Summary: | Trailing Dots stripped from PATH_INFO environment variable | ||
---|---|---|---|
Product: | Apache httpd-2 | Reporter: | Corey Quinn <corquinn> |
Component: | mod_rewrite | Assignee: | Apache HTTPD Bugs Mailing List <bugs> |
Status: | ASSIGNED --- | ||
Severity: | normal | CC: | andersk, kerry, rodneyarauzs, ross.lawley |
Priority: | P3 | ||
Version: | 2.2.22 | ||
Target Milestone: | --- | ||
Hardware: | PC | ||
OS: | All | ||
URL: | Behind Firewall - see description |
Description
Corey Quinn
2003-05-19 14:37:20 UTC
The problem also strips off trailing dots from any path element: For example, if I call http://localhost/cgi-bin/test.exe/test./test./ PATH_INFO is only set to /test/test/ The same applies to PATH_TRANSLATED. In the source, I found the following in function apr_filepath_merge (filepath.c:626): /* Truncate all trailing spaces and all but the first two dots */ segend = seglen; while (seglen && (addpath[seglen - 1] == ' ' || addpath[seglen - 1] == '.')) { if (seglen > 2 || addpath[seglen - 1] != '.' || addpath[0] != '.') --seglen; else break; } So the stipping of trailing dots seems to be intentional for some reason, yet it was surely written for real file names, not additional information provided for the PATH_INFO variable. As a workaround, I am now using REQUEST_URI and stripping/decoding it appropriately, yet I still think this is a bug in Apache. The problem is still around in Apache 2.0.52, only on Win32, Netware and OS/2. Kerry W. Lothrop I believe that this behaviour is by design because Windows cannot differentiate between filenames like "foo." and "foo"; marking WONTFIX unless some Win32er can provide enlightenment. I still believe this to be a bug. I just stumbled across it again while trying to get my CGI application running under IIS. My workaround (using REQUEST_URI) doesn't work there since REQUEST_URI is not provided (it doesn't appear in the CGI specs either). However, PATH_INFO is set correctly there, even if a path element ends with a dot. I believe Apache should not strip the dots off PATH_INFO or PATH_TRANSLATED since the CGI application expecting the variables has no other way to figure out the actual request. The reporter might have a point here, because according to CGI 1.1 specification PATH_INFO is the "extra path information, _as given by the client_" (emphasis mine). Since in Windows "foo" and "foo." are roughly the same file, apache should have preserved the path information as given by the client. As for PATH_TRANSLATED, apache don't need to preserve the path information because it's a server provided translation (virtual-to-physical mapping) of PATH_INFO. 100% agreed with Davi's suggestion, PATH_TRANSLATED should clean up the information into canonical form, however PATH_INFO should not. I concur with the reporter that the PATH_INFO behavior is a bug. |