You can make use of the Cause apis to do that, context.WithDeadlineCause, context.WithCancelCause, context.WithTimeoutCause and so on, and then look at context.Cause for the cancellation cause.

You can make use of the Cause apis to do that, context.WithDeadlineCause, context.WithCancelCause, context.WithTimeoutCause and so on, and then look at context.Cause for the cancellation cause.

The idea of the proposal is to add cause for cases when context is canceled within standard library itself. And yes it can be accomplished with context.WithCancelCause and context.WithTimeoutCause.

This would be very useful. Nowadays, when I see that a request failed due to context canceled, I have no idea happened. It could be a timeout on a SQL query, some internal request, etc. And if the context was canceled, because the client closed the connection (which happens in (*connReader).backgrounRead() -> cr.handleReadError(err), as far as I'm able to tell), I'd like to be able to distinguish it and not log it as an error.

cc @neild

I'd like to work on this. I haven't contributed before, but I think this could be a good first issue and I'm running into it.

My proposal would be to change net/http.conn.cancelCtx into a context.CancelCauseFunc. Any callers now need a cause error, which I believe can be any error. This would be backwards compatible, since the ctx.Err() still returns context.Canceled, but the context.Cause() now newly returns the error from net.http. (Only implementations that were depending on context.Cause() also returning context.Canceled might break. Would this be considered acceptable?

conn.cancelCtx() is called in three places:

• deferred by serve(), where I would use a newly defined net/http.ErrConnectionHandled. I assume here that calling the CancelCauseFunc multiple times is a no-op, and the first cause is kept.
• handleReadError from the background reader, where I would use a newly defined net/http.ErrConnectionClosed if the read error was io.EOF, and the read error otherwise (suggestions welcome?)
• Write() from the checkConnErrorWriter, which I believe is used to check whether we can re-use existing HTTP connections, so I don't think the cause matters, here; the cancelCtx() is only called for cleanup (needs a double-check).

Feedback is welcome. In the meantime, I'll be following the contribution guide.

Change https://go.dev/cl/636235 mentions this issue: net/http: add context cancellation reason for server handlers

Mainly, I believe this proposal requires consensus about the following three net/http contract/API changes:

1. When a server handler context is cancelled by net/http, the Cause was set to the default context.Canceled, but now it is set to a more specific error. (The context Error remains set to context.Canceled, as always.)
2. The newly exposed http.ErrConnectionClosed is used when the client closed the connection between end of request and the server handler return.
3. The newly exposed http.ErrRequestHandlerReturned is used when the server handler returned.