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. |
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: