- From: <jg@w3.org>
- Date: Fri, 29 Mar 96 18:10:02 -0500
- To: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
- Cc: klensin@mail1.reston.mci.net
To Roy's rewrite of 10.22 Host he circulated a while back (which looks pretty good to me), I've added a few other sentences in other sections, and drafted a section to the Changes from HTTP/1.0 appendix. This also resolves the FULLURL issue, so that we have a transition plan to full URL's in some future HTTP version. I believe this issue has been talked to death, so now is the time to complain about exact wording and/or nits. We must get this one so that no fool can misunderstand it. - Jim Gettys Add to section 5.1.2 Request-URI To allow for transition to absoluteURI's in all requests in future versions of HTTP, HTTP/1.1 servers must accept the absoluteURI form in requests, even though HTTP/1.1 clients will not likely normally generate them. Later HTTP versions (beyond HTTP 1.1) may require absoluteURI's everywhere, once HTTP 1.0 clients and servers are no longer in service. Change the sentence: The absoluteURI form is only allowed when the request is being made to a proxy. To: The absoluteURI form is required when the request is being made to a proxy. The absoluteURI form is only allowed to an origin server if the client knows the server supports HTTP/1.1 or later. Add the following sentence to Section 8. Method Definitions: Note that the Host request-header field (Section 10.22) must accompany HTTP 1.1 requests. Replace the current 10.22 with the following: 10.22 Host The Host request-header field specifies the Internet host and port number of the resource being requested, as obtained from the original http URL (Section 3.2.2) given by the user or referring resource. The Host field value must represent the network location of the origin server or gateway given by the original http URL. This allows the origin server or gateway to differentiate between internally-ambiguous URLs (such as the root "/" URL of a server harboring multiple virtual hostnames). Host = "Host" ":" host [ ":" port ] ; see Section 3.2.2 A "host" without any trailing port information is equivalent to a value of "host:80". For example, a request on the origin server for <http://www.w3.org/pub/WWW/> must include: GET /pub/WWW/ HTTP/1.1 Host: www.w3.org The Host header field must be included in all HTTP/1.1 request messages on the Internet (i.e., on any message corresponding to a request for an http URL, as described in Section 3.2.2). If the Host field is not already present, an HTTP/1.1 proxy must add a Host field to the request message prior to forwarding it on the Internet. If an HTTP/1.1 request message lacking a Host header field is received via the Internet by an origin server or gateway, that server must respond with a 400 status code. Note It is extremely important that HTTP/1.1 client implementations use the Host request-headers and server implementations both accept absoluteURI's and also report errors if Host request-headers are not recieved with HTTP/1.1 requests (see Appendix D.1). Add to Appendix D (Chagnes from HTTP/1.0: D.1 Changes to Simplify Vanity Web Servers and Conserve IP Addresses The requirements on clients and servers to support the Host request-header, report an error if the Host request-header is missing from an HTTP/1.1 request (Section 10.22), and accept absolute URI's (Section 5.1.2) are the most important changes from HTTP/1.0. In HTTP/1.0 there is a one to one relationship of IP addresses and servers, as there is no other way to disambiguate the server of a request than the IP address of that request. This change to HTTP 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 sites, where the routing 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 this purpose. 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 before deployment.
Received on Friday, 29 March 1996 15:16:32 UTC