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

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.
>