/cc @bradfitz @tombergan per owners.

cc @fraenkel re http2

@jared2501 One question, now that you have created the context, what is going to use it?

I was using it in downstream handler code so that I can track the number of HTTP/2 streams that exist per HTTP/2 connection. I.e. I have some code like this:

type connStreamCounter struct{}

var connStreamCounterKey = connStreamCounter{}

func (e *Endpoint) trackStreamsPerConn(ctx context.Context, add bool) {
	strmCtr := ctx.Value(connStreamCounterKey).(*atomicInt64)

	if add {
		numStreams := strmCtr.Add(1)
		...
		return
	}

	numStreams := strmCtr.Add(-1)
	...
}

The reason for doing this is that we had an issue in production where a frontend web application was continually opening long-lived server streams, and never closing old streams. We then hit 250 open streams on a few of our HTTP/2 connections, which is the default max number before the http2.Server blocks accepting new streams. I would like to track this number so that I can monitor and alert on it.

@jared2501 If you have set the MaxConcurrentStreams, the client side should be getting a stream error.
I know that there is a lack of desire to expose the net.Conn underneath the h2 or h2c implementations. I would have to defer to @bradfitz for an alternative way to track streams per connection.
You might be able to get away with retrieving the LocallAddrContextKey to manage the streams for a given connection in your own map.

One thing to note that I would need the remote address, not just the local address, since the (local, remote) tuple fully identifies the connection. If I had this, then I could also achieve this goal so would also be happy with that solution.

But you do have the remote address via the Request.

@fraenkel ah you're totally right! So if I wanted to do this, I guess I could track this using a sync.Map.. It's not super ideal since A) I would have to do sync.Map read/writes for every request, and B) I wouldn't get notified when a connection ends so I wouldn't know when to clean up the counter.

@jared2501 You could use srv.ConnState() to track that, no?

@fraenkel The trouble is that once the HTTP/2 server takes over the ConnState will be StateHijacked, and so new HTTP/2 requests don't cause it to change.

Ah I guess you're saying that after the connection ends, the ConnState will transition from StateHijacked to StateClosed?

If so then yeah that's fine, we can close this ticket out

we're implementing an auth system which uses ConnContext to extract some per-connection information that is used later for auth purposes:

• when we receive a TCP connection, we do some expensive operations and store the result in the context to be used by all subsequent requests.
• This is currently being done via ConnContext for HTTP1, and it's working great, but doesn't work when we use an h2c handler with HTTP/2.

we'd like to help make this change and have a preliminary patch ready. would that be something folks here would consider?

Change https://go.dev/cl/419181 mentions this issue: http2/h2c: propagate HTTP/1 server configuration to HTTP/2