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

> I believe this is too restrictive.  An HTTP/1.1 client may send an
> absoluteURI to what it knows to be an HTTP/1.1 origin server.

No, it cannot do so.  I have already explained that several times.
The decision was that we would require acceptance of absoluteURIs
so that it would be possible for HTTP/2.0 to use them on requests
without first determining the origin server version.
That does not change the fact that HTTP/1.x is forbidden from using
them on requests to an origin server.

  >> 5.3  The resource identified by a request
> [This is 9.2 in Jim's rev57 draft.]
  >> 
  >>    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.
> 
> Because Host is unconditionally required, I believe the rules should
> read this way:
> 
> 1) If there is no Host header field present in the request, the server
> MUST respond with a 400 (Bad Request) error message.
> 
> 2) If Request-URI is an absoluteURI, the host is included in the
> Request-URI.  The Host header field in the request is ignored.
> 
> 3) If the Request-URI is not an absoluteURI, the host is determined by
> the Host header field.

I don't.  The reason for the prior ordering is because it allows
existing HTTP/1.1 servers to act correctly upon receipt of a
absoluteURI without any Host (I don't care about what the spec requires
here -- it is a simple question of robust behavior given the possibility
that future versions of HTTP will send an absoluteURI and no Host).


 ...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 Thursday, 2 May 1996 09:21:43 UTC