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

["Michael D. Schleif" <mds-resource@xxxxxxxxxxxx>]

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

OK, #4 isn't something that I would use; but, I can see plenty of
reasons for #3 -- and, it does conform to CGI specifications.

> > 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'm not playing any name game -- only searching for the Root Cause and
possible solutions ;>

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

So would I; but, that is where Tera-Byte (webhost) comes in -- they
won't diddle one iota from standard Cobalt -- period ;<

O, CGIWrap was my first suspect!  Of course, neither
http://cgiwrap.unixtools.org/ nor
mailto:cgiwrap-users@xxxxxxxxxxxxxxxxxxxxx have proven helpful.

Of course, that does *not* relieve them of culpability };-Þ

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

No kidding . . .

> > 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..

Please, give an example?

> 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...

Yes, I know ;>

If PATH_* remained null and empty all of the time, I'd be much happier.

Any other ideas?  Without Tera-Byte's cooperation, is there anyway for
me to prove Root Cause as Apache configuration or CGIWrap?  That is what
I really need . . .

Also, thank you, for humoring an ol' geek ;>

-- 

Best Regards,

mds
mds resource
888.250.3987

"Dare to fix things before they break . . . "

"Our capacity for understanding is inversely proportional to how much we
think we know.  The more I know, the more I know I don't know . . . "