In the midst of Xmas eve celebration, over at the Philippines Linux Users' Group mailing list someone is having trouble with HTTP headers. The scenario: John is getting complaints from a third party (I will call them the Grinch) accessing his HTTP host. The Grinch is getting HTTP 400 Bad request errors from John's Apache HTTP daemon. He found out that the Grinch is not sending a Host header along with a HTTP 1.1 request.
Examining RFC 2616 (Hypertext Transfer Protocol -- HTTP/1.1) section 5.1.2
(Request-URI) you can see that a HTTP 1.1 client must set the Host header:
The most common form of Request-URI is that used to identify a
resource on an origin server or gateway. In this case the absolute
path of the URI MUST be transmitted (see section 3.2.1, abs_path) as
the Request-URI, and the network location of the URI (authority) MUST
be transmitted in a Host header field. For example, a client wishing
to retrieve the resource above directly from the origin server would
create a TCP connection to port 80 of the host "www.w3.org" and send
the lines:
GET /pub/WWW/TheProject.html HTTP/1.1
Host: www.w3.org
If it is true that John's host did not do any reconfiguration obviously the Grinch is at fault here. A stock Apache 1.3.x or 2 HTTP daemon that speaks fluent HTTP 1.1 will expectedly spit out a HTTP 400 Bad request error when a client request omits the Host header field.
I found out an interesting excerpt in the HTTP 1.1 specification. It is about
handling absoluteURIs:
GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1
To allow for transition to absoluteURIs in all requests in future
versions of HTTP, all HTTP/1.1 servers MUST accept the absoluteURI
form in requests, even though HTTP/1.1 clients will only generate
them in requests to proxies.
Apache 1.3.x and 2 does not handle absoluteURIs by specification, it also returns a HTTP 400 Bad request error. Thttpd 2.25b is OK with absoluteURIs. I have yet to fully test Lighttpd, it seems to freeze on my custom headers.
0 comments:
Post a Comment