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.
_______________________________________________
QP mailing list
[email protected]
http://mail.mems-exchange.org/mailman/listinfo/qp
