Workaround for mod_perl introduced a bug for mod_rewrite

[niner]

Commit 5a22236 introduced a workaround for a mod_perl issue. Since mod_perl squeezes multiple slashes into one in PATH_INFO, REQUEST_URI is used instead to generate a new PATH_INFO.

We use a content management system based on Catalyst 5.9 which uses Plack underneath. The CMS is running as FastCGI process and accessed via mod_fastcgi from Apache. We use mod_rewrite to provide short URLs for certain sub pages. With Catalyst 5.8 this works while with 5.9 this is broken, resulting in 404 errors from the CMS. The problem is, that PATH_INFO now contains the short URL which the CMS knows nothing about. Without Plack, REQUEST_URI contains the short URL while PATH_INFO contains the destination path which is what the CMS needs to find the right page.

Removing the above mentioned workaround for mod_perl fixes the issue for us.

[miyagawa]

Can you post an example combination of PATH_INFO and REQUEST_URI, as well as the (possibly simplified version of) mod_rewrite configurations?

[niner]

These are the relevant configuration statements for this issue:
RewriteEngine On
RewriteRule ^/kaarst /content/steuerberater/stb/wir_ueber_uns/unsere_standorte/steuerberater_kaarst/unsere_philosophie/index_ger.html [PT]
AliasMatch ^/(?!cgi-bin|error|icons)(.*)$ /srv/www/tmp/cms.fcgi/$1

This would be the desired result:
SCRIPT_NAME: /
REQUEST_URI: /kaarst
PATH_INFO: /content/steuerberater/stb/wir_ueber_uns/unsere_standorte/steuerberater_kaarst/unsere_philosophie/index_ger.html

This is the actual result with the mod_perl workaround in place in Plack:
SCRIPT_NAME: /
REQUEST_URI: /kaarst
PATH_INFO: /kaarst

[miyagawa]

Thanks.

There's a similar one on FCGI http://groups.google.com/group/psgi-plack/browse_thread/thread/d690e1b57e79b709

@cho45 @bobtfish I don't know, but maybe the double slash fix should be extracted as a piece of middleware and disabled by default or something? This is pain in the ass (mod_rewrite generally is, though).

[bobtfish]

Yeah, stopping this being default (so Catalyst doesn't use it) is the correct fix for what we want to do...

It is both a pain in the ass, and a mess, and we have a setting for 'old style' (where just PATH_INFO) is used, and 'new style' (where REQUEST_URI is used).

http://search.cpan.org/~bobtfish/Catalyst-Runtime-5.90005/lib/Catalyst.pm#CONFIGURATION (use_request_uri_for_path at the bottom of the list here)

[cho45]

Okay... I understood the problem finally....

Unfortunately, this is too difficult to resolve fundamentally. So I agree with @bobtfish about the setting and the (smaller complaint) default.

However, I don't know if a middleware does it... (or fix in embed in code and switch with environment variable).

[miyagawa]

I think a piece of middleware can do for FastCGI.

It basically has to look at REQUEST_URI, s/^SCRIPT_NAME// and then URI-decode it and stash the result into PATH_INFO.

For Apache, it would be a bit more complicated because of its LocationMatch madness.

[cho45]

For Apache, an easiest way is that a middleware just flags to $env and P::H::Apache2 changes behavior by the flag...

[miyagawa]

Apache handler runs before any middleware runs, so it might not work :)

We can extract the location handling as middleware as well, but that sounds a bit too painful to configure.

[cho45]

Oh... I have overlooked.

[niner]

Is there any progress on this issue? Is there something I can do to help fix this?