Bug #1980
closedconflict with RFC 2616 Section 5.2
Description
Request.c
http://redmine.lighttpd.net/projects/lighttpd/repository/entry/trunk/src/request.c
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;
443
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.
Files
Updated by Olaf-van-der-Spek over 15 years ago
In what cases is this actually a problem?
Updated by peto over 15 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 over 15 years ago
like such a request
GET http://www.foo.com/index.html HTTP/1.1
Host: www.goo.com
...
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 over 15 years ago
It might be legal but it doesn't make much sense.
Updated by gstrauss over 8 years ago
- Status changed from New to Invalid
https://tools.ietf.org/html/rfc7230#section-5.4
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