What is REQUEST_URI supposed to be?
While evaluating Gallery, I noticed that my test web server generates wrong links inside the web application. After getting some help on the Gallery Forum, I was told that this was because my setup was miscreating REQUEST_URI to contain the entire URI, consisting of scheme, host name and path, while Gallery expects that variable to be only the path portion of the URI.
Since REQUEST_URI is fine when I ask the web server running the application directly from the host in question, while accessing it from my local machine through an ssh tunnel (since the application web server is not going to be publicly visible on the Internet) yields the full URI in REQUEST_URI
Unfortunately, neither is the PHP Documentation especially verbose (it just says that REQUEST_URI is "The URI which was given in order to access this page; for instance, '/index.html'.") nor is the apache documentation formally defining REQUEST_URI (the closest to a definition being the documentation for mod_setenvif, which says that REQUEST_URI is "generally the portion of the URL following the scheme and host portion without the query string").
Did I miss a more formal documentation of apache/PHP's behavior? Pointers appreciated.
While I was writing this blog entry, which was a lot more angry in its first version, the Gallery guys finally acknowledged that apache and PHP are not sufficiently specifying REQUEST_URI and that I have delivered a valid example where there is a host part in REQUEST_URI. They're going to work around this. Good news, thanks!
The promised fix is in gallery2 svn, I have applied the patch to my local version, and the application is fine now. Thanks!
Comments to this article were closed in July 2012, this article is getting an obscene amount of spam
Trackbacks
No Trackbacks
The author does not allow comments to this entry
Comments
Display comments as Linear | Threaded
kju on :
Another example of idiots at work. My naive mind would expect to find a URI in a variable called REQUEST_URI. But a real URI needs to contain a scheme and hostname as per RFC2396.
I also would expect that a parser using a variable with such a name is able to cope with a actual provided scheme and host in the content. Even if PHP is so broken to provide a non-URI in a variable named REQUEST_URI.
Blame both sides. Clear violation of "Be Liberal in What You Accept, Conservative in What You Send". And one more example that the Web is still full of outdated technology and nuisances. See https for another example.
-thh on :
Gallery was the application with more remote holes then phpbb, right? eg
jdh on :
I would guess that perhaps the REQUESTURI variable is coming straight from the address specified in GET, i.e. your browser is perhaps sending GET http://host/uri or GET /uri depending on which way you connect. You could try using telnet or netcat to send the request by hand and see what the resulting value of REQUESTURI is, if you care what's making the difference instead of just about fixing the bug.
P.S. Your anti-spam verification seems to hate Konqueror, since I tried three times and got an error message before trying Firefox.