- From: <jg@w3.org>
- Date: Sun, 02 Jun 96 22:20:42 -0400
- To: Dave Kristol <dmk@allegra.att.com>
- Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
It turns out I was all wet; appropriate requirements on Host are in fact elsewhere in the document. I added some cross references to help. On a different note, in fact, I had misunderstood Roy in Palo Alto; he was happy with the requirement that 1.1 clients always sent Host, and that any 1.1 requrest without Host generate an error, but had problems how the requirements were stated so that Host would not have to be required in future versions. So, putting it all in my pipe and smoking it and Dave's comments, I get: 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. (But see section 19.5.1 for other requirements on Host support in HTTP/1.1.) 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. 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. 19.5.1 Changes to Simplify Multi-homed Web Servers and Conserve IP Addresses The requirements that clients and servers support the Host request-header, report an error if the Host request-header (section 14.23) is missing from an HTTP/1.1 request, and accept absolute URIs (section 5.1.2) are among the most important changes from HTTP/1.0. In HTTP/1.0 there is a one-to-one relationship of IP addresses and servers. There is no other way to distinguish the intended server of a request than the IP address to which that request is directed. The HTTP/1.1 change will allow the Internet, once HTTP/1.0 clients and servers are no longer common, to support multiple Web sites from a single IP address, greatly simplifying large operational Web servers, where allocation of many IP addresses to a single host has created serious problems. The Internet will also be able to recover the IP addresses that have been used for the sole purpose of allowing root-level domain names to be used in HTTP URLs. Given the rate of growth of the Web, and the number of servers already deployed, it is extremely important that implementations of HTTP/1.1 correctly implement these requirements: o Both clients and servers MUST support the Host request-header. o Host request-headers are required in HTTP/1.1 requests. o Servers MUST report a 400 (Bad Request) error if an HTTP/1.1 request does not include a Host request-header. o Servers MUST accept absolute URIs. Note that there used to be a claim at the beginning of the appendixes which said they were not normative; various normative material is now in the appendix (not just the Host requirements), and so that claim was removed.
Received on Sunday, 2 June 1996 19:23:18 UTC