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: Ross Patterson <ROSSP@SS1.Reston.VMD.Sterling.COM>
Date: Wed, 11 Nov 98 12:04:38 EST
Message-Id: <199811111716.RAA22270@hplb.hpl.hp.com>
To: http-wg@hplb.hpl.hp.com
Cc: fielding@kiwi.ics.uci.edu, jg@pa.dec.com

"Roy T. Fielding" <fielding@kiwi.ics.uci.edu> writes:

>>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.

That's exactly where I was going, although using "TCP/IP" was a poor
choice.  (I meant something like "any protocol that flows data over a
network where said network understands the concept of a 'hostname'", but
that would have pegged the Obfusco-Meter).  In the case of
HTTP-over-SNA, a Host header would look very different, if it could
exist at all.  Certainly other transports could have similar issues.

My concern wasn't over the relaxation of the requirement when using
transports that don't have a "hostname" concept, but rather the way it
was written up.  I also wasn't sure if this was an intentional
relaxation - the statement in section 9 "Method Definitions" is
unequivocal:

   "The Host request-header field (section 14.23) MUST accompany
   all HTTP/1.1 requests."

If the relaxation is intentional, then section 9 is in error.

Ross Patterson
VM Software Division
Sterling Software, Inc.
Received on Wednesday, 11 November 1998 17:17:03 EST

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