Bug Report #3001
Request::$uri changes based on the server.
|Assignee:||Jeremy Bush||% Done:|
You have a server with PATH_INFO and request the following URL:
PATH_INFO will contain /ö and thus set Request::$uri to the same value.
This server doesn't have PATH_INFO, but REQUEST_URI. I request the same URL:
but REQUEST_URI uses the encoded values like so: /%C3%B6.
We have a problem where the Request class is inconsistent. The solution I propose would be to cascade down from using decoded values to encoded values.
I think REQUEST_URI should be used as a last resort. If a user requests /ö then I expect that in the Request class. What if they request /%C3%B6? I still expect /ö in the request class. That's because they're the same, just ones encoded and the other is not.
I think it'd be a far more common scenario for a person to want to use the already decoded values.
#2 Updated by Mathew Davies about 4 years ago
I'd prefer rawurldecode. This way the addition character isn't parsed as a space. This will mimic how the server globals act.
URI requested: /%C3%B6%20+
'SCRIPT_NAME' => string '/ö +' (length=5) 'REQUEST_URI' => string '/%C3%B6%20+' (length=11) 'DOCUMENT_URI' => string '/ö +' (length=5) 'PHP_SELF' => string '/ö +' (length=5)
I still think using REQUEST_URI last is the optimal solution. The server has already done the work and would require 1 less method call. Either way works for me though.
#6 Updated by Woody Gilk about 4 years ago
- Status changed from New to Needs Test
- Assignee changed from Woody Gilk to Jeremy Bush
- Resolution set to fixed