Re: #38 - HTTP2 min value for server supported max_concurrent_streams

[William Chan (陈智昌) <[e-mail]>]

We always have to examine what the choices end up being for which parties.
If servers end up limiting parallelism, or requiring roundtrips to ramp up
parallelism, then clients which want speed (browsers) will be incentivized
to simply open up more connections to bypass the low parallelism limit or
slow start.

Overall, I think it's better to tolerate the minor suboptimality of having
servers RST_STREAM streams if they don't want so much parallelism, rather
than incentivize browsers to open more connections.




On Fri, Feb 22, 2013 at 2:19 PM, Yoav Nir <[e-mail]> wrote:

>
> On Feb 22, 2013, at 6:16 PM, Martin Thomson <[e-mail]>
> wrote:
>
> > On 22 February 2013 05:18, Roberto Peon <[e-mail]> wrote:
> >> Why 1?
> >
> > 1 seems a little restrictive, especially since 6 concurrent
> > connections is the current expectation in many browsers.
>
> Defaulting to 1 allows for a simple server that never has to handle
> multiple concurrent streams, one that can be implemented with much fewer
> lines of code, but is still compliant. Great for serving software updates,
> large files, CRLs, etc. Not so great for web pages.
>
> Other servers will quickly raise the limit via a SETTINGS frame.
>
> Yoav
>