W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > September to December 1998

Re: HTTP 1.1 issue 15: 14.23 Host

From: Jim Gettys <jg@pa.dec.com>
Date: Wed, 11 Nov 1998 08:28:33 -0800
Message-Id: <9811111628.AA30811@pachyderm.pa.dec.com>
To: "Roy T. Fielding" <fielding@kiwi.ics.uci.edu>
Cc: Ross Patterson <ROSSP@ss1.reston.vmd.sterling.com>, http-wg@hplb.hpl.hp.com

> >In section 14.23 "Host", the statements
> >
> >   "A client MUST include a Host header field in all HTTP/1.1 request
> >   messages on the Internet (i.e., on any message corresponding to a
> >   request for a URL which includes an Internet host address for the
> >   service being requested). 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. All Internet-based
> >   HTTP/1.1 servers MUST respond with a 400 (Bad Request) status code
> >   to any HTTP/1.1 request message which lacks a Host header field."
> >
> >can be interpreted to relax the requirement when requests are not
> >transiting the public Internet (e.g., between a client and server on a
> >departmental LAN). I believe the intent is to make HOST a required
> >request header whenever TCP/IP is the vehicle for the HTTP conversation.
> >If so, these statements should be clarified.
> 
> No, the existing wording is better because the requirement still holds
> even if the use of HTTP is over UDP, T/TCP, or any other future transport
> protocol.  The requirement relates to the meaning of identifier components
> and not to the transport protocol itself.  The reason for the implied
> relaxation is because it is possible to use HTTP on a transport that
> has no concept of hostnames (like between a PDA and its base station)
> and we don't want a separate specification of HTTP for every transport.
> 

Actually, Roy, I see Ross's point here: it says "on the Internet". Some 
might misinterpret this on a LAN or intranet.  I agree there should be 
no reference to TCP or other transport protocols in this paragraph, of 
course, for the reasons you give.

So I think striking the two phrases "on the Internet", and the word 
"Internet-based"  from the paragraph will reduce the wriggle room of 
implementers to get it wrong.  The result would be:


   "A client MUST include a Host header field in all HTTP/1.1 request
   messages (i.e., on any message corresponding to a
   request for a URL which includes an Internet host address for the
   service being requested). 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. All
   HTTP/1.1 servers MUST respond with a 400 (Bad Request) status code
   to any HTTP/1.1 request message which lacks a Host header field."

I don't think that any arguments to allow the host header to be dropped
for PDA use are compelling enough to relax this requirement in this way.

If it is relaxed at all, it might be relaxed in the following way:

  "A client MUST include a Host header field in all HTTP/1.1 request messages 
   on any message corresponding to a request for a URI which includes 
   an Internet host for the naming authority. All HTTP/1.1 servers MUST 
   respond with a 400 (Bad Request) status code to any such HTTP/1.1 request 
   message which lacks a Host header field. If the Host field is not already 
   present, an HTTP/1.1 proxy MUST add a Host field to such a request message 
   prior to forwarding it."

This would bring it in line with the draft standard URI specification 
as well, and make it clear that for other URL schemes which might also 
have a host name for the naming authority that we demand the host 
information, while making it clearer that for schemes that don't have 
a host name for a naming authority that we don't need a Host header.

What say you?
				- Jim
Received on Wednesday, 11 November 1998 16:28:46 EST

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