Project

General

Profile

Bug #1980

conflict with RFC 2616 Section 5.2

Added by ycheng over 10 years ago. Updated about 3 years ago.

Status:
Invalid
Priority:
Normal
Assignee:
-
Category:
core
Target version:
Start date:
2009-05-11
Due date:
% Done:

0%

Estimated time:
Missing in 1.5.x:

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.


Related issues

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

Actions

History

#1

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

In what cases is this actually a problem?

#2

Updated by peto about 10 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.

#3

Updated by ycheng about 10 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?

#4

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

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

#5

Updated by gstrauss about 3 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