On Feb 26, 2008, at 12:44 PM, Binger David wrote:
> This looks like a problem the scgi module in lighttpd, where the
> SCRIPT_NAME value is first set.  It could just be a bug, or perhaps
> there is a way to control the SCRIPT_NAME by configuration?
>
> I don't think QP has any code that could set the SCRIPT_NAME
> to a nonempty value.
>
> There is a similar web server bug for which QP provides a workaround
> (setting a "script_name" value in the publisher's dictionary).
> In that situation, we are dealing with web servers that put the full
> path in the SCRIPT_NAME and leave PATH_INFO unset.
> The case you describe looks similar, and I guess we could put
> a similar hack to deal with it in
> qp.hub.web.SCGIHandler.handle_connection(),
> but it would be nicer to fix it at the source.

I see that code -- but if this were a bug it would be more difficult to
tell whether the non-empty script_name is erroneous or not.

Playing with the echo test site some more, I discovered that setting
the  on which the scgi handler matches to be "" (empty),
then the echo site behaves as I would expect it. I.e. the previous
lighttpd conf becomes:

$HTTP["host"] == "echo.example.com" {
    server.name = "echo.example.com"
    server.document-root = "/srv/www"
    scgi.server = (
         "" => (
            (
              "host" => "127.0.0.1",
              "port" => 11001,
              "check-local" => "disable",
              "max-procs" => 1,
            ),
        ),
    )
}

I had tried an empty string  earlier, but on another site on
a different publisher... and the result was an infinite redirection
loop. As it turns out, I had added a hack fix similar to above for a
condition on apache2... this one was was using the SCRIPT_FILENAME
(when not set, nothing changes). The condition it was trying to fix is:

     # Handle case when site is deployed under a script, but the
requested
     # url ends with precisely the SCRIPT_NAME (with nothing trailing
it).
     # This erroneously (on Apache2) gives an empty string SCRIPT_NAME
and
     # a PATH_INFO set to the what the SCRIPT_NAME should be -- this
breaks
     # any dynamically calculated relative url paths.
     #
     # Assumption here is that if SCRIPT_FILENAME (not part of the CGI
1.1
     # spec) is set, then it must end with the (non-empty) SCRIPT_NAME.

I had placed the check in Publisher.process_inputs(). Removing this
check makes the site behave as the echo site.

Incidentally ligthtpd (1.4.18) *is* setting the SCRIPT_FILENAME here...
and fwiw it seems to follow the logic below (that may not be correct --
in this case SCRIPT_FILENAME is not in any way related to the server's
static document root):

     if SCRIPT_NAME:
         SCRIPT_FILENAME = document-root + SCRIPT_NAME
     else:
         SCRIPT_FILENAME = document-root + REQUEST_URI

So, with the above config, requesting http://echo.example.com/xx/yy
will give:
'SCRIPT_FILENAME': '/src/www/xx/yy'

Anyhow, long-winded way of saying that what the lighttpd conf's
 on which an scgi handler matches may be could be made
clearer, and combined with other attempt I assumed it is not allowed to
be empty... the complete doc I found on it is rather thin:
: is the file-extension or prefix (if started with "/")

So, no changes to qp necessary ;-)

mario