search

hyperium / hyper

An HTTP library for Rust
https://hyper.rs
MIT License
14.36k stars 1.58k forks source link

access to SETTINGS frame as received from client for HTTP/2 connection #2887

Open GlenDC opened 2 years ago

GlenDC commented 2 years ago

Is your feature request related to a problem? Please describe.

I can currently not get access (AFAIK) to the settings as received in the SETTINGS frame by the HTTP/2 client.

https://httpwg.org/specs/rfc7540.html#rfc.section.6.5.2

Describe the solution you'd like

Ability to listen for these somehow such that this information is known and can be acted upon.

Describe alternatives you've considered

I do not see alternatives, I need this information,

seanmonstar commented 2 years ago

I think we could fairly easily make the common registered settings be getters on the connection struct, but it would be harder to expose unregistered settings, unless we came up with a proposal to do so in a forwards compatible way.

GlenDC commented 2 years ago

I imagine we could expose them as an Enum, where we have an Unknown(u16) identifier for the unknown settings? Similar to how rustls exposes internally properties in regards to things such as their ClientHello properties.

Furthermore the client (builder) already allows to set some settings, but not all. I imagine that it could be possible to underlying make it more of a generic solution where such solutions are stored as send, such that we can also allow any other setting to be defined with the client builder. And again respecting client order.

And than the other aspect would be as discussed earlier where we would also want to be able to have observability over these incoming frames. It's for sure a very low-level and specialised use case, but I cannot imagine that I'm the only one who would want to have more fine grained control over the incoming frames where desired, and in the end you anyway already process and observe these incoming frames, it's just not something exposed to the user of hyper in any way possible.

So there are two different efforts/issues discussed above. There is also a third issue/effort that can be added to the list and that is to be able to choose in what order frames are send, at least the initial ones.

Again I think that having the API and defaults as it is currently is good for most use cases. But I don't think that there is really much said against not exposing the more lower level primitives here. The only other option would be to maintain my own fork of Hyper, or not use Rust at all, neither are very desirable.

Of course I do not want to put any burden on you here, or bring the crate out of scope. I do however see possibilities how we can facilitate these without really impacting existing users or ergonomics of the crate.