Project

General

Profile

Feature #2885

Log error if Host name is illegal (e.g. contains an underscore)

Added by bwechner 26 days ago. Updated 23 days ago.

Status:
Wontfix
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
2018-04-29
Due date:
% Done:

0%

Estimated time:
Missing in 1.5.x:

Description

Relates specifically to:

https://redmine.lighttpd.net/boards/2/topics/8013

and:

https://redmine.lighttpd.net/issues/551

But the observation is that if an underscore appears in the Host: header line that lighttpd fails silently returning only:

ERROR 400: Bad Request

with no clue as to what is wrong. That cost me a day of diagnostics because of a lousy underscore.

I request that when that Bad Request result in a more detail line in the error log explaining why it's bad! At the very least if the Host name fails to adhere to convention, possibly listing the illegal characters.

History

#1

Updated by stbuehler 26 days ago

There is debug.log-request-header-on-error = "enable", although it's not clear to me why a separate debug flag is used for this; debug.log-request-handling should include this imho.

Also the error is very generic: "Invalid Hostname -> 400" - this could be improved.

#2

Updated by gstrauss 26 days ago

  • Category deleted (core)
  • Status changed from New to Wontfix
  • Target version deleted (1.4.x)
#3

Updated by gstrauss 26 days ago

stbuehler: debug.log-request-header-on-error has been around since the first commit to lighttpd 1.4 branch back in 2005: bcdc6a3b

#4

Updated by stbuehler 26 days ago

gstrauss wrote:

stbuehler: debug.log-request-header-on-error has been around since the first commit to lighttpd 1.4 branch back in 2005: bcdc6a3b

Doesn't mean it was a good idea or has to stay that way; we both didn't think about it when reading the config in the forum.

Also the debug output could certainly be improved; I think printing the invalid hostname and the reason why it is considered invalid would be helpful.

#5

Updated by gstrauss 26 days ago

we both didn't think about it when reading the config in the forum.

That's only because he corrupted his own detailed error report, posting $HTTP["host"] == "myhost.lan" instead of arachne_nova.lan (until a subsequent post)

I posted on IRC to you with the suggestion that maybe debug.log-request-handling = "enable" should enable debug.log-request-header-on-error. I do think this additional trace info should be with debug.log-request-header-on-error since the error is with the headers, so you likely need both headers and error message for complete context.

#6

Updated by bwechner 24 days ago

stbuehler wrote:

Doesn't mean it was a good idea or has to stay that way; we both didn't think about it when reading the config in the forum.

Also the debug output could certainly be improved; I think printing the invalid hostname and the reason why it is considered invalid would be helpful.

Agreed. I think there's room to improve the feedback here.

gstrauss wrote:

That's only because he corrupted his own detailed error report, posting $HTTP["host"] == "myhost.lan" instead of arachne_nova.lan (until a subsequent post)

True, but that doesn't invalidate the experience or that the refusal to respond to the invalid host name is a fatal error that should be logged IMHO with some clarification when it happens regardless of the log configs. It's likely to almost never happen, but when it does, helpful output that leads to resolution autonomously within minutes is pretty desirable.

#7

Updated by stbuehler 24 days ago

bwechner wrote:

[...], but that doesn't invalidate the experience or that the refusal to respond to the invalid host name is a fatal error that should be logged IMHO with some clarification when it happens regardless of the log configs. It's likely to almost never happen, but when it does, helpful output that leads to resolution autonomously within minutes is pretty desirable.

As gstrauss wrote in the forum:

Bad requests happen all the time on publicly facing servers. Do you run a high-capacity site that would lend some weight to that opinion of yours? tldr: You must enable the extra diagnostics if you want all that noise in your error log.

I fully agree with that statement; in general a server should imho only log things as error that indicate problems on the server, not on the client. It would be nice though if we had one debug flag to log all errors related to clients (bad requests, bad ssl stuff, connection aborts, timeouts, auth, ...); there shouldn't be more than one message per request generated this way though.

#8

Updated by bwechner 23 days ago

stbuehler wrote:

bwechner wrote:

[...], but that doesn't invalidate the experience or that the refusal to respond to the invalid host name is a fatal error that should be logged IMHO with some clarification when it happens regardless of the log configs. It's likely to almost never happen, but when it does, helpful output that leads to resolution autonomously within minutes is pretty desirable.

As gstrauss wrote in the forum:

Bad requests happen all the time on publicly facing servers. Do you run a high-capacity site that would lend some weight to that opinion of yours? tldr: You must enable the extra diagnostics if you want all that noise in your error log.

I fully agree with that statement; in general a server should imho only log things as error that indicate problems on the server, not on the client. It would be nice though if we had one debug flag to log all errors related to clients (bad requests, bad ssl stuff, connection aborts, timeouts, auth, ...); there shouldn't be more than one message per request generated this way though.

But surely if the host name is malformed the request never reaches the server? The instances where a malformed hostname reaches the server are surely very few, or? Am curious. I have found this one instance, where a DNS accepts _ in the host name, which is not valid. Given it's not valid, are there really lots of doamins out there with _ in them? Recalling that it is only names that a DNS supports that are not legal, that will ever reach the server, or?

Also available in: Atom