At 04:43 PM 10/30/2002, Bill Stoddard wrote: >> 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. >You've lost me.
3.2.3 URI Comparison ... *** Characters other than those in the "reserved" and "unsafe" sets (see RFC 2396 [42]) are equivalent to their ""%" HEX HEX" encoding. For example, the following three URIs are equivalent: http://abc.com:80/~smith/home.html http://ABC.com/%7Esmith/home.html http://ABC.com:/%7esmith/home.html *** "Other than those"??? That means, members of reserved and unsafe ARE NOT THE SAME VALUE as an %nn of the same characters. reserved = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+" | "$" | "," To explain the other bit, 'unsafe', we look to the errata; 'unsafe' characters Archive thread http://ftp.ics.uci.edu/pub/ietf/http/hypermail/1999/0273.html In the rules for comparison of URIs [section 3.2.3], it says: Characters other than those in the "reserved" and "unsafe" sets (see RFC 2396 [42]) are equivalent to their ""%" HEX HEX" encoding. but RFC 2396 has no definition of a character set called "unsafe". The paragraph should read: Characters other than those in the "reserved" set (see RFC 2396 [42]) are equivalent to their ""%" HEX HEX" encoding. This was an historical artifact. An earlier HTTP draft had defined a set of 'unsafe' characters, but they were characters that were not valid in a URI, so making a special case in the comparison rule was not needed.
