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 <extension> 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 <extension> 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
<extension> 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:
<extension>: is the file-extension or prefix (if started with "/")
So, no changes to qp necessary ;-)
mario
_______________________________________________
QP mailing list
[email protected]
http://mail.mems-exchange.org/mailman/listinfo/qp
