Project

General

Profile

Actions

Bug #1980

closed

conflict with RFC 2616 Section 5.2

Added by ycheng almost 15 years ago. Updated over 7 years ago.

Status:
Invalid
Priority:
Normal
Category:
core
Target version:
ASK QUESTIONS IN Forums:

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


Related issues 1 (0 open1 closed)

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

Updated by Olaf-van-der-Spek over 14 years ago

In what cases is this actually a problem?

Actions #2

Updated by peto over 14 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.

Actions #3

Updated by ycheng over 14 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?

Actions #4

Updated by Olaf-van-der-Spek over 14 years ago

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

Actions #5

Updated by gstrauss over 7 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).

Actions

Also available in: Atom