- From: <jg@w3.org>
- Date: Fri, 31 May 96 15:07:31 -0400
- To: Dave Kristol <dmk@allegra.att.com>
- Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
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 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. 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. 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. 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.
Received on Friday, 31 May 1996 12:11:19 UTC