Re: WWW Form Bug Report: "incorrect processing of percent-sign char encoding in URL" on SunOS 4.x

["Roy T. Fielding" <fi...@liege.ICS.UCI.EDU>]

> My best guess as to the source of this behavior is that code which got
> added to the server a ways back when for some reason Ben and David
> spent quite a bit of time hashing out what constituted an illegal URL,
> so we could reject it.  An encoded slash will specifically cause that
> code to bounce a request with a NOT_FOUND, even if it occurs in
> PATH_INFO.  (URLs with '%' signs which are not followed by two hex
> digits get a BAD_REQUEST).  See unescape_url in util.c.
> 
> Accepting encoded slashes only in PATH_INFO is unfortunately not an
> option, since unescape_url is invoked long before we can possibly know
> where in the submitted URL the PATH_INFO *starts*.
> 
> FWIW, this strikes me personally as being somewhat over-strict
> (remember, "be liberal in what you accept"), but in this case, I'll
> leave it to the judgment of the HTTP cop.

It depends on how we (or CGI) want to define PATH_INFO.  If it is
considered part of the URL path, then the %2f should be left encoded
and only the CGI can determine whether or not is is an error.
If it is considered part of a filename path, then Apache can treat
it as an error (for security reasons).

Assuming it is part of the URL path, then the server should leave the %2f
encoded.  Later in the process (after determination of what parts are
filesystem-based and what parts are virtual), the filesystem based part
should be checked for illegal things (like %2f).  GREAT care must be taken
to prevent any string from being unescaped twice.

In any case, the original user (I didn't save the address) is wrong.
The following two URLs are not equivalent:

       http://site/script/path1/path2
       http://site/script/path1%2fpath2

and at least one of them should result in an error from the script.

Reserved characters cannot be decoded without changing the meaning
of the URL.  If PATH_INFO is defined by CGI as being decoded by the
server, then the second URL above can only be treated as an error,
since there is no way for the server to say "here is a slash that
must not be treated as a slash" in a decoded path.

......Roy