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

Re: #40 - HTTP2 default value for client supported max_concurrent_streams

From: Roberto Peon <grmocg@gmail.com>
Date: Fri, 22 Feb 2013 08:23:59 -0800
Message-ID: <CAP+FsNcqu-AwNnijWcPyNZFWssEqo0b+sv61E09ZO=aFyzCNFQ@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Cc: Osama Mazahir <OSAMAM@microsoft.com>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
Yup, I understand that part. :)
I'm doing a poor job of pointing out that any harm done by doing something
like this is borne by the party doing it.
... so why mandate it-- if there turns out to be a positive benefit of
doing such a push in the future, fine.
I guess I'm attempting to argue that, unless we can figure out how this
causes harm/is likely to be done accidentally and cause issues, then it is
better to not say anything about it. Saying something about it creates a
spec with is more fragile.

-=R


On Fri, Feb 22, 2013 at 8:19 AM, Martin Thomson <martin.thomson@gmail.com>wrote:

> On 22 February 2013 05:29, Roberto Peon <grmocg@gmail.com> wrote:
> > What is the motivation for that?
>
> I'm not suggesting that this is Osama's motivation, but look at the
> Upgrade scenario: the server is the first to send on the HTTP/2.0
> session with a response.  There's an obvious opportunity there to push
> prior to the client SETTINGS frame arriving.  The TLS scenario is less
> interesting - the client sends SETTINGS prior to any request, making
> defaults non-interesting.
>
Received on Friday, 22 February 2013 16:24:27 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 22 February 2013 16:24:29 GMT