Lighttpd

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.

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

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.

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.

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.

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.

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?