-
Notifications
You must be signed in to change notification settings - Fork 214
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
Conversation
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 |
So make it $env->{'plack.PATH_INFO_ORIGINAL'} ? |
Sounds better to me yes. |
ok, done! |
Can you squash them into one commit and force push? The changes are dirty. |
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? |
If you mean putting:
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. :/ |
IIS6 and Lighttpd fix middleware already exists solely to fix FCGI environments. |
Oh, so those middleware are not needed outside of FCGI? |
Because if that is the case, then yes it makes most sense just to modify each middleware individually. |
Not needed, because if you don't use FCGI SCRIPT_NAME and PATH_INFO are NOT built by lighttpd or IIS anyway. |
If that is the case then I guess I'll just modify IIS6 middleware with this: my($path, $query) = ( $env->{REQUEST_URI} =~ /^([^?])(?:?(.))?$/s ); $env->{PATH_INFO} = URI::Escape::uri_unescape($path); and that should do it. |
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