REWRITE: updated consensus wording

Due to comments from the WG, here is an update. The changes are as
follows:

1. This isn't really a replacement for all of 5.1.2; Jim Gettys already
posted another change for 
issues FULLURL and HOST that apply to this section. The real change is
the addition of the last 
paragraph; the rest of 5.1.2 is just here to give context for the
changes. (I've attempted to incorporate 
his changes for your reading pleasure, but Jim's placement of the text
he posted may differ from mine.)

2. The sentence that read

"(Proxies may canonicalize the Request-URI, according to the
canonicalization rules in section 3.2.2, for internal processing
puposes, e.g., for comparison of cache keys when doing cache lookups or
updates, but should not use this form in forwarded requests.)"

has been changed to

>"(Proxies may transform the Request-URI for internal processing
>puposes, but should not send such a transformed Request-URI  in
forwarded requests. Transformations for use in cache updates and lookups
>   are subject to additional requirements; see section TBD on caching.)"

in order to make it clear that what this section says is decoupled from
cache processing rules.
>
>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
>
>   To allow for transition to absoluteURIs in all requests in future
>versions
>   of HTTP, HTTP/1.1 servers must accept the absoluteURI form in
>requests, 
>   even though HTTP/1.1 clients will not normally generate them.
>   Versions of HTTP after HTTP/1.1 may require absoluteURIs everywhere,
>   after HTTP/1.1 or later have become the dominant implementations.

>   The absoluteURI form is required when the request is being made to
>   a proxy.  The absoluteURI form is only allowed to an origin server
>   if the client knows the server supports HTTP/1.1 or later.
>   If the absoluteURI form is used, any Host request-header included
>   with the request must be ignored. 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
>|   "abs_path" 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 transform the Request-URI for internal processing puposes,
>|   but should not send such a transformed Request-URI  in forwarded
|   requests. Transformations for use in cache updates and lookups
>|   are subject to additional requirements; see section TBD on caching.)
>|   The main reason for this rule is to make sure that the form of
>Request-URIs
>|   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 that
>|   some existing proxies do some rewriting.
>

Received on Wednesday, 3 April 1996 11:55:33 UTC