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

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

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?

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:
> >
> > ``The PATH_INFO string is the trailing part of the <path> component of
> > the Script-URI (see section 3.2) that follows the SCRIPT_NAME portion of
> > the path.''
> >
> > ``Servers MUST make this URI component available to CGI scripts.''
> 
> ONLY when using scriptalias...otherwise it's meaningless

How does this invalidate my argument ???

> > Notice, also, that _6.1.7. _PATH_TRANSLATED_ states:
> >
> > ``PATH_TRANSLATED is derived by taking any path-info component of the
> > request URI (see section 6.1.6), decoding it (see section 3.1), parsing
> > it as a URI in its own right, and performing any virtual-to-physical
> > translation appropriate to map it onto the server's document repository
> > structure.''
>
[ snip ]
>
> The thing that is biting you is this:
> 
> AliasMatch ^/~([^/]+)(/(.*))? /home/sites/site99/users/$1/web/$3
> 
> Because user directories are handled as an alias , the path is not
> reversible by the server and several things break, includig mod_rewrite
> functionality for .htaccess for users and PATH info for cgi's

This is an interesting contention: ``... the path is not reversible by
the server ...''

Why is this?

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

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

Why is this?

How is it doing this?

> Doing the above using rewrite instead of the alias odule might fix it, tho
> i admit i have never tried it...

Here is the only stab at a solution, that anybody has suggested.

Anything else?

> The question is do you want to fiddle and void the (largely
> useless)[imho] software warrenty....

As stated in my preface, my goal is to identify the Root Cause and
possible solutions.

I believe, once I can demonstrate a solution to Cobalt, it can be
incorporated into a supported patch.

What do you think?

-- 

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