Return 408 when a connection times out before headers arrive

[00200200]

Fixes #4447.

When Node times out a socket that never sent request headers (ERR_HTTP_REQUEST_TIMEOUT / HPE_HEADER_TIMEOUT), hapi's clientError handler answered with 400 Bad Request and left the connection open. Chrome commonly opens an extra idle connection after a successful request, so servers then logged a timeout as a bad request about a minute later.

Node's own default (with no clientError listener) is 408 Request Timeout plus Connection: close. This matches that behavior for the idle-socket case, while malformed requests still get 400.

Test plan

• New test: idle TCP connection with a short headersTimeout receives 408 and Connection: close, and does not emit a hapi response event
• Existing tests for parser failures before a request is set up still receive 400 Bad Request

[kanongil]

Thanks, but this is not the right solution.

The issue is not really the 408 vs 400 response code (or the connection: close header), but the internal logging of these errors. Something that this PR does not address.

[00200200]

@kanongil Ah, understood! I had kept this._log(['connection', 'client', 'error'], err) intact, but the main issue in #4447 is indeed the noisy error event emitted for normal idle browser connections.

If we omit this._log for these idle timeouts (ERR_HTTP_REQUEST_TIMEOUT / HPE_HEADER_TIMEOUT), should we also keep the silent 408 response, or do you have a specific alternative in mind?

[kanongil]

Sorry, not going to engage further on this drive-by PR.

[00200200]

Understood, thank you for your time and feedback.