On Feb 26, 2008, at 5:46 AM, mario ruggier wrote:

> Hi,
>
> am trying to configure a sub-domain on lighttpd as a scgi-deployed
> qp site. It seems pretty straightforward, but there is something
> very strange going on with script_name.
>
> To illustrate, using the stock echo demo site that comes in qp 2.0,
> and setting up a sub-domain echo.example.com to point to the
> physical box where lighttpd is listening, and adding the following
> lighttpd conf (to an otherwise default main lighttpd config):
>
> $HTTP["host"] == "echo.example.com" {
>    server.name = "echo.example.com"
>    scgi.server = (
>         "/" => (
>            (
>              "host" => "127.0.0.1",
>              "port" => 11001,
>              "check-local" => "disable",
>              "max-procs" => 1,
>            ),
>        ),
>    )
> }
>
> Then requesting the following URLs sets the following values:
>
> http://echo.myfiki.com/
>  'PATH_INFO': '/',
>  'REQUEST_URI': '/',
>  'SCRIPT_NAME': '',
>
> http://echo.myfiki.com/xx
>  'PATH_INFO': '/xx',
>  'REQUEST_URI': '/xx',
>  'SCRIPT_NAME': '',
>
> http://echo.myfiki.com/xx/
>  'PATH_INFO': '/',
>  'REQUEST_URI': '/xx/',
>  'SCRIPT_NAME': ''/xx,
>
> http://echo.myfiki.com/xx/yy
>  'PATH_INFO': '/yy',
>  'REQUEST_URI': '/xx/yy',
>  'SCRIPT_NAME': ''/xx,
>
> http://echo.myfiki.com/xx/yy/
>  'PATH_INFO': '/yy/',
>  'REQUEST_URI': '/xx/yy/',
>  'SCRIPT_NAME': ''/xx,
>
> and so on. It seems that -- when there is more than one url
> component -- the first of these is interpreted as being the
> script_name.
>
> Has anyone been successfully deploying qp sites (or quixote, as I
> suspect behaviour will be identical) on lighttpd+scgi? Should I be
> using a different lighttpd conf, or is the sample conf above
> conceptually correct? Is this variation in what is the script_name
> an internal issue to qp?


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.