3 ms·

Ask HN: HTTP 1.0 and the host header

3 points by sigdante 11y ago

Would anybody know what the exact specification for the host header in a HTTP 1.0 context would be? Considering the header is not defined at all I would imagine that the following request should actually return a 400 due to an unknown header. GET / HTTP/1.0 Host: ahost In more RFC-like words, MAY a 1.0 request include a host header or MUST it NOT?

bruno2222 11y ago
Virtual Hosts on Apache and nginx see Host header value to properly process the request. Why are u asking? Are building a browser-client, a web server or a Crawler?
- sigdante 11y ago
  The question is not specific to any server but in regards to the specification. HTTP 1.0 does not define such a header so it should not be sent, and if it is I'd say there is a good reason to respond with a 400. Am I missing something?
dragonwriter 11y ago
Host is not specified in HTTP 1.0 (RFC 1945); HTTP/1.0 specifies that unrecognized headers are to be treated by the receiver as Entity Headers, which certainly is an explicit statement that unspecified headers are permitted. OTOH, since a server supporting only standard HTTP/1.0 won't know what a HOST header is (and will treat it as an Entity Header rather than what the client expects, which is a Request Header with very specific semantics), it doesn't make a lot of sense for a client to include Host in an HTTP/1.0 request unless it has out-of-band knowledge that the server supports HTTP/1.0 with some extension to handle the Host header. > Considering the header is not defined at all I would imagine that the following request should actually return a 400 due to an unknown header. I think the more common approach is just to ignore unrecognized Entity Headers, rather than returning a 400, so the result would more likely be identical to the result of the same request without the Host header (custom headers have always been a fairly common thing in HTTP, and it would break the web if they resulted in 400s when not recognized, rather than only when they are recognized by the server but make the request with them unfulfillable.) Unrecognized headers are not syntactically invalid, nor, AFAIK, are the usually treated as additional restrictions that cannot be satisfied.
- sigdante 11y ago
  Very elaborate response. Thank you. I am aware that the way I phrased it was rather strict. The reason for this is that I'd agree that such a request should possibly not be discarded straight away but should also not be processed by the "queue"/configuration specified by the host field but should rather - being a HTTP 1.0 request - exclusively default to the standard host. However Apache at least does not seem to agree on this and still processes 1.0 requests with a host field under/with the respective host configuration.
  - dragonwriter 11y ago
    An HTTP/1.0 server may recognize, and apply with its own semantics, non-standard headers. That flexibility is fairly key to the design of HTTP. So, Apache isn't wrong here. OTOH, a client can't expect that behavior with out-of-band information about server capabilities. So using the Host heater with HTTP 1.0 requests is a risky proposition.

3 points by sigdante 11y ago

bruno2222 11y ago

Virtual Hosts on Apache and nginx see Host header value to properly process the request. Why are u asking? Are building a browser-client, a web server or a Crawler?

sigdante 11y ago
The question is not specific to any server but in regards to the specification. HTTP 1.0 does not define such a header so it should not be sent, and if it is I'd say there is a good reason to respond with a 400. Am I missing something?

dragonwriter 11y ago

Host is not specified in HTTP 1.0 (RFC 1945); HTTP/1.0 specifies that unrecognized headers are to be treated by the receiver as Entity Headers, which certainly is an explicit statement that unspecified headers are permitted. OTOH, since a server supporting only standard HTTP/1.0 won't know what a HOST header is (and will treat it as an Entity Header rather than what the client expects, which is a Request Header with very specific semantics), it doesn't make a lot of sense for a client to include Host in an HTTP/1.0 request unless it has out-of-band knowledge that the server supports HTTP/1.0 with some extension to handle the Host header. > Considering the header is not defined at all I would imagine that the following request should actually return a 400 due to an unknown header. I think the more common approach is just to ignore unrecognized Entity Headers, rather than returning a 400, so the result would more likely be identical to the result of the same request without the Host header (custom headers have always been a fairly common thing in HTTP, and it would break the web if they resulted in 400s when not recognized, rather than only when they are recognized by the server but make the request with them unfulfillable.) Unrecognized headers are not syntactically invalid, nor, AFAIK, are the usually treated as additional restrictions that cannot be satisfied.

sigdante 11y ago
Very elaborate response. Thank you. I am aware that the way I phrased it was rather strict. The reason for this is that I'd agree that such a request should possibly not be discarded straight away but should also not be processed by the "queue"/configuration specified by the host field but should rather - being a HTTP 1.0 request - exclusively default to the standard host. However Apache at least does not seem to agree on this and still processes 1.0 requests with a host field under/with the respective host configuration.
- dragonwriter 11y ago
  An HTTP/1.0 server may recognize, and apply with its own semantics, non-standard headers. That flexibility is fairly key to the design of HTTP. So, Apache isn't wrong here. OTOH, a client can't expect that behavior with out-of-band information about server capabilities. So using the Host heater with HTTP 1.0 requests is a risky proposition.