Re: WWW Form Bug Report: "%2F and possibly other hex codes not translated correctly" on Solaris 2.x (fwd)

[Paul Richards <p....@elsevier.co.uk>]

>>>>> "Chuck" == Chuck Murcko <ch...@telebase.com> writes:

Chuck> Shouldn't / not be allowed to be encoded?

Umm, you've misread that, it says that an octet that possibly could be
reserved in a scheme *should* be encoded.

>> From RFC 1738:

Chuck>    Reserved:

Chuck>    Many URL schemes reserve certain characters for a special
Chuck> meaning: their appearance in the scheme-specific part of the
Chuck> URL has a designated semantics. If the character corresponding
Chuck> to an octet is reserved in a scheme, the octet must be encoded.
Chuck> The characters ";", "/", "?", ":", "@", "=" and "&" are the
Chuck> characters which may be reserved for special meaning within a
Chuck> scheme. No other characters may be reserved within a scheme.

Chuck>    Usually a URL has the same interpretation when an octet is
Chuck> represented by a character and when it encoded. However, this
Chuck> is not true for reserved characters: encoding a character
Chuck> reserved for a particular scheme may change the semantics of a
Chuck> URL.


There's another snippet you should read:

        Servers may reject with error 404 any requests that would
        result in an encoded "/" being decoded into PATH_INFO or
        SCRIPT_NAME, as this might represent a loss of information to
        the script.

Apache explicitly checks for %2F and returns a 404. I've discussed this to
death with people at work who relied on NCSA behaviour where %2F was
decoded to '/' and all their scripts broke when they switched to Apache.

Reading that paragraph though I could never work out what the loss
of information could be if %2F was decoded.