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

Let's be careful about this issue, because as we've noted many times
before, if the server can't leverage HTTP/2 to push streams, it is likely
to just inline resources directly, which is definitely worse.
Fundamentally, when the client issues a request, the server can send
anything it wants in the response. Defaulting to 0 would most likely
incentivize servers to to just inline resources, which is probably worse
than sending push streams to clients which don't want it (I assert that in
the open web, this should be a minority. If not, then HTTP/2 stream pushing
will have failed and people will just inline resources).

On Fri, Feb 22, 2013 at 1:02 PM, Gabriel Montenegro <
Gabriel.Montenegro@microsoft.com> wrote:

>  There is harm borne by the unwilling client receiver: battery and data
> allowance are not free.****
>
> ** **
>
> *From:* Roberto Peon [mailto:grmocg@gmail.com]
> *Sent:* Friday, 22 February, 2013 08:24
> *To:* Martin Thomson
> *Cc:* Osama Mazahir; ietf-http-wg@w3.org Group
> *Subject:* 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.****
>
>  ** **
>