Re: [cobalt-users] Failure to conform to CGI standards ???

[flash22@xxxxxxx]

On Mon, 4 Dec 2000, Michael D. Schleif wrote:

> 
> First, let me assure everybody that my posting is *no* attempt at
> criticism, nor a slam of webhost Tera-Byte.
> 
> I have come to understand the turnkey nature of Cobalt offerings and the
> warranty/support issues regarding modifying standard configurations.
> 
> Nevertheless, I am documenting a technical problem:
> 
> [1] I am seeking the Root Cause of this problem.
> 
> [2] I am seeking technical solutions to that Root Cause.
> 
> Can any of you assist me in this???
> 
> flash22@xxxxxxx wrote:
> > 
> > On Sun, 3 Dec 2000, Michael D. Schleif wrote:
> > 
> > > Please, notice that following four (4) URL's demonstrate a serious
> > > problem with the configuration of one of Tera-Byte's servers:
> > >
> > > #1 <http://www.helices.org/~helices/tmp/test5.pl>
> > > #2 <http://www.helices.org/~helices/tmp/test5.pl?tmp=pictures>
> > > #3 <http://www.helices.org/~helices/tmp/test5.pl/tmp/pictures>
> > > #4 <http://www.helices.org/~helices/tmp/test5.pl/tmp/pictures?tmp=pictures>
> > 
> > well, in theory only #2 is a valud cgi call...
> 
> I'd love to review your support of this argument -- perhaps, offlist?

ok, taking foot out of mouth, never reply at 2am ;)
i still argue that #3 is an invalid url as it is neither a directory name
or a mime type'd file, but it's does't matter much
#4 is imho EVIL ;) tho i suppose it's valid from the point of view of the
gateway spec...I really need to get a spell checker ;0

> 
> However, since you have kindly accepted my other examples, even for sake
> of my case, let us look further into this challenge ;>
> > > Notice that _6.1.6. PATH_INFO_ states:
> How does this invalidate my argument ???

It doesn't really, but don't blame everything on apache here, the default
cobalt config uses cgiwrapper, which itself is invoked as a scriptalias
 and it's not very smart about this, it's trying to convert a mangled url
to a user id, and it doesn't always get it right, it doesn't have
access to all the path info that apache does .

i'd try the same test with cgiwrapper disabled ;0

there's way too much translation going on...

url -> userdir alias
userdir -> user scriptalias
any .htaccess generated aliases...
userscript alias -> cgiwrapper alias
cgiwrapper -> uid/gid -> real script

part of the problem is cgiwrapper doesn't really know if the paths are
invalid anymore, it can only see the final fragment passed to it via one
of the alias's , so i suspect it always runs in a context where it thinks
it has a valud path <-> url mapping, even when it doesn't, also i know
cobalt's build of cgiwrapper plays with environment variables (mostly it
deletes them)


 > 
> Clearly, given the URL submitted, I can do required parsing inside a CGI
> -- how is it that Apache cannot do this?

It can, if everything is done with rewrite, i really don't understand why
cobalt didn't do this, they loaded the module to support domain
translation, so they paid the price per hit for starting it up and
initalizing it, so why did they then switch to Alias to do the user part?
for that matter, wrapping cgi's would have been possible here as well,
it's fairly easy to tag info into a rewritten url with rewrite and the
wrapper could have been given definitive user access info instead of
making it try to guess at what the proper uid was supposed to be from
directory context, something it seems to get wrong a lot , especially in
contexts where frontpage is also on the machine with it's own idea of file
ownership..
 
> > For that matter, Apache *IS* performing some parsing, because it *IS*
> populating *both* PATH_INFO and PATH_TRANSLATED, even though it ``... is
> not reversible by the server ...''
> ... and, even when it should *NOT* be populating these vars ;<

ok,i ran a quick test on my desktop machine (apache 1.3.9) with no
cgiwrapper, and with a plain cgi call, it does not set any PATH*
variables, tho it correctly sets SCRIPT_* stuff...

(ok, there's too many permutations of cgi methods here for that to be
definitive, but i think cgiwrapper is at elast aprt of the problem ..)