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: 陈智昌 <willchan@chromium.org>
Date: Wed, 6 Mar 2013 14:31:43 -0800
Message-ID: <CAA4WUYjsbtR3QvPShWb3F-_F4E_FB7hjRrV3oPBN8wFg+OLg1A@mail.gmail.com>
To: "DRUTA, DAN" <dd5826@att.com>
Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Having the client to send a hint/signal to inform the server that the
server should not push resources (whether it be via resource inlining or
HTTP/2 server push) should not be conflated with the issue at hand: the
default value for the client's max_concurrent_streams limit. I think that
if you want to advertise/negotiate this, then you should propose a separate
mechanism for doing so.


On Wed, Mar 6, 2013 at 2:19 PM, DRUTA, DAN <dd5826@att.com> wrote:

>  *I agree with Gabriel** and the use cases he described**. *
>
> *Mobile clients still **run in more constraint environments and the
> ability to **negotiate **with the server** not to **use inlining even
> when server push is disabled** is quite important from user experience
> point of view.** When I request updated weather forecast on my phone I
> care less about the pretty sun image and more about the **actual
> forecasted temperature.*
>
> *Some form of a hint **should be sent to the server in that case** **with
> the **initial** request.*
>
> *Dan** Druta*
>
> *From*: Gabriel Montenegro <*Gabriel.Montenegro@microsoft.com*<Gabriel.Montenegro@microsoft.com?Subject=RE%3A%20%2340%20-%20HTTP2%20default%20value%20for%20client%20supported%20%20max_concurrent_streams&In-Reply-To=%253CCA566BAEAD6B3F4E8B5C5C4F61710C1163AAA591%40TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com%253E&References=%253CCA566BAEAD6B3F4E8B5C5C4F61710C1163AAA591%40TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com%253E>
> >
> *Date*: Sun, 24 Feb 2013 01:23:04 +0000
> *To*: William Chan (陈智昌) <*willchan@chromium.org*<willchan@chromium.org?Subject=RE%3A%20%2340%20-%20HTTP2%20default%20value%20for%20client%20supported%20%20max_concurrent_streams&In-Reply-To=%253CCA566BAEAD6B3F4E8B5C5C4F61710C1163AAA591%40TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com%253E&References=%253CCA566BAEAD6B3F4E8B5C5C4F61710C1163AAA591%40TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com%253E>>,
> Amos Jeffries <*squid3@treenet.co.nz*<squid3@treenet.co.nz?Subject=RE%3A%20%2340%20-%20HTTP2%20default%20value%20for%20client%20supported%20%20max_concurrent_streams&In-Reply-To=%253CCA566BAEAD6B3F4E8B5C5C4F61710C1163AAA591%40TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com%253E&References=%253CCA566BAEAD6B3F4E8B5C5C4F61710C1163AAA591%40TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com%253E>
> >
> *CC*: HTTP Working Group <*ietf-http-wg@w3.org*<ietf-http-wg@w3.org?Subject=RE%3A%20%2340%20-%20HTTP2%20default%20value%20for%20client%20supported%20%20max_concurrent_streams&In-Reply-To=%253CCA566BAEAD6B3F4E8B5C5C4F61710C1163AAA591%40TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com%253E&References=%253CCA566BAEAD6B3F4E8B5C5C4F61710C1163AAA591%40TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com%253E>
> >
>
> There’s two parties in this dance, and it takes both to want to do it. If
> a client wants at some point to not be fired upon strictly more than it
> requests for (perhaps because it is low on batteries or is very close to
> its monthly data allowance or because it just plain doesn’t feel like it),
> than a server inlining a bunch of stuff is like it shooting at the client.
> From the point of view of the client, getting fired at hurts. The client
> can very well decide never again to use such servers.
>
> If the server does not inline but instead uses the new fancy push
> capability, it might be friendlier fire, but getting fired at even if it’s
> “friendly” fire hurts just the same.
>
> Catering to the server’s wishes is fine and dandy, but that is only one
> part of the equation. I guess I’m a bit more optimistic in that I hope it
> will become possible for clients not to be fired at, instead of just
> changing from one type of fire to another.
>
> From: *willchan@google.com*<willchan@google.com?Subject=RE%3A%20%2340%20-%20HTTP2%20default%20value%20for%20client%20supported%20%20max_concurrent_streams&In-Reply-To=%253CCA566BAEAD6B3F4E8B5C5C4F61710C1163AAA591%40TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com%253E&References=%253CCA566BAEAD6B3F4E8B5C5C4F61710C1163AAA591%40TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com%253E>[mailto:
> *willchan@google.com*<willchan@google.com?Subject=RE%3A%20%2340%20-%20HTTP2%20default%20value%20for%20client%20supported%20%20max_concurrent_streams&In-Reply-To=%253CCA566BAEAD6B3F4E8B5C5C4F61710C1163AAA591%40TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com%253E&References=%253CCA566BAEAD6B3F4E8B5C5C4F61710C1163AAA591%40TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com%253E>]
> On Behalf Of William Chan (???)
> Sent: Saturday, 23 February, 2013 07:09
> To: Amos Jeffries
> Cc: HTTP Working Group
> Subject: Re: #40 - HTTP2 default value for client supported
> max_concurrent_streams
>
> Sorry, I did not explicitly state a conditional that I thought was
> implicitly understood.
>
> *In situations where the server wants to push resources*, if the majority
> of clients disable HTTP/2 stream push, then servers will simply inline
> resources instead.
>
> You're right that push can always be abused. But in situations that it
> makes sense to push, it's better to use HTTP/2's push facility than to
> inline resources. And we should ensure that the push mechanism remains
> viable, otherwise servers will just inline in those situations.
>
> On Sat, Feb 23, 2013 at 3:03 AM, Amos Jeffries <*squid3@treenet.co.nz*<squid3@treenet.co.nz?Subject=RE%3A%20%2340%20-%20HTTP2%20default%20value%20for%20client%20supported%20%20max_concurrent_streams&In-Reply-To=%253CCA566BAEAD6B3F4E8B5C5C4F61710C1163AAA591%40TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com%253E&References=%253CCA566BAEAD6B3F4E8B5C5C4F61710C1163AAA591%40TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com%253E>
> <mailto:*squid3@treenet.co.nz*<squid3@treenet.co.nz?Subject=RE%3A%20%2340%20-%20HTTP2%20default%20value%20for%20client%20supported%20%20max_concurrent_streams&In-Reply-To=%253CCA566BAEAD6B3F4E8B5C5C4F61710C1163AAA591%40TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com%253E&References=%253CCA566BAEAD6B3F4E8B5C5C4F61710C1163AAA591%40TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com%253E>>>
> wrote:
> 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 <*
> Gabriel.Montenegro@microsoft.com*<Gabriel.Montenegro@microsoft.com?Subject=RE%3A%20%2340%20-%20HTTP2%20default%20value%20for%20client%20supported%20%20max_concurrent_streams&In-Reply-To=%253CCA566BAEAD6B3F4E8B5C5C4F61710C1163AAA591%40TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com%253E&References=%253CCA566BAEAD6B3F4E8B5C5C4F61710C1163AAA591%40TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com%253E>
> <mailto:*Gabriel.Montenegro@microsoft.com*<Gabriel.Montenegro@microsoft.com?Subject=RE%3A%20%2340%20-%20HTTP2%20default%20value%20for%20client%20supported%20%20max_concurrent_streams&In-Reply-To=%253CCA566BAEAD6B3F4E8B5C5C4F61710C1163AAA591%40TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com%253E&References=%253CCA566BAEAD6B3F4E8B5C5C4F61710C1163AAA591%40TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com%253E>>
> <mailto:*Gabriel.Montenegro@microsoft.com*<Gabriel.Montenegro@microsoft.com?Subject=RE%3A%20%2340%20-%20HTTP2%20default%20value%20for%20client%20supported%20%20max_concurrent_streams&In-Reply-To=%253CCA566BAEAD6B3F4E8B5C5C4F61710C1163AAA591%40TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com%253E&References=%253CCA566BAEAD6B3F4E8B5C5C4F61710C1163AAA591%40TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com%253E>
> <mailto:*Gabriel.Montenegro@microsoft.com*<Gabriel.Montenegro@microsoft.com?Subject=RE%3A%20%2340%20-%20HTTP2%20default%20value%20for%20client%20supported%20%20max_concurrent_streams&In-Reply-To=%253CCA566BAEAD6B3F4E8B5C5C4F61710C1163AAA591%40TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com%253E&References=%253CCA566BAEAD6B3F4E8B5C5C4F61710C1163AAA591%40TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com%253E>>>>
> wrote:
>
>     There is harm borne by the unwilling client receiver: battery and
>     data allowance are not free.
>     *From:*Roberto Peon [mailto:*grmocg@gmail.com*<grmocg@gmail.com?Subject=RE%3A%20%2340%20-%20HTTP2%20default%20value%20for%20client%20supported%20%20max_concurrent_streams&In-Reply-To=%253CCA566BAEAD6B3F4E8B5C5C4F61710C1163AAA591%40TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com%253E&References=%253CCA566BAEAD6B3F4E8B5C5C4F61710C1163AAA591%40TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com%253E>
> <mailto:*grmocg@gmail.com*<grmocg@gmail.com?Subject=RE%3A%20%2340%20-%20HTTP2%20default%20value%20for%20client%20supported%20%20max_concurrent_streams&In-Reply-To=%253CCA566BAEAD6B3F4E8B5C5C4F61710C1163AAA591%40TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com%253E&References=%253CCA566BAEAD6B3F4E8B5C5C4F61710C1163AAA591%40TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com%253E>
> >
>     <mailto:*grmocg@gmail.com*<grmocg@gmail.com?Subject=RE%3A%20%2340%20-%20HTTP2%20default%20value%20for%20client%20supported%20%20max_concurrent_streams&In-Reply-To=%253CCA566BAEAD6B3F4E8B5C5C4F61710C1163AAA591%40TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com%253E&References=%253CCA566BAEAD6B3F4E8B5C5C4F61710C1163AAA591%40TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com%253E>
> <mailto:*grmocg@gmail.com*<grmocg@gmail.com?Subject=RE%3A%20%2340%20-%20HTTP2%20default%20value%20for%20client%20supported%20%20max_concurrent_streams&In-Reply-To=%253CCA566BAEAD6B3F4E8B5C5C4F61710C1163AAA591%40TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com%253E&References=%253CCA566BAEAD6B3F4E8B5C5C4F61710C1163AAA591%40TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com%253E>
> >>]
>     *Sent:* Friday, 22 February, 2013 08:24
>     *To:* Martin Thomson
>     *Cc:* Osama Mazahir; *ietf-http-wg@w3.org*<ietf-http-wg@w3.org?Subject=RE%3A%20%2340%20-%20HTTP2%20default%20value%20for%20client%20supported%20%20max_concurrent_streams&In-Reply-To=%253CCA566BAEAD6B3F4E8B5C5C4F61710C1163AAA591%40TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com%253E&References=%253CCA566BAEAD6B3F4E8B5C5C4F61710C1163AAA591%40TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com%253E>
> <mailto:*ietf-http-wg@w3.org*<ietf-http-wg@w3.org?Subject=RE%3A%20%2340%20-%20HTTP2%20default%20value%20for%20client%20supported%20%20max_concurrent_streams&In-Reply-To=%253CCA566BAEAD6B3F4E8B5C5C4F61710C1163AAA591%40TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com%253E&References=%253CCA566BAEAD6B3F4E8B5C5C4F61710C1163AAA591%40TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com%253E>
> >
>     <mailto:*ietf-http-wg@w3.org*<ietf-http-wg@w3.org?Subject=RE%3A%20%2340%20-%20HTTP2%20default%20value%20for%20client%20supported%20%20max_concurrent_streams&In-Reply-To=%253CCA566BAEAD6B3F4E8B5C5C4F61710C1163AAA591%40TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com%253E&References=%253CCA566BAEAD6B3F4E8B5C5C4F61710C1163AAA591%40TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com%253E>
> <mailto:*ietf-http-wg@w3.org*<ietf-http-wg@w3.org?Subject=RE%3A%20%2340%20-%20HTTP2%20default%20value%20for%20client%20supported%20%20max_concurrent_streams&In-Reply-To=%253CCA566BAEAD6B3F4E8B5C5C4F61710C1163AAA591%40TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com%253E&References=%253CCA566BAEAD6B3F4E8B5C5C4F61710C1163AAA591%40TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com%253E>>>
> 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*<martin.thomson@gmail.com?Subject=RE%3A%20%2340%20-%20HTTP2%20default%20value%20for%20client%20supported%20%20max_concurrent_streams&In-Reply-To=%253CCA566BAEAD6B3F4E8B5C5C4F61710C1163AAA591%40TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com%253E&References=%253CCA566BAEAD6B3F4E8B5C5C4F61710C1163AAA591%40TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com%253E>
> <mailto:*martin.thomson@gmail.com*<martin.thomson@gmail.com?Subject=RE%3A%20%2340%20-%20HTTP2%20default%20value%20for%20client%20supported%20%20max_concurrent_streams&In-Reply-To=%253CCA566BAEAD6B3F4E8B5C5C4F61710C1163AAA591%40TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com%253E&References=%253CCA566BAEAD6B3F4E8B5C5C4F61710C1163AAA591%40TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com%253E>>
> <mailto:*martin.thomson@gmail.com*<martin.thomson@gmail.com?Subject=RE%3A%20%2340%20-%20HTTP2%20default%20value%20for%20client%20supported%20%20max_concurrent_streams&In-Reply-To=%253CCA566BAEAD6B3F4E8B5C5C4F61710C1163AAA591%40TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com%253E&References=%253CCA566BAEAD6B3F4E8B5C5C4F61710C1163AAA591%40TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com%253E>
> <mailto:*martin.thomson@gmail.com*<martin.thomson@gmail.com?Subject=RE%3A%20%2340%20-%20HTTP2%20default%20value%20for%20client%20supported%20%20max_concurrent_streams&In-Reply-To=%253CCA566BAEAD6B3F4E8B5C5C4F61710C1163AAA591%40TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com%253E&References=%253CCA566BAEAD6B3F4E8B5C5C4F61710C1163AAA591%40TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com%253E>>>>
> wrote:
>
>         On 22 February 2013 05:29, Roberto Peon <*grmocg@gmail.com*<grmocg@gmail.com?Subject=RE%3A%20%2340%20-%20HTTP2%20default%20value%20for%20client%20supported%20%20max_concurrent_streams&In-Reply-To=%253CCA566BAEAD6B3F4E8B5C5C4F61710C1163AAA591%40TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com%253E&References=%253CCA566BAEAD6B3F4E8B5C5C4F61710C1163AAA591%40TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com%253E>
> <mailto:*grmocg@gmail.com*<grmocg@gmail.com?Subject=RE%3A%20%2340%20-%20HTTP2%20default%20value%20for%20client%20supported%20%20max_concurrent_streams&In-Reply-To=%253CCA566BAEAD6B3F4E8B5C5C4F61710C1163AAA591%40TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com%253E&References=%253CCA566BAEAD6B3F4E8B5C5C4F61710C1163AAA591%40TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com%253E>
> >
>         <mailto:*grmocg@gmail.com*<grmocg@gmail.com?Subject=RE%3A%20%2340%20-%20HTTP2%20default%20value%20for%20client%20supported%20%20max_concurrent_streams&In-Reply-To=%253CCA566BAEAD6B3F4E8B5C5C4F61710C1163AAA591%40TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com%253E&References=%253CCA566BAEAD6B3F4E8B5C5C4F61710C1163AAA591%40TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com%253E>
> <mailto:*grmocg@gmail.com*<grmocg@gmail.com?Subject=RE%3A%20%2340%20-%20HTTP2%20default%20value%20for%20client%20supported%20%20max_concurrent_streams&In-Reply-To=%253CCA566BAEAD6B3F4E8B5C5C4F61710C1163AAA591%40TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com%253E&References=%253CCA566BAEAD6B3F4E8B5C5C4F61710C1163AAA591%40TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com%253E>>>>
> 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 Wednesday, 6 March 2013 22:32:14 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 6 March 2013 22:32:19 GMT