Double urldecode causes problems with filenames that have % or +Description:
------------
I am working on a script which allows browsing a filesystem. I noticed that when requesting filenames that contained a certain combination of characters (notably %40 or +), the file name presented to my application had been modified. This is not a mistake: the file names themselves had a character sequence which could be mistaken for a urlencoded string.
After researching, I found that that Server.php contained a call to urldecode the $_SERVER['PATH_INFO'] string. Because the CGI1.1 specification[1] requires that the HTTP server present an already decoded URL to the controlling script, this is causing a double decoding of PATH_INFO and thus the request becomes invalid.
My suggestion would be to remove the _urldecode() function (starting at line 1971) and the call to _urldecode($path_info) on line 155 in the ServeRequest() method of Server.php. This is the only place in Server.php that _urldecode() is called. The call to urldecode() should also be removed from line 1470 in the _copymove() method.
[1]: http://hoohoo.ncsa.uiuc.edu/cgi/env.htmlbklang
bklanghttp://pear.php.net/bugs/12283
HTTP_WebDAV_Server Bug
Reported by bklang
2007-10-19T11:07:24+00:00
PHP: Irrelevant OS: All Package Version: 1.0.0RC4
Description:
------------
I am working on a script which allows browsing a filesystem. I noticed that when requesting filenames that contained a certain combination of characters (notably %40 or +), the file name presented to my application had been modified. This is not a mistake: the file names themselves had a character sequence which could be mistaken for a urlencoded string.
After researching, I found that that Server.php contained a call to urldecode the $_SERVER['PATH_INFO'] string. Because the CGI1.1 specification[1] requires that the HTTP server present an already decoded URL to the controlling script, this is causing a double decoding of PATH_INFO and thus the request becomes invalid.
My suggestion would be to remove the _urldecode() function (starting at line 1971) and the call to _urldecode($path_info) on line 155 in the ServeRequest() method of Server.php. This is the only place in Server.php that _urldecode() is called. The call to urldecode() should also be removed from line 1470 in the _copymove() method.
[1]: http://hoohoo.ncsa.uiuc.edu/cgi/env.html]]>HTTP_WebDAV_Server Bug
Reported by bklang
2007-10-19T11:07:24+00:00
PHP: Irrelevant OS: All Package Version: 1.0.0RC4
Description:
------------
I am working on a script which allows browsing a filesystem. I noticed that when requesting filenames that contained a certain combination of characters (notably %40 or +), the file name presented to my application had been modified. This is not a mistake: the file names themselves had a character sequence which could be mistaken for a urlencoded string.
After researching, I found that that Server.php contained a call to urldecode the $_SERVER['PATH_INFO'] string. Because the CGI1.1 specification[1] requires that the HTTP server present an already decoded URL to the controlling script, this is causing a double decoding of PATH_INFO and thus the request becomes invalid.
My suggestion would be to remove the _urldecode() function (starting at line 1971) and the call to _urldecode($path_info) on line 155 in the ServeRequest() method of Server.php. This is the only place in Server.php that _urldecode() is called. The call to urldecode() should also be removed from line 1470 in the _copymove() method.
[1]: http://hoohoo.ncsa.uiuc.edu/cgi/env.html]]>2007-10-19T11:07:24+00:00
hholzgra [2008-04-22 21:55] http://pear.php.net/bugs/12283#1208901356
This bug has been fixed in CVS.
If this was a documentation problem, the fix will appear on pear.php.net by the end of next Sunday (CET).
If this was a problem with the pear.php.net website, the change should be live shortly.
Otherwise, the fix will appear in the package's next release.
Thank you for the report and for helping us make PEAR better.]]>This bug has been fixed in CVS.
If this was a documentation problem, the fix will appear on pear.php.net by the end of next Sunday (CET).
If this was a problem with the pear.php.net website, the change should be live shortly.
Otherwise, the fix will appear in the package's next release.
Thank you for the report and for helping us make PEAR better.]]>2008-04-22T21:55:56+00:00