Comments (7)
So I separated #732 into a couple of PRs. Now the part of setting a reasonable default value is moved to hyper. Here are the separated PRs:
from h2.
What do you mean by this? If what you mean is that the users of hyper should be able to configure the initial value of max send streams, then I think it's covered by the first bullet
Yes :)
I'm completely on board with the first point. Just saying that regardless of changing the default value, this option should be configurable in hyper
. So I see this as another improvement if we go down this route.
from h2.
This is a great write-up, thank you! I agree it makes sense to adjust the default. I only want to pause to make sure it's the right place to adjust the default.
It's worth calling out that for workloads where the server will NOT place a limit, changing this default here could be a negative. This would be places where both peers are trusted. My mind goes to things like linkerd2 proxies. (cc @hawkw @olix0r) The proper solution could actually be that those use cases should explicitly set a high initial value, instead of depending on the default, which perhaps should aim to protect the most common cases.
But I also vaguely feel like so far we've put those defaults in hyper or reqwest, and left h2
to simply implement the protocol, and otherwise not pick defaults.
from h2.
It makes sense that changing the default value could have a negative impact in a rare situation.
Actually, I opened an issue to here instead of to hyper (or reqwest) because I found that the client builder in h2 provides a way to set the initial MAX_CONCURRENT_STREAMS value while hyper doesn't. Plus, it looks like hyper doesn't set any value for initial MAX_CONCURRENT_STREAMS when constructing h2 client, thus ending up using the default value specified in h2, i.e. usize::MAX
.
So probably what we would like to do is:
- to have hyper provide a method on
hyper::client::conn::http2::Builder
that allows users to set the initial MAX_CONCURRENT_STREAMS value - to have hyper call
h2::client::Builder::initial_max_send_streams
when constructing h2 client with the user-configured value, if any.- If no value is configured by the user, set the reasonable default value i.e. 100.
- Or we could set the default value at one more upper level, i.e. reqwest.
- to have hyper_util provide a method on
hyper_util::client::legacy::Builder
that allows users to set the initial MAX_CONCURRENT_STREAMS value
I also feel that some changes still need to be made to h2, namely:
- improves the doc of
h2::client::Builder::initial_max_send_streams
to clearify that the default value isusize::MAX
- sets MAX_CONCURRENT_STREAMS to
usize::MAX
or whatever reasonable value (for example Go adopts 1,000) if the server's initial SETTINGS frame doesn't include MAX_CONCURRENT_STREAMS, assuming that the absence of MAX_CONCURRENT_STREAMS implies the server is willing to accept infinite number of concurrent streams- note that currently h2 keeps using the value set by
h2::client::Builder::initial_max_send_streams
if no specific value is supplied by the server
- note that currently h2 keeps using the value set by
Do these sound reasonable to you? If they do, I'd be happy to work on these :)
from h2.
But I also vaguely feel like so far we've put those defaults in hyper or reqwest, and left h2 to simply implement the protocol, and otherwise not pick defaults.
+1. h2
definitely should concern the protocol-level implementation only. The defaults should be in hyper
.
Having arbitrary defaults everywhere is also a nightmare to handle, so it's good that we're avoiding that.
to have hyper call h2::client::Builder::initial_max_send_streams when constructing h2 client with the user-configured value, if any.
This sounds like it should be exposed in hyper
from h2.
Thanks for your opinion @dswij.
This sounds like it should be exposed in hyper
What do you mean by this? If what you mean is that the users of hyper
should be able to configure the initial value of max send streams, then I think it's covered by the first bullet:
- to have hyper provide a method on hyper::client::conn::http2::Builder that allows users to set the initial MAX_CONCURRENT_STREAMS value
from h2.
Thanks a lot for doing that, your contributions have been wonderful to work with
from h2.
Related Issues (20)
- Panic due to the max headers capacity HOT 1
- `h2spec 2.6.0` tests are failling against `h2` HOT 3
- Settings frames are not applied correctly HOT 12
- Sending data frame results in transmission of more tcp segments than needed HOT 11
- Make tracing an optional feature
- Modifying the `akamai` example to send to `www.google.com` and adding a `host` header and errors HOT 2
- `max_send_buffer_size` documentation states default is 400 MB. It is 400 KB. HOT 2
- Remove tokio I/O traits from dependencies HOT 4
- http2 error: stream error received: unspecific protocol error detected HOT 4
- custom SETTINGS settings
- Documentation: How to handle GOAWAY HOT 2
- Respond with an HTTP 4xx than only a `RST_STREAM` to malformed requests HOT 2
- Default server configuration prevents the use of server pushes HOT 3
- /del i am retarded
- Memory leak caused by the long-lifespan trace_debug_span within the reused connection HOT 1
- Add option to disable connection preface
- :scheme & :path pseudo-headers are included in CONNECT requests. HOT 1
- Allow max_concurrent_reset_streams>0 on browser environments
- Allow disabling header compression HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from h2.