Document lighttpd fastcgi-fix

[miyagawa]

Since lighttpd 1.4.23, you also can use the "fix-root-scriptname" flag
in fastcgi.server.

[miyagawa]

From Yury --

Rack has a similar doc on this
http://github.com/rack/rack/blob/master/KNOWN-ISSUES
Doc patch to Plack/Handler/FCGI.pm to address this would be pretty
much appreciated.

I have written some documentation. It is based on the Rack documentation:
http://github.com/tadam/Plack/commit/c53bc7c112d79a510d11d6cb5cc03ea70dcebb26
(I am not sure of my terrible English, but something is better than nothing)

Problem appears every time when you mount at something with "/" at the end, not only in the root case.
But if the root case is a simple, "/something/" mount point is more weird.
Here are some samples, when you mount app at "/something/":

'SCRIPT_NAME' => '/something/',
'PATH_INFO' => '',
'REQUEST_URI' => '/something/',

'SCRIPT_NAME' => '/something/one',
'PATH_INFO' => '',
'REQUEST_URI' => '/something/one',

'SCRIPT_NAME' => '/something/one',
'PATH_INFO' => '/',
'REQUEST_URI' => '/something/one/',

'SCRIPT_NAME' => '/something/one',
'PATH_INFO' => '/two/three',
'REQUEST_URI' => '/something/one/two/three',

So, in this case you must pass your mount point as parameter in middleware, that will split REQUEST_URI into SCRIPT_NAME and PATH_INFO.

Or you can change mount point to "/something". Everything will work except of trivial case:
'SCRIPT_NAME' => '/something',
'PATH_INFO' => '',
'REQUEST_URI' => '/something',
PSGI spec says that it is a valid situation: "This may be an empty string if the request URL targets the application root and does not have a trailing slash." (from description of PATH_INFO).
In this case PATH_INFO is empty and it means that Plack::Handler::FCGI will swap SCRIPT_NAME and PATH_INFO. You can avoid this if you will make redirect from "/someting" to "/something/".
But you can't distinguish these two situations without additional information.

So I see two options here:

• pass additional information about mount point in Plack::Handler::FCGI
• or documentation must says, that redirection is mandatory (probably it is a more convenient variant)

Since lighttpd 1.4.23, you also can use the "fix-root-scriptname" flag
in fastcgi.server. Did you try it?

I use ubuntu hardy and here is a 1.4.19 by default.
I checked 1.4.23. Yes, "fix-root-scriptname" works for "/" mount point and don't works for "/something/".
They says, that 1.5.x haven't this bug, but I can't compile it on my machine, some errors appears (aargh, I already hate lighttpd but it is not my wish to use lighttpd :-) ).

So this SCRIPT_NAME/PATH_INFO is pretty much broken -- SCRIPT_NAME
should be /admin (why /feedamin? copy-paste failure?) and PATH_INFO
should be /css/main.css.

Yeah, it is a copy-paste failure.
Thank you. Now I understand the meaning of SCRIPT_NAME and PATH_INFO.
Also I have read this interesting discussion about empty and non-empty PATH_INFO:
http://mail.python.org/pipermail/web-sig/2007-January/002475.html

[miyagawa]

Or you can change mount point to "/something". Everything will work except
of trivial case:
'SCRIPT_NAME' => '/something',
'PATH_INFO' => '',
'REQUEST_URI' => '/something',
PSGI spec says that it is a valid situation: "This may be an empty string if
the request URL targets the application root and does not have a trailing
slash." (from description of PATH_INFO).
In this case PATH_INFO is empty and it means that Plack::Handler::FCGI will
swap SCRIPT_NAME and PATH_INFO.

Actually I think we can patch Handler::FCGI to eliminate the
lighttpd-fix at all, and then recommend the use of mount "/something"
(without the trailing slash). Also we can document the ligghtpdFix
middleware if you want to mount in the root, like your doc patch
suggests. What do you think?

