- From: Roy T. Fielding <fielding@liege.ICS.UCI.EDU>
- Date: Sat, 01 Jun 1996 02:28:00 -0700
- To: jg@w3.org
- Cc: Paul Leach <paulle@microsoft.com>, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
> Note: This rule ensures that the form of Request-URI is well
> specified, to enable future extensions without fear that they will
> break in the face of some rewritings. One consequence of rewriting the
> Request-URI is that integrity or authentication checks by the server
> may fail. Implementers should be aware that some pre-HTTP/1.1 proxies
> have been known to rewrite the Request-URI."
The first two sentences are wrong, which is why I asked for them
to be deleted from the last draft. The "rule" referred to does not
do anything to impact how "well specified" is the Request-URI, it
does nothing to enable future extensions, and servers CANNOT depend
on it for integrity or authentication checks (that can only be done
when the URI is enclosed within a special parameter of the
authentication credentials) even with that paragraph in place.
The only thing the note should say is
Note: Implementers should be aware that some pre-HTTP/1.1 proxies
have been known to rewrite the Request-URI.
The purpose (and only purpose) of the "no rewrite" rule is to prevent
the proxy from changing the meaning of the request when the origin
server is improperly using a non-reserved URL character for a reserved
purpose. The reason we need it is simply because we cannot fix all
CGI scripts (or script authors) to do the right thing with the URI
syntax.
...Roy T. Fielding
Department of Information & Computer Science (fielding@ics.uci.edu)
University of California, Irvine, CA 92717-3425 fax:+1(714)824-4056
http://www.ics.uci.edu/~fielding/
Received on Saturday, 1 June 1996 02:38:17 UTC