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

[Cliff Skolnick <cl...@organic.com>]

--
Cliff Skolnick, CIO      http://www.organic.com/     cliff@organic.com
Organic Online, Inc.       ** we're hiring **           (415) 278-5650
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety." -- Benjamin Franklin, 1759

---------- Forwarded message ----------
Date: Wed Jun 26 19:58:04 1996
From: shandrew@leland.stanford.edu
To: cliff@organic.com
Subject: WWW Form Bug Report: "%2F and possibly other hex codes not translated correctly" on Solaris 2.x

Submitter: shandrew@leland.stanford.edu
Operating system: Solaris 2.x, version: 
Version of Apache Used: 1.1b4
Extra Modules used: 
URL exhibiting problem: http://www.apache.org/library%2Findex.html

Symptoms:
--
Pass apache a %2F in a URL, such as
http://www.apache.org/library%2Findex.html
and it doesn't get translated. 

%7E gets translated ok though.
--

Backtrace:
--

--

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.