What version of Go are you using (go version)?

$ go version 1.19

Does this issue reproduce with the latest release?

N/A

What operating system and processor architecture are you using (go env)?

$ go env all

What did you do?

A related RFC chapter mentions this:

RFC 7540
Stream identifiers cannot be reused. Long-lived connections can
result in an endpoint exhausting the available range of stream
identifiers. A client that is unable to establish a new stream
identifier can establish a new connection for new streams. A server
that is unable to establish a new stream identifier can send a GOAWAY
frame so that the client is forced to open a new connection for new
streams.

Based on http2 RFC, from client site, when the request send out, if stream id larger then 2^31, our http2 lib will see it as invalid strream id , and return errStreamId. But it is seem that there is no additional processing for errStreamId in our http2 lib or in h2_hundle. So how client to known streamID exhausted so that it can request new connection? and legacy connection could not be shutdown by client or server, because legacy stream id still can be mantain.

Is it possible to run into a problem where HTTP2 connections where the stream id is exhausted (more than 2^31). Another words , errStreamID will be triggerd.
like this:
https://github.com/golang/net/blob/daac0cec0cf964a628a29bb4b82940c225b921ed/http2/frame.go#L1097
but not return errStreamID to werr, so werr is nil
https://github.com/golang/net/blob/daac0cec0cf964a628a29bb4b82940c225b921ed/http2/transport.go#L1637

So I feel confuse how to handle the errStreamID , and I try to test by myself by use http2 client/server echo module, which stream id is 1 ,and manually modify the code like this

func (f *Framer) WriteHeaders(p HeadersFrameParam) error {
	//if !validStreamID(p.StreamID) && !f.AllowIllegalWrites {
	//	return errStreamID
	//}
	return errStreamID

I find the client do not send any tcp connection request by capture fream used wireshark, and the code blocked at function of read in pipe.go, maybe my observations are limited.
client used :
https://github.com/posener/h2conn/blob/master/example/echo/client.go#L35

What did you expect to see?

May golang 's http2 lib do not support this ? if want to implement about stream id exhausted. client have to mantain stream id by itself, not rely on http2 lib, if stream id exhaust, client should request a new connection.

What did you see instead?

http2 lib's next stream id should transfer to application level and application should mantain the stream Id, if applicaiotn knows next stream id is larger then 2^31, it will request a new conneciton by a new port.