httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexei Kosut <>
Subject Re: fwd> problem with apache-1.2b1 and cgiwrap-3.5
Date Sun, 08 Dec 1996 19:13:50 GMT
On Sun, 8 Dec 1996, Nathan Neulinger wrote:

> I got this note on the cgiwrap list about cgiwrap not working with the new
> beta, but it works fine with 1.1.1. It appears from the note that the
> behavior of ScriptAliases with embedded path_info (the arguments to cgiwrap
> in the scriptalias call) appears to have changed.

Yes, it has. The problem with the code was that it relied on simple
subtraction of string lengths to figure out where to pull path_info
from. To use the example from the forwarded message:

> ScriptAlias /cgi-bin/ /usr/local/etc/httpd/cgi-bin/cgiwrapd/digisi/

In this case, Apache would note that the path info, "/digisi/", was
eight characters, and would take the last eight characters off of
"/cgi-bin/" to form SCRIPT_NAME. This results in "/c". This is
obviously wrong, and if "digisi" had been two characters longer, it
would have tried to pull off more characters than existed, which would
have resulted in a seg fault.

We changed the code to be "smarter", to look at the requested URI, and
the translated filename, figure out how much was similar. So if the
user requests "/cgi-bin/", it translates this to
"/usr/local/etc/httpd/cgi-bin/cgiwrapd/digisi/". Apache
determines that the only part of the two strings that are the same is
the "/" part. So SCRIPT_NAME gets "/cgi-bin", and
PATH_INFO gets "/".

The CGI/1.1 spec is vauge on the exact defenitions of PATH_INFO and
SCRIPT_NAME as they apply to this sort of situation, and we felt it
was better to maintain a server that worked consitently than one that
adhered to some weird interpertation of the CGI spec, which resulted
in incorrect behavior. In addition, we felt it was important to
maintain the ability for a CGI script to determine its own location
interpretation of $SCRIPT_NAME and $PATH_INFO made this impossible in
these cases. It now works perfectly.

Except in this case, of course, where the "digisi" information gets
lost, except in PATH_TRANSLATED (which maintains the old-style
path_info formatting). This is unfortunate, but neccessary.

Hmm. I suppose we could put the old-style PATH_INFO into another env
variable, FILENAME_INFO maybe. It would still result in backwards-
incompatibility, though. That's what happens when you try to use a
filesystem path to store non-file related information (as this example
is doing).

Feel free to forward this to any interested parties.

Alexei Kosut <>      The Apache HTTP Server

View raw message