At 02:52 PM 10/30/2002, Roy T. Fielding wrote: >Your patch will simply let the %2F through, but then a later section >of code will translate them to / and we've opened a security hole >in the main server. I'd rather move the rejection code to the >place where a decision has to be made (like the directory walk), >but I have no time to do it myself. I think it is reasonable to >allow %2F under some circumstances, but only in content handlers >and only as part of path-info and not within the real directory >structure.
That's the right idea... however it doesn't work. %2f is distinct from '/' - the rfc defines it as another character altogether. Because loc_walk, dir_walk and family all deal in parsed URIs, and we have a 256 character code page, there is no way to disambiguate the %2f from a '/'. If those families handled the unparsed URI we could do this with no problem, because they would be able to distinguish %2f from '/'. As long as we unparse first, we lose the distinction, and that's what opens up this flaw. Of course we should find a way to accept %2f in the query string, but never in the path (including path_info.) Bill
