W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2013

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

From: (wrong string) 陈智昌 <willchan@chromium.org>
Date: Fri, 22 Feb 2013 14:36:04 -0800
Message-ID: <CAA4WUYhCLv5vv9tnm9TbYGaF5do-BzKNmuHv17XJ_GM7zFwSaA@mail.gmail.com>
To: Yoav Nir <ynir@checkpoint.com>
Cc: Martin Thomson <martin.thomson@gmail.com>, Roberto Peon <grmocg@gmail.com>, Osama Mazahir <OSAMAM@microsoft.com>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
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 <ynir@checkpoint.com> wrote:

> On Feb 22, 2013, at 6:16 PM, Martin Thomson <martin.thomson@gmail.com>
> wrote:
> > On 22 February 2013 05:18, Roberto Peon <grmocg@gmail.com> 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
Received on Friday, 22 February 2013 22:36:32 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:10 UTC