Skip Menu |

Preferred bug tracker

Please visit the preferred bug tracker to report your issue.

This queue is for tickets about the Plack CPAN distribution.

Report information
The Basics
Id: 78687
Status: rejected
Priority: 0/
Queue: Plack

Owner: Nobody in particular
Requestors: DAMI [...]

Bug Information
Severity: Normal
Broken in: 1.0001
Fixed in: (no value)

Subject: Handler::Apache2::fixup_path messes up SCRIPT_NAME
Download (untitled) / with headers
text/plain 1.3k
Context ======= I'm using modperl PerlAuthz handlers to control access to some parts of my application, i.e. the Apache config looks more or less like this: <Location /my_app> SetHandler modperl PerlResponseHandler My::Catalyst::App PerlOptions +ParseHeaders PerlOptions +SetupEnv </Location> <LocationMatch "^/my_app/(foo|bar)/restricted"> PerlAuthzHandler My::Authorization::Module # authz configuration options </LocationMatch> <LocationMatch "^/my_app/(other|area)/restricted"> ... </LocationMatch> Problem ======== fixup_path() in Handler/ misinterprets the config. When it calls $r->location, modperl returns the _inner_ LocationMatch directive, but that directive is just for authorization, it's not the root of the application. Then $env->{SCRIPT_NAME} is incorrectly set to the inner URL, whereas $ENV{SCRIPT_NAME} as given through Apache+mod_perl is correct. I don't really understand why this fixup_path() business is necessary, since Apache+mod_perl already seems to do the proper job; but anyway, if you need to keep that code, I guess there should be an additional check to execute it only when running under ModPerl::Registry, not when running under other modperl handlers. For the moment, I hacked the "prepare_path" method in my Catalyst app to work around this problem.
Please report on the issue tracker on

This service is sponsored and maintained by Best Practical Solutions and runs on infrastructure.

Please report any issues with to