Re: EDITS for Section 5 (Request) (Was: Re: 5.1.2 Request-URI)

The edits suggested by Koen were not quite correct, and did not fix the
problem I identified with the changes to draft 02 being in the wrong place.

Here is another rewrite of those sections:

Note: Use of underscores for character highlighting is not allowed in RFCs.
      Anything like _*_ must be generated as "*" in the text draft.

.......Roy
=======================================================================
Corrected 5.1.2, with change bars:


    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 required when the request is being made to a
|   proxy. The proxy is requested to forward the request or service it
|   from a valid cache, and return the response.
|   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

    To allow for transition to absoluteURIs in all requests in future
|   versions of HTTP, all HTTP/1.1 servers MUST accept the absoluteURI
|   form in requests, even though HTTP/1.1 clients will only generate
|   them in requests to proxies.  The Host request-header field MUST
|   be ignored in requests using an absoluteURL as the Request-URI.

    The most common form of Request-URI is that used to identify a
|   resource on an origin server or gateway. In this case, the absolute
|   path of the URI (see Section 3.2.1, abs_path) MUST be transmitted 
|   as the Request-URI, and the network location of the URI (net_loc)
|   MUST be transmitted in a Host header field. 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 lines:

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

    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
|          Host: www.ics.uci.edu:8001

    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 purposes, but SHOULD NOT send such a transformed
|   Request-URI in forwarded requests.
|
|      Note: The main reason for this rule is to make sure that
|      the form of the Request-URI is well specified and 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.
|      Implementors should be aware that some HTTP/1.0 proxies
|      do rewrite the Request-URI.


================
5.3  The resource identified by a request

   HTTP/1.1 origin servers SHOULD be aware that the exact resource
   identified by an Internet request is determined by examining both
   the Request-URI and the Host header field.  An origin server that
   does not allow resources to differ by the requested host MAY ignore
   the Host header field.  An origin server that does differentiate
   resources based on the host requested (sometimes referred to as
   virtual hosts or vanity hostnames) MUST use the following rules
   for determining the requested resource on an HTTP/1.1 request:

   1. If Request-URI is an absoluteURI, the host is included in the
      Request-URI.  Any Host header field in the request is ignored.

   2. If the Request-URI is not an absoluteURI, and the request includes
      a Host header field, the host is determined by the Host header
      field.

   3. If the request-URI is not an absoluteURI and no Host header field
      is present (or does not represent a valid host on that server),
      the response SHOULD be a 400 (Bad Request) error message.

   Recipients of an HTTP/1.0 request lacking a Host header field MAY
   attempt to use heuristics (e.g., examination of the URI path for
   something unique to a particular host) in order to determine what
   exact resource is being requested.

Received on Tuesday, 30 April 1996 20:00:21 UTC