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

REWRITE: consensus

From: Paul Leach <paulle@microsoft.com>
Date: Sun, 31 Mar 1996 18:23:21 -0800
Message-Id: <c=US%a=_%p=msft%l=RED-77-MSG-960401022321Z-1206@red-05-imc.itg.microsoft.com>
To: "'http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com'" <http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/125
Here is a replacement for section 5.1.2, to close the issue of whether
proxies should rewrite URLs. The only change is the addition of the last
paragraph (marked with change bars); the rest of the section is here
just for context, and there may be other changes to it in resolution of
other issues.

This issue has been discussed on the list, so it is believed that this
represents the consensus on this issue. If you disagree, please let me
know; otherwise we will close this issue.
5.1.2 Request-URI

   The Request-URI is a Uniform Resource Identifier (Section 3.2) and 
   identifies the resource upon which to apply the request.

       Request-URI    = "*" | absoluteURI | abs_path

   The three options for Request-URI are dependent on the nature of 
   the request. The asterisk "*" means that the request does not apply 
   to a particular resource, but to the server itself, and is only 
   allowed when the Method used does not necessarily apply to a 
   resource. One example would be

       OPTIONS * HTTP/1.1

   The absoluteURI form is only allowed when the request is being made 
   to a proxy. The proxy is requested to forward the request and 
   return the response. If the request is GET or HEAD and a prior 
   response is cached, the proxy may use the cached message if it 
   passes any restrictions in the Cache-Control and Expires header 
   fields. Note that the proxy may forward the request on to another 
   proxy or directly to the server specified by the absoluteURI. In 
   order to avoid request loops, a proxy must be able to recognize all 
   of its server names, including any aliases, local variations, and 
   the numeric IP address. An example Request-Line would be:

       GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1

   The most common form of Request-URI is that used to identify a 
   resource on an origin server or gateway. In this case, only the 
   absolute path of the URI is transmitted (see Section 3.2.1, 
   abs_path). For example, a client wishing to retrieve the resource 
   above directly from the origin server would create a TCP connection 
   to port 80 of the host "www.w3.org" and send the line:

       GET /pub/WWW/TheProject.html HTTP/1.1

   followed by the remainder of the Full-Request. Note that the 
   absolute path cannot be empty; if none is present in the original 
   URI, it must be given as "/" (the server root).

   If a proxy receives a request without any path in the Request-URI 
   and the method used is capable of supporting the asterisk form of 
   request, then the last proxy on the request chain must forward the 
   request with "*" as the final Request-URI. For example, the request

       OPTIONS http://www.ics.uci.edu:8001 HTTP/1.1

   would be forwarded by the proxy as

       OPTIONS * HTTP/1.1

   after connecting to port 8001 of host "www.ics.uci.edu".

   The Request-URI is transmitted as an encoded string, where some 
   characters may be escaped using the "% hex hex" encoding defined by 
   RFC 1738 [4]. The origin server must decode the Request-URI in 
   order to properly interpret the request.

|   In requests that they forward, proxies MUST NOT rewrite the
|   part of a Request-URI in any way except as noted above to replace
|   a null abs_path with "*". Illegal Request-URIs should be responded
to with
|   an appropriate status code. (Proxies may canonicalize the
|   according to the canonicalization rules in section 3.2.2, for
|   processing puposes, e.g., for comparison of cache keys when doing
|   lookups or updates, but should not use this form in forwarded
|   The main reason for this rule is to make sure that the form of
|   is well specified, to enable future extensions without fear that
they will
|   break in the face of some rewritings. Another is that one
consequence of
|   rewriting the Request-URI is that integrity or authentication checks
by the
|   server may fail; since rewriting must be avoided in this case, it
may as
|   well be proscribed in general. Note: servers writers should be aware
|   some existing proxies do some rewriting.

Paul J. Leach            Email: paulle@microsoft.com
Microsoft                Phone: 1-206-882-8080
1 Microsoft Way          Fax:   1-206-936-7329
Redmond, WA 98052
Received on Monday, 1 April 1996 03:24:05 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:16 UTC