- From: 陈智昌 <willchan@chromium.org>
- Date: Wed, 6 Mar 2013 14:31:43 -0800
- To: "DRUTA, DAN" <dd5826@att.com>
- Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
- Message-ID: <CAA4WUYjsbtR3QvPShWb3F-_F4E_FB7hjRrV3oPBN8wFg+OLg1A@mail.gmail.com>
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 UTC