Re: Rev81: COMMENT: 5.2 The Resource Identified by a Request

jg@w3.org wrote:
  > 	I guess you are right...  I'm nervous about providing much
  > latitude here for implementers to get it wrong, but simplicity is
  > a virtue.  I think just by deleting the second sentence in bullet 1
  > "Any Host Header field value in the request MUST be ignored.", in concert with
  > what was bullet 3 applying all the time, we get the right effect with
  > minimum specification and confusion.  
  > 				-Jim

I don't agree that you've solved my problem.  See below.

  > 
  > Here is the revised section 5.2.
  > 
  > 5.2 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 value. 
  > 
  > If the Request-URI is not an absoluteURI and no
  > Host header field is present (or the field value does not represent a
  > valid host on that server), the response MUST be a 400 (Bad Request)
  > error message.
Note that for the non-absoluteURI case, we require that the
host be a valid one for the server, even if it doesn't differentiate
resources based on the host requested.  I think that's too strong.
  > 
  > 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 part of the Request-URI. 

But we've made no demand that it be valid.  So I could send
	GET http://dummy/real.html HTTP/1.1
and it would be acceptable.  But
	GET /real.html HTTP/1.1
	Host: dummy
would not be.
  > 
  > 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 value.
  > 
  > [...]

Now, depending on my mood, I could (and have) argue(d) either that the
host must be valid, or that it doesn't matter.  But I think the two
ways to represent the request, absoluteURI or via Host, should be
consistent in how they handle it.

So let me take a crack at 5.2.  I am trying to make these clarifications:
 
1) The request must either be an absoluteURI or have a Host header.

2) The value of the host requested specified either way matters only if
the server differentiates hosts.

3) If the server differentiates hosts, then the host, as determined from
either absoluteURI or Host, MUST be a valid one for the server.  (This
point can be dropped in the interests of flexibility by dropping Bullet
#3 below.)

5.2 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.  If the Request-URI is not an
absoluteURI and no Host header field is present, the response MUST be a
400 (Bad Request) error message.

An origin server that does not allow resources to differ by the
host requested MAY ignore the Host header field value.

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 to determine the host requested on an
HTTP/1.1 request:

  1. If Request-URI is an absoluteURI, the host is part of the Request-
     URI.  Any Host header field value in the request MUST be 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 value.
  3. If the host as determined by rule 1 or 2 is not a valid host on
     the server,  the response MUST be a 400 (Bad Request) error
     message.

Recipients of an HTTP/1.0 request that lacks 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.

Dave Kristol

Received on Friday, 31 May 1996 13:48:27 UTC