W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 1996

Re: proxies rewriting URLs

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
Message-Id: <9603101903.aa19480@paris.ics.uci.edu>
> 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
Received on Sunday, 10 March 1996 20:32:00 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:42:57 UTC