Bug Report #3001

Request::$uri changes based on the server.

Added by Mathew Davies almost 3 years ago. Updated almost 3 years ago.

Status:Closed Start date:06/24/2010
Priority:High Due date:
Assignee:Jeremy Bush % Done:

50%
Category:Core
Target version:v3.0.7
Resolution:fixed Points:

Description

Scenario 1.

You have a server with PATH_INFO and request the following URL:

http://example.com/ö

PATH_INFO will contain /ö and thus set Request::$uri to the same value.

Scenario 2.

This server doesn't have PATH_INFO, but REQUEST_URI. I request the same URL:

http://example.com/ö

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.

Decoded

  • PHP_SELF
  • DOCUMENT_URI
  • SCRIPT_NAME
  • PATH_INFO

Encoded

  • REQUEST_URI

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.

Related issues

related to Kohana v3.x - Bug Report #2680: Request::uri() should url-encode parameters v3.0.8 Closed 03/06/2010

Associated revisions

Revision c6b92e64
Added by Woody Gilk almost 3 years ago

Use rawurldecode() on the REQUEST_URI when using it in Request::instance, fixes #3001

History

#1
Updated by Woody Gilk almost 3 years ago

  • Assignee set to Woody Gilk

Would using urldecode on $_SERVER['REQUEST_URI'] fix this?

#2
Updated by Mathew Davies almost 3 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)

urldecode:

ö<space><space>

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.

#3
Updated by Woody Gilk almost 3 years ago

Perfect Mathew, that was exactly the comparison I needed.

#4
Updated by Mathew Davies almost 3 years ago

Just a note, this was running under nginx/0.8.41. Results could vary from server to server.

#5
Updated by Woody Gilk almost 3 years ago

I doubt the results would vary much, this is all RFC specification.

#6
Updated by Woody Gilk almost 3 years ago

  • Status changed from New to Needs Test
  • Assignee changed from Woody Gilk to Jeremy Bush
  • Resolution set to fixed

#7
Updated by Woody Gilk almost 3 years ago

  • % Done changed from 0 to 50

#8
Updated by Jeremy Bush almost 3 years ago

What was the reason for using REQUEST_URI as opposed to a "pre-decoded" value?

#9
Updated by Woody Gilk almost 3 years ago

The code in question tests for PATH_INFO,REQUEST_URI, and PHP_SELF to attempt to find the URI. Almost all servers will provide PATH_INFO.

#10
Updated by Woody Gilk almost 3 years ago

  • Status changed from Needs Test to Closed

I think this is also the same as #3001, just worded differently.

#11
Updated by Jeremy Bush almost 3 years ago

Ah, it helps if i look what around the changeset :)

btw, this is #3001 :)

Also available in: Atom PDF