aborted is not always an error about pino-http

[mcollina]

@ronag this is where it is handled: https://github.com/pinojs/pino-http/blob/master/logger.js#L49-L53.

What do you propose? Would you like to send a PR?

[ronag]

I don't think there is a way in NodeJS to differentiate between client and server aborted. When the client aborts, printing an error with 418 is confusing.

[mcollina]

I don't think there is a way in NodeJS to differentiate between client and server aborted. When the client aborts, printing an error with 418 is confusing.

What do you mean?

[ronag]

@mcollina: There are two scenarios where an "aborted" event is emitted.

1. Server aborts due to server.timeout or req.socket.setTimeout. The current behaviour is correct for this case.
2. The client chooses to abort the request. The current behaviour is confusing for this case. It's not a timeout (408) and it's not an error for GET and HEAD requests.

[davidmarkclements]

Perhaps we can listen for a close event for detecting client abort...

Perhaps also veryifing by listening for a timeout on the server object for server side timeouts

[davidmarkclements]

although we're going to want to handle this in the most performant way of course..

@ronag can you point to a spec doc detailing a 408 not being an error for GET and HEAD ?

[ronag]

@davidmarkclements: A client aborting GET or HEAD is not a server error since they should be side effect free. (9.1.1 Safe Methods). Server aborting due to timeout should still be 408.

[ronag]

1. regardless of the method, a client aborting is not a timeout.
2. a client aborting a safe method is not a server error.

[mcollina]

@ronag I still do not know yet how to fix this, and what do you propose. Also, #21 was closed.
Would you like to submit a PR with unit tests? You investigated this issue with much more details than us.

[ronag]

@mcollina I don't know yet. nodejs/node#11014

[ronag]

@mcollina #22