W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 1996

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

From: <jg@w3.org>
Date: Sun, 02 Jun 96 22:20:42 -0400
Message-Id: <9606030220.AA08739@zorch.w3.org>
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 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:32:01 EDT