- From: Roy T. Fielding <fielding@avron.ICS.UCI.EDU>
- Date: Sun, 10 Mar 1996 19:03:31 -0800
- To: Larry Masinter <masinter@parc.xerox.com>
- Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
> Apologies if this is clear in the text, but it didn't seem to be when
> I scanned 1.1. Some older proxies seemed to be modifying URLs, e.g.,
>
> if you
>
> GET http://foo.com/test#frob HTTP/1.0
>
> they might ask foo.com for
>
> GET /test%23frob HTTP/1.0
>
> or vice versa. Is there any reason to disallow this, and if so, what
> language would be put in the spec to disallow it; alternatively, if
> proxies might do this kind of transformation, what should we say?
Well, it's really a question of what should a proxy do when it
receives a syntactically invalid Request-URI. My preference is that
it make no changes whatsoever to the path part of the Request-URI
when it forwards the request. However, this would mean the proxy
would be sending a non-compliant request, which is also bad.
I guess that the best thing to include is a paragraph saying
A proxy may encode portions of the Request-URI prior to forwarding
the message if and only if such encoding is necessary to make the
message compliant with HTTP. Where possible, proxies should attempt
to use the same characters in the forwarded Request-URI as were
received from the client, since some servers improperly apply
special semantics to characters outside the "reserved" set.
Note, however, that "#" is never allowed in a Request-URI.
...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 Sunday, 10 March 1996 20:32:00 UTC