request_uri() creates a request_uri, either directly from apache or by using other values from the super global _SERVER array.
This method is designed to return an abs_path as per http://www.w3.org/Protocols/rfc2616/rfc2616-sec5.html#sec5.1.2 though as noted, proxies must use the absoluteURI form, and are not allowed to rewrite this.
This method blindly assumes that $_SERVER['REQUEST_URI'] returns abs_path and therefore things like form actions are created with urls such as /http://www.example.org/node/86
The enclosed patch checks $_SERVER['REQUEST_URI'] for the absoluteURI form, and then uses parse_url if required to create an abs_path, as expected
Comment | File | Size | Author |
---|---|---|---|
#4 | request_uri_5.patch | 932 bytes | AaronBauman |
request_uri.patch | 688 bytes | agentblueuk | |
Comments
Comment #1
agentblueuk CreditAttribution: agentblueuk commentedappears to be the same in 7.x-dev too
Comment #2
agentblueuk CreditAttribution: agentblueuk commentedComment #3
MichaelCole CreditAttribution: MichaelCole commentedrequest_uri.patch queued for re-testing.
Comment #4
AaronBaumanereg() is overkill (and deprecated in PHP 5.3+) -- stripos() is sufficient in this case.
rerolled @ HEAD, no other changes
Comment #5
Damien Tournoud CreditAttribution: Damien Tournoud commentedUgh. I wonder how that stayed unnoticed for so long. I guess that very few proxies are actually forwarding the request URI as an absolute URL. That said, we are clearly violating HTTP/1.1 here.
^ This is basically
substr($_SERVER['REQUEST_URI'], 0, 4) == 'http'
and should be rewritten this way (also, the if and the parenthesis must be separated by a space as per our coding standards). Anyone care to reroll?Comment #6
pukku CreditAttribution: pukku commentedIs there any news on this patch being accepted? Apparently, this needs to get into 7 before it can get into 6?
This bit me today.
Comment #7
Anonymous (not verified) CreditAttribution: Anonymous commentedI encountered the leading slash in form action uri with a Druapl 6 and Drupal 7 installation running in Windows 7 recently. My comment #4 in https://drupal.org/node/940470 gives another useable solution to the erroneous leading slash problem caused in the request_uri() function of the boostrap.inc include file.
My understanding is that the use of ltrim to remove the leading slash then prefix the resulting uri with another slash - regardless of whether the uri is an absolute or relative path - is the cause of the problem, and can be easily fixed with the use of preg_replace().