-
-
Notifications
You must be signed in to change notification settings - Fork 278
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
expose information about negotiated connection settings #512
Comments
I'd be happy to work on this, but I'd love to get input on API design --- cc @seanmonstar. |
Seems reasonable. My first instinct is to add getters to |
Hmm, that was my initial thought as well. I suppose the downside is that the |
This PR adds accessors to `client::Connection` and `server::Connection` that return the send stream concurrency limit on that connection, as negotiated by the remote peer. This is part of issue #512. I think we probably ought to expose similar accessors for other settings, but I thought it was better to add each one in a separate, focused PR. Signed-off-by: Eliza Weisman <eliza@buoyant.io>
This commit adds accessors to `client::Connection` and `server::Connection` that return the current value of the `SETTINGS_MAX_CONCURRENT_STREAMS` limit that has been sent by this peer and acknowledged by the remote. This is analogous to the `max_concurrent_send_streams` methods added in PR #513. These accessors may be somewhat less useful than the ones for the values negotiated by the remote, since users who care about this limit are probably setting the builder parameter. However, it seems worth having for completeness sake --- and it might be useful for determining whether or not a configured concurrency limit has been acked yet... Part of #512
This commit adds accessors to `client::Connection` and `server::Connection` that return the current value of the `SETTINGS_MAX_CONCURRENT_STREAMS` limit that has been sent by this peer and acknowledged by the remote. This is analogous to the `max_concurrent_send_streams` methods added in PR #513. These accessors may be somewhat less useful than the ones for the values negotiated by the remote, since users who care about this limit are probably setting the builder parameter. However, it seems worth having for completeness sake --- and it might be useful for determining whether or not a configured concurrency limit has been acked yet... Part of #512
This commit adds accessors to `client::Connection` and `server::Connection` that return the current value of the `SETTINGS_MAX_CONCURRENT_STREAMS` limit that has been sent by this peer and acknowledged by the remote. This is analogous to the `max_concurrent_send_streams` methods added in PR #513. These accessors may be somewhat less useful than the ones for the values negotiated by the remote, since users who care about this limit are probably setting the builder parameter. However, it seems worth having for completeness sake --- and it might be useful for determining whether or not a configured concurrency limit has been acked yet... Part of #512
This commit adds accessors to `client::Connection` and `server::Connection` that return the current value of the `SETTINGS_MAX_CONCURRENT_STREAMS` limit that has been sent by this peer and acknowledged by the remote. This is analogous to the `max_concurrent_send_streams` methods added in PR #513. These accessors may be somewhat less useful than the ones for the values negotiated by the remote, since users who care about this limit are probably setting the builder parameter. However, it seems worth having for completeness sake --- and it might be useful for determining whether or not a configured concurrency limit has been acked yet... Part of #512
This PR adds accessors to `client::Connection` and `server::Connection` that return the send stream concurrency limit on that connection, as negotiated by the remote peer. This is part of issue hyperium#512. I think we probably ought to expose similar accessors for other settings, but I thought it was better to add each one in a separate, focused PR. Signed-off-by: Eliza Weisman <eliza@buoyant.io>
This commit adds accessors to `client::Connection` and `server::Connection` that return the current value of the `SETTINGS_MAX_CONCURRENT_STREAMS` limit that has been sent by this peer and acknowledged by the remote. This is analogous to the `max_concurrent_send_streams` methods added in PR hyperium#513. These accessors may be somewhat less useful than the ones for the values negotiated by the remote, since users who care about this limit are probably setting the builder parameter. However, it seems worth having for completeness sake --- and it might be useful for determining whether or not a configured concurrency limit has been acked yet... Part of hyperium#512
current implementation still does not return the remote max_send_streams.
|
@Yneth maybe it makes sense to use ready as a signal that the data is ready then use global getters that return an |
h2
currently permits configuring most of the HTTP/2 protocol settings that are negotiated with the remote peer; for example, the client builder can configure settings like maximum frame size, maximum concurrent streams, etc.However, once a connection is established, there's no way to access information about the settings that were negotiated with a remote peer, besides information about stream flow control. For example, in my particular use case, we would like to be able to record the max concurrent streams limit set by the server after initiating a client connection. It would be great to add some kind of API for querying connection-level settings that were received from a remote peer.
The text was updated successfully, but these errors were encountered: