New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
proposal: x/net/http2: enable extension frame handling for HTTP/2 #40359
Comments
I would like to take the issue. Thanks! |
cc @fraenkel |
Change https://golang.org/cl/244478 mentions this issue: |
Change https://golang.org/cl/244800 mentions this issue: |
Can someone write down the additional API that is being proposed? That is, all the new exported names that would be added to the x/net/http2 package. Thanks. |
The new API include a reader interface which can be called by both servers and clients, a write interface called by servers and a write function called by clients. In addition, the PR also proposes an unknown frame info struct. // Server side usage: // Servers call WriteUnknownFrame writes unknown frames. // Clients call AddUnknownFrame to add an unknown frame to http.Request on the client side. This function can // UnknownFrameInfo is a struct to store unknown frame fields. // Flag to enable unknown frame handling |
There are four new operations required to support sending and receiving extension frames: Send and receive for client and server. Under this proposal:
There are some clear asymmetries in here. Clients pass frames via the request/response body, but the send API looks quite different from the receive one. Servers get an Incoming frames are added to an infinite buffer. This seems hazardous. Since there is no flow control on frames (AFAIK, I may be missing something here), I think it would be better to deliver incoming frames immediately to a callback. This does open the question of how to dispatch extensions frames received before the response. |
I wanted to pick this up. The main idea of this proposal relates to https://datatracker.ietf.org/doc/html/rfc9113#name-extending-http-2 allowing for adding new frame types but go http2 simply errors out https://cs.opensource.google/go/x/net/+/master:http2/transport.go;l=2322;bpv=1;bpt=1 This is how nghttp2 handles it as extensions https://nghttp2.org/documentation/programmers-guide.html#implement-user-defined-http-2-non-critical-extensions and it allows anyone to add a frame type. I will figure out a clean api and submit it for approval shortly. I just wanted to see what the community has to say about this proposal since it is almost a year old. |
At a high level, I think supporting user access extension frames seems reasonable. The question is what the API should look like. We have a medium-term project to fully merge We would like to support HTTP/3 in Buffering received frames is problematic without some form of limit on buffer growth. Capping the buffer size leaves the question of what to do when an extension is received when the buffer is full. I think a callback-based approach is going to work better, since it adds a natural pushback mechanism. A connection-level callback for unrecognized frames would be easy to implement. Associating frames with streams (requests) is harder. We could expose the stream id in requests somehow and leave it up to the user to figure out how to move the frame from the callback to the request handler; that's not the most ergonomic approach, but I don't have any better ideas at the moment. Sending frames has the interesting question of where to put the send-frame method. If frames are a connection-level concept, then a method on |
HTTP/2 library currently ignores HTTP/2 frames with an undefined type. The proposal is to enable the library to handle the extension frames. The change will enable HTTP/2 Go's feature parity to nghttp2 (a popular HTTP/2 library in c).
Requirement:
The text was updated successfully, but these errors were encountered: