William A. Rowe, Jr. wrote:
If Apache is going to decode the URI, then it should first split
>>the URI into path segments (an array) and then perform the decoding. >>Thus, you can make http://host/path/foo%2fbar/baz into ["path", >>"foo/bar", "baz"]. You can then encode each piece, and join them >>together with "/".
This is, in fact, the only way to handle this scenario.
um, no, i disagree, for reasons i just mentioned in reply to greg. you cannot reliably re-assemble the path-info because you cannot tell what transformations have been performed upon it. i have spent a lot of time on trying to figure out exactly what is suggested above, and have come up against that brick wall each time, in various forms.
> The decoded %2f should then be treated as invalid within > any apache file resource (dir_walk/file_walk) of which my proposal for the immediate term takes advantage. of course, if someone creates a file 'a%2fb' it should be accessible, and that would happen as well. > Since some folks are itching to cut apart the filesystem > from the request_rec, now seems like a golden opportunity > to play out how this new logic would work. cool. in the meantime, there is a need to allow %2f in path-info, which my patch addresses. i will post the patch directly; please examine it and actually *test* it before dismissing it out of hand as not a perfect solution. 'good enough' should be sufficient until perfection arrives. -- #ken P-)} Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/ Author, developer, opinionist http://Apache-Server.Com/ "Millennium hand and shrimp!"
