- From: Roy T. Fielding <fielding@kiwi.ics.uci.edu>
- Date: Wed, 11 Nov 1998 14:11:13 -0800
- To: Jim Gettys <jg@pa.dec.com>
- Cc: Ross Patterson <ROSSP@ss1.reston.vmd.sterling.com>, http-wg@hplb.hpl.hp.com
>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.
Yes, either that or
A client MUST include a Host header field in all HTTP/1.1 request
messages. If the requested URI does not include an Internet hostname
for the service being requested, then the Host header field MUST be
given with an empty value. An HTTP/1.1 proxy MUST ensure that any
request message it forwards does contain an appropriate Host header
field that identifies the service being requested by the proxy.
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.
Both will give people doing things like name-to-location resolution via
HTTP some guidance.
....Roy
Received on Wednesday, 11 November 1998 14:40:15 UTC