You can avoid this if you will make redirect
from "/someting" to "/something/".
But you can't distinguish these two situations without additional
information.

I see.

So I see two options here:

• pass additional information about mount point in Plack::Handler::FCGI

No, that's not really clean.

• or documentation must says, that redirection is mandatory (probably it
  is a more convenient variant)

Yes, or prevent the redirection and let users work around by writing middleware.

Since lighttpd 1.4.23, you also can use the "fix-root-scriptname" flag
in fastcgi.server. Did you try it?

I use ubuntu hardy and here is a 1.4.19 by default.
I checked 1.4.23. Yes, "fix-root-scriptname" works for "/" mount point and
don't works for "/something/".

Okay good. Then let's remove the if (for_lighttpd) code at all and
document the "fix-root-scriptname" as well as the middleware solution.

[miyagawa]

So my preference here is to a) eliminate the current if (lighttpd) { fix SCRIPT_NAME } code from Handler::FCGI, and b) document that you should either mount /foo (without the trailing slash) or to root with fix-root-scriptname with lighttpd 1.4.23+. And if you want to use the older lighttpd you should write the middleware which we could probably include in the core dist.

[miyagawa]

Committed a fix http://github.com/miyagawa/Plack/commit/c2c8a23d5c4a37c777e7f469c9406b6e03825c2b

[miyagawa]

Fixed in 0.9925

[tadam]

I checked the last revision from github and tested this with lighttpd 1.4.19 and 1.4.23.
So there are little fixes from me in patch: http://gist.github.com/347801

"fix-root-scriptname" works only for "/" mount point but don't works for "", it is my oversight. But another urls without slash at the end works correctly. I changed "" to "/" both in documentation and code that generates config for lighttpd.

Also I changed code that gets lighttpd version (in previous versions it was a 'lighttpd-$ver' in current -- 'lighttpd/$ver').

P. S. I had a situation when I needed to use "/" at the end of mount point.
I wanted to serve static files by lighttpd, not by Plack, and wanted to serve following uris:

/changes.xml -- static files that serves by lighttpd

/changes/\d+ -- some request

In this (specific enough) case I use such (compatible with Plack::Middleware::LighttpdScriptNameFix) code: http://gist.github.com/347803
(maybe it will be helpful for some people)

[miyagawa]

tadam, thanks for the patches. Both look good to me but i wonder why fcgi.t tests were working for lighttpd 1.4.26. Maybe the code to check version was wrong and was still using LighttpdScriptNameFix?

[miyagawa]

Also in the LighttpdScriptNameFix you're using REQUEST_URI but it's not correct -- REQUEST_URI sets the escaped URI but PATH_INFO should be unescaped (decoded). So you should first save the original SCRIPT_NAME that lighttpd sets and then concat with PATH_INFO, i.e.

my $lighttpd_script_name = $env->{SCRIPT_NAME};
$env->{SCRIPT_NAME} = $self->script_name;
($env->{PATH_INFO} = $lighttpd_script_name . $env->{PATH_INFO}) 
  =~ s/^\Q$env->{SCRIPT_NAME}\E//;

[miyagawa]

committed your patch and merged the LighttpdFix into LighttpdScriptNameFix (because it's compatible) as daa56bc

[tadam]

Maybe the code to check version was wrong and was still using LighttpdScriptNameFix?

Yes, it is:
tadam@hardy64:/src/Plack$ perl -e 'my $ver; if ($ver < 4.23) { print "<\n" } else { print ">\n" }'
<
tadam@hardy64:/src/Plack$

You are right about unescaped PATH_INFO.

Current master works properly with lighttpd-{1.4.19,1.4.23,1.4.26}.
Thanks.

[miyagawa]

it was checking if $ver was defined as well, and Plack 0.9925 was failing with lighttpd 1.4.26 -- not sure how i missed that. Shipped 0.9927 to CPAN -- great that we confirm the fix against all of nasty lighttpd versions. Thanks!