httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexei Kosut <>
Subject Re: CGIWrap Problems (fwd)
Date Wed, 30 Apr 1997 01:03:59 GMT
On Tue, 29 Apr 1997, Roy T. Fielding wrote:

> That may be the reason for doing it this way, but it doesn't change
> the fact that it results in the wrong information being given to
> the script.  It is not a feature if it breaks the definition of SCRIPT_NAME,
> which is exactly what it is doing.

Yeah, and the old "correct" way of creating SCRIPT_NAME, which would
result in things like "/cgi-b" or a core dump, was much better... ;)

> There are two issues here.  First, if the above is what is wanted, the
> implementation is still wrong (see below).  Second, Apache is opening
> a CGI gateway to the script cgiwrapd, and thus a ScriptAlias is performing
> an internal redirection on a new URL whether or not that was intended
> by the original definition of ScriptAlias [if we aren't doing that, then
> we should return 404 Not Found instead].  You are assuming that the *URL*
> is the Request-URI, but that is not how it was implemented in NCSA httpd
> or Apache 1.1 or CERN httpd (the only real definition of CGI that matters).
> In fact, this is exactly what David wrote in the CGI spec:

Again, this is not correct. ScriptAlias does two things, Script and
Alias. Alias is not an "internal redirection", it is a simple
URL-to-filename mapping. Script just means that it runs it as a CGI
script. Nothing mystical there.

Using ScriptAlias to send path info is, IMHO, an extermely broken and
braindead way of using it. I believe that we *should* return 404. But
one's man bug is another's feature...

> In other words, the definition of SCRIPT_NAME and PATH_INFO are based
> on the internal URL defined by ScriptAlias and not based on the Request-URI.
> The fact that the internal URL is not accessible may be less important
> than the ability to pass path_info via the ScriptAlias mechanism.

But it's not a URL. It's a filename. It refers to the physical
location of the script on the hard drive. Which has nothing to do with
a URL.

> Even if they were defined by the Request-URI, the implementation is still
> wrong.  Look at the example given by the user:
>   ScriptAlias /cgi-bin/ /magma/web/cgi-bin/cgiwrapd/userid00/
> calling the Request-URI:
>   /cgi-bin/
> with the following record info
>   r->path_info       /userid00/
>   r->uri             /cgi-bin/
> produces:
>   SCRIPT_NAME: '/cgi-bin'
>   PATH_INFO: '/'
> According to the your definition of SCRIPT_NAME and PATH_INFO,
> the result should be
>   SCRIPT_NAME: '/cgi-bin/'
>   PATH_INFO: '/klgeddie/test'
> The reason it isn't is because the find_path_info routine doesn't work right.

Yes, it is. You're presuming that "" is the CGI
script. It's not. cgiwrapd is the CGI script. is just an
argument to cgiwrapd. The fact that it also happens to be a CGI script
is irrelevant; the server never sees it. The server calls cgiwrapd;
and cgiwrapd's name certainly isn't "". As far as URLs go,
it's name *is* /cgi-bin.

Alexei Kosut <>      The Apache HTTP Server

View raw message