-
-
Notifications
You must be signed in to change notification settings - Fork 89
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
fix request URI with multiple leading slashes, #203
- Loading branch information
Showing
1 changed file
with
2 additions
and
1 deletion.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
575cfda
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why the
preg_match
?$_SERVER['REQUEST_URI']
should always be scheme-less.575cfda
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I read that in case a proxy was used, REQUEST_URI can also be a full absolute URI. In that case we don't need to adjust this thing, or it would break.
575cfda
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On which server? If that's the case, maybe we should tweak
REQUEST_URI
orURI
so that other pieces don't break (REALM
for example).575cfda
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
not tested by myself yet, just read that in comments on http://php.net/manual/en/reserved.variables.server.php but maybe this is not valid. I was just believing that, due to the fact that parse_url is used at this point, which already handles this occasion. So I thought it's already prepared for that in the core?!?
575cfda
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Justed tested it, following these instructions, with the following .pac file:
Here are the variables which differ:
http://192.168.33.10/foo/bar
http://www.foo.local/foo/bar
HTTP_HOST
192.168.33.10
www.foo.local
SERVER_NAME
192.168.33.10
www.foo.local
REQUEST_URI
/foo/bar
http://www.foo.local/foo/bar
But now: isn't that a misuse of the proxy autoconfig ? We're sending a proxy command to a web server, instead of a proxy server. And if I look at the Apache access.log, I can see this:
which shows that the HTTP request generated by the .pac file is intended for a proxy, not a web server.
https://tools.ietf.org/html/rfc2616#section-5.1.2 says:
and
575cfda
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thx for the research @xfra35. so what does this mean? It's valid to patch it for the framework, as we don't know if the application will ever be used as a proxy service directly?! (actually I really wrote such a thing on F3 already)
575cfda
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well it looks to me that:
So the framework should never receive an absoluteURI form.
But the fact is that we may, in very rare cases, receive an absolute URI. So your patch makes sense.
The next question is: what to do with
REQUEST_URI
? Should we patch it as well, so that we can keep on relying on it as a relative URI in all circumstances? That would fixREALM
at the same time.575cfda
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am for patching
REQUEST_URI
if both of you agree.575cfda
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok done here 4d70bb4