Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PATH_INFO Backup and IIS Middleware Patch #300

Closed
wants to merge 6 commits into from
Closed

PATH_INFO Backup and IIS Middleware Patch #300

wants to merge 6 commits into from

Conversation

KnowZero
Copy link

This is to address issue #284 and allow IIS to work while also making PATH_INFO accessible to middleware prior to destruction via PLACK_PATH_INFO

@miyagawa
Copy link
Member

PLACK_PATH_INFO isn't a great name to set this up and also kind of violates the PSGI spec. If I were to do it, i would use plack.PATH_INFO_ORIGINAL.

@KnowZero
Copy link
Author

So make it $env->{'plack.PATH_INFO_ORIGINAL'} ?

@miyagawa
Copy link
Member

Sounds better to me yes.

@KnowZero
Copy link
Author

ok, done!

@miyagawa
Copy link
Member

Can you squash them into one commit and force push? The changes are dirty.

@miyagawa
Copy link
Member

I'm still not sure if this is the right thing to do - Can resurrecting PATH_INFO from REQUEST_URI be pushed to a piece of middleware and then IIS/lighttpd/apache middleware can do whatever they want to do, instead of doing it inside FCGI?

@KnowZero
Copy link
Author

If you mean putting:

my($path, $query) = ( $env->{REQUEST_URI} =~ /^([^?]*)(?:\?(.*))?$/s );
for ($path, $query) { s/\#.*$// if defined && length } # dumb clients sending URI fragments

my $newpath = URI::Escape::uri_unescape($path);

Inside a middleware?

That said this issue effects only FCGI so is making a middleware specific to FCGI make any sense?

But you just reminded me of a flaw in my code which I am going to fix right now. :/

@miyagawa
Copy link
Member

That said this issue effects only FCGI so is making a middleware specific to FCGI make any sense?

IIS6 and Lighttpd fix middleware already exists solely to fix FCGI environments.

@KnowZero
Copy link
Author

Oh, so those middleware are not needed outside of FCGI?

@KnowZero
Copy link
Author

Because if that is the case, then yes it makes most sense just to modify each middleware individually.

@miyagawa
Copy link
Member

Not needed, because if you don't use FCGI SCRIPT_NAME and PATH_INFO are NOT built by lighttpd or IIS anyway.

@KnowZero
Copy link
Author

If that is the case then I guess I'll just modify IIS6 middleware with this:

my($path, $query) = ( $env->{REQUEST_URI} =~ /^([^?])(?:?(.))?$/s );
for ($path, $query) { s/#.*$// if defined && length } # dumb clients sending URI fragments

$env->{PATH_INFO} = URI::Escape::uri_unescape($path);

and that should do it.

@miyagawa miyagawa closed this Jun 29, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants