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

[Amos Jeffries <[e-mail]>]

On 23/02/2013 10:29 a.m., William Chan (陈智昌) wrote:
> 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).

Sorry I just parsed that as a re-wording of "if it turns out the 
majority of clients disable push we can consider it failed and servers 
will just do it via inlining anyway."

If that is the case, why are sites not already inlining _all_ of their 
page content and pushing it on first contact from any client. The answer 
should be obvious that it is a waste of resources for both client and 
server to do this at all on any large scale. Although, that said I'm 
still fielding questions about how to pre-cache entire sites like 
facebook and google :-( there will always be idiots whatever gets specified.

Amos

>
> On Fri, Feb 22, 2013 at 1:02 PM, Gabriel Montenegro 
> <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     There is harm borne by the unwilling client receiver: battery and
>     data allowance are not free.
>
>     *From:*Roberto Peon [mailto:[e-mail]
>     <mailto:[e-mail]>]
>     *Sent:* Friday, 22 February, 2013 08:24
>     *To:* Martin Thomson
>     *Cc:* Osama Mazahir; [e-mail]
>     <mailto:[e-mail]> 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
>     <[e-mail] <mailto:[e-mail]>> wrote:
>
>         On 22 February 2013 05:29, Roberto Peon <[e-mail]
>         <mailto:[e-mail]>> 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.
>
>