Lighttpd

Hello,

while trying to replace an apache2 server on a slow machine (with 256MB RAM), I tested the latest snapshot release (svn r1691), being interested specifically in proxy request and response header rewriting. Besides the failure to proxy files larger than an unreproducable size over SSL (#1042), I found a problem with mod_cgi incorrectly setting an environment variable.

I am hosting a few private mercurial repositories through a CGI script. It is located at {{{"/hgweb/hgwebdir.cgi"}}} relative to the doc-root, and is operated via pathinfo. The path handling regression is experienced when providing a pathinfo with a trailing slash.

As an example, consider the request URI {{{"/hgweb/hgwebdir.cgi/foo/bar/"}}}. In contrast to lighttpd-1.4.x (and apache), lighttpd erroneously sets the CGI environment variable SCRIPT_NAME to {{{"/hgweb/hgwebdir.cgi/"}}}. If, however, one provides the URI {{{"/hgweb/hgwebdir.cgi/foo/bar"}}} (that is, without a trailing slash), SCRIPT_NAME is set to the correct value {{{"/hgweb/hgwebdir.cgi"}}}.

This regression results from svn r1131, where a code snippet to remove a trailing directory separator from physical.path was introduced in function handle_get_backend, in order to circumvent the broken win32 dir handling.

                /* win32: directories can't have a trailing slash */
                if (con->physical.path->ptr[con->physical.path->used - 2] == DIR_SEPERATOR) {
                        con->physical.path->ptr[con->physical.path->used - 2] = '\0';
                        con->physical.path->used--;
                }

What had been forgotten with this change is the removal of pathinfo from uri.path near the end of the function. This code still assumes the original physical.path length, thus leaving a surplus slash in uri.path in the case of a trailing slash in the request URI.

                                /*
                                 * shorten uri.path
                                 */

                                con->uri.path->used -= strlen(pathinfo);
                                con->uri.path->ptr[con->uri.path->used - 1] = '\0';

Omitting the above win32 fix resolves the issue, but obviously only for POSIX systems.
(On further thought, a consistent solution might also affect physical.rel_path.)

Regards,
Peter.

-- peterco