Bug #1980

conflict with RFC 2616 Section 5.2

Added by ycheng over 11 years ago. Updated about 4 years ago.

Target version:


Line 439-445
439 if (request_check_hostname(ds->value)) {
440 TRACE (" Host header is invalid (Status: 400), was %s", SAFE_BUF_STR(ds->value));
441 con->http_status = 400;
442 con->keep_alive = 0;
444 return 0;
445 }

So if the host info in absoluteURI and in Host header are different, lighttpd will response 400.
But "RFC 2616 5.2 The Resource Identified by a Request" says:
If Request-URI is an absoluteURI, the host is part of the Request-URI, Any Host header field value in the request MUST be ignored.

I think lighttpd should not response 400.


Related issues

Has duplicate Bug #1937: Bad requestFixed2009-03-16Actions

Updated by Olaf-van-der-Spek about 11 years ago

In what cases is this actually a problem?


Updated by peto about 11 years ago

When clients expect servers to comply with the spec. I hope "because the spec says so" is a good enough reason to fix something, unless there's a compelling reason not to.

Patch changes the Host and URI parsing to do the following:

1: Parse headers, including Host; don't validate the results yet.
2: Validate that at least one Host header was received. Even if the host is being overridden by the URI, this check is still required.
3: Possibly, override the Host header from the URI.
4: Validate the final http_host only.

This also fixes a related issue: HTTP/1.1 requests with no Host: header at all to raise an error, even if a host is specified in the URI. (The spec requires this, and Apache follows this.)

This patch looks bigger than it is; most of it is just moving code around. req->uri_raw to con->request.orig_uri is moved to below header parsing; request_check_hostname is consolidated and moved after everything else.

This patch is locally tested but not production tested; this is a critical path, so please review it carefully.


Updated by ycheng about 11 years ago

like such a request


Though this is a rare case, it is legal indeed.

Olaf-van-der-Spek wrote:

In what cases is this actually a problem?


Updated by Olaf-van-der-Spek about 11 years ago

It might be legal but it doesn't make much sense.


Updated by gstrauss about 4 years ago

  • Status changed from New to Invalid

   A client MUST send a Host header field in all HTTP/1.1 request
   messages.  If the target URI includes an authority component, then a
   client MUST send a field-value for Host that is identical to that
   authority component, excluding any userinfo subcomponent and its "@" 
   delimiter (Section 2.7.1).

Also available in: Atom