Re: #40 - HTTP2 default value for client supported max_concurrent_streams
William Chan (陈智昌) <willchan@chromium.org> Wed, 27 February 2013 20:20 UTC
Return-Path: <ietf-http-wg-request@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62B3F21F8528 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 27 Feb 2013 12:20:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.467
X-Spam-Level:
X-Spam-Status: No, score=-9.467 tagged_above=-999 required=5 tests=[AWL=0.209, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IdjTt85HOCWX for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 27 Feb 2013 12:20:53 -0800 (PST)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 5B6C021F857C for <httpbisa-archive-bis2Juki@lists.ietf.org>; Wed, 27 Feb 2013 12:20:53 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1UAnTO-00038Q-7s for ietf-http-wg-dist@listhub.w3.org; Wed, 27 Feb 2013 20:19:30 +0000
Resent-Date: Wed, 27 Feb 2013 20:19:30 +0000
Resent-Message-Id: <E1UAnTO-00038Q-7s@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <willchan@google.com>) id 1UAnTC-00037J-Ep for ietf-http-wg@listhub.w3.org; Wed, 27 Feb 2013 20:19:18 +0000
Received: from mail-qa0-f51.google.com ([209.85.216.51]) by lisa.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <willchan@google.com>) id 1UAnT8-0004D9-DC for ietf-http-wg@w3.org; Wed, 27 Feb 2013 20:19:18 +0000
Received: by mail-qa0-f51.google.com with SMTP id cr7so801336qab.3 for <ietf-http-wg@w3.org>; Wed, 27 Feb 2013 12:18:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=05+opzSqKL55wmDB64Dzk6gq0DFaLFW0ZK2HLsKpWPE=; b=S5s7gc6VjKDZzXo1h2xZswVToDwYUhxAQD/99fCVLAN4Mvsa9IrmiRk1ExUGqRqnQh 7GnyWGBCkkZYsEHESVUPt8eCn1sXN327qgyz8jKtRDaJBWVVkgxPIX217llVMNORbyCL 7O3RRDDeQ6dgGjQkx3MZzeGu5lIb9sCb77kHIMUt+VAO86SvgtPXjr9A1/I0iLUrPSlF 4tO/DEhLOrGdLWUMIlVTULd1SfxucepOo8IAomUp9q89RYKyZMuh62JxdivhkcJTM0sd 1yFkcDKD5b/+/JkrrJGraic+8HgmGsRiTQOZ31d+SlhYheRZ/AAtS+3okAM4aFkZCAp8 8gtw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=05+opzSqKL55wmDB64Dzk6gq0DFaLFW0ZK2HLsKpWPE=; b=CX1ftVq5B67fJnGkqt88Zh89a8+4zwzDXBh4xk+iHYX4imk5uRhn+Q5Ofh05LmKj8P IPZ3tfOefVXAwkWcufAPApiC3G3l7YEPnzWQpWv7wqfvc+En8a/6hXiD/9E9+BiGfDmZ Ci94IFHW80/G3fgrd8diUMWkfcUSTB6z4w9Ow=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=05+opzSqKL55wmDB64Dzk6gq0DFaLFW0ZK2HLsKpWPE=; b=jlh1z+aWBbFmbwlY5nMVa2y5gx7MFY27V65Ac19Lc4jcVqTiBQplHp2zEm6hgk81EE ZQGl5o2LdEZ9JviB57SafWCkP+OdDg9vpHec36/5Fdw4kR/T4P40NV+cpdPK5eI3oUu3 gZijjAUrJdksioduNu0Pxo7dlZtu+FyD5plBzU8I/wuaGesbUb4b0dUne3eFcqG95Bud o/RZ1XmLL9jE1RAYbkZkQZsRddtuMpiM4jsPWK4z2VbqUGHElOAj+OJQ6oyFDap1dGsl y3iIWZYrLpZJPNBGASD2MS2rYQcUCzDVTstmQp69D2KUslpMLAvlEf1cjmvRBxmdQfvx HVpw==
MIME-Version: 1.0
X-Received: by 10.224.216.9 with SMTP id hg9mr9821416qab.44.1361996328242; Wed, 27 Feb 2013 12:18:48 -0800 (PST)
Sender: willchan@google.com
Received: by 10.229.135.210 with HTTP; Wed, 27 Feb 2013 12:18:48 -0800 (PST)
In-Reply-To: <CA566BAEAD6B3F4E8B5C5C4F61710C1163ABFA8C@TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com>
References: <B33F11E188FEAB49A7FAF38BAB08A2C001D31EF6@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <CAP+FsNeHjN-SQHw5NyiqauNAL-7rbwq91a0OdXujdF4SL6j4Yw@mail.gmail.com> <CABkgnnWD1XWx3hChfDh83VmhtspsCHETRnZBYjzM7pCXYa=0Fg@mail.gmail.com> <CAP+FsNcqu-AwNnijWcPyNZFWssEqo0b+sv61E09ZO=aFyzCNFQ@mail.gmail.com> <CA566BAEAD6B3F4E8B5C5C4F61710C1163AA6440@TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com> <CAA4WUYiJbASP2fUGSZYzLstDM1zn6FLou9OOdRwokwm0yu+OMg@mail.gmail.com> <5128A209.7040403@treenet.co.nz> <CAA4WUYjUTkJk1EdJ_N6w_8VPCu7cSZ8aTceO7r=ojX8b5bmuXA@mail.gmail.com> <CA566BAEAD6B3F4E8B5C5C4F61710C1163AAA591@TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com> <CAA4WUYgo=GD1_9OV5vtpE+rRbXVJShHU_L861QxPAq1yc15cMw@mail.gmail.com> <CA566BAEAD6B3F4E8B5C5C4F61710C1163AB76D9@TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com> <CAA4WUYhLCmJ_2qZNUYO7W1n9tHVY18w6K=KuO1k3tDjGg62Piw@mail.gmail.com> <CA566BAEAD6B3F4E8B5C5C4F61710C1163ABFA8C@TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com>
Date: Wed, 27 Feb 2013 12:18:48 -0800
X-Google-Sender-Auth: 1oXO8qRrsJoo7Rbwr69h_sAMuPM
Message-ID: <CAA4WUYgOY3TMyu525mbK4YvsS+ZW7J4rUHU_4QZdPu9K5VUhXg@mail.gmail.com>
From: "William Chan (陈智昌)" <willchan@chromium.org>
To: Gabriel Montenegro <Gabriel.Montenegro@microsoft.com>
Cc: Amos Jeffries <squid3@treenet.co.nz>, HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="20cf300512fe54b17404d6ba7b5b"
X-Gm-Message-State: ALoCoQkyyCZnqYb6CpUZIjxi689cvITui5AonMm5uEOWvZk1kf9ZH/tee0u2BZUeuDnxJ8pVrSthEhAzboGKnZq5sHhDgJTXMxEE9wJQGpFmktU9Ee6X2zNRyY6yLV/JjP6ZxoVi9MPP540uf98ufyHZSDtpZeLsa2qq9/M7rHErbM0wJ+HA2ScuvTSwEPzVKbKLO+wPMDc6
Received-SPF: pass client-ip=209.85.216.51; envelope-from=willchan@google.com; helo=mail-qa0-f51.google.com
X-W3C-Hub-Spam-Status: No, score=-3.8
X-W3C-Hub-Spam-Report: AWL=-2.319, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.703, SPF_PASS=-0.001
X-W3C-Scan-Sig: lisa.w3.org 1UAnT8-0004D9-DC 4e6aa7f1abdf84833e8cd46711150bdc
X-Original-To: ietf-http-wg@w3.org
Subject: Re: #40 - HTTP2 default value for client supported max_concurrent_streams
Archived-At: <http://www.w3.org/mid/CAA4WUYgOY3TMyu525mbK4YvsS+ZW7J4rUHU_4QZdPu9K5VUhXg@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/16900
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>
Great to hear we're agreed on the current state of things. As for users changing behavior based on websites, I totally agree that's a signal and agree it's neither explicit, nor very good. To be clear, the part that I said was not a signal was a protocol default: "I assert that having a low/zero *default* max streams limit won't help here, since defaults do *not* signal intent." On Wed, Feb 27, 2013 at 11:59 AM, Gabriel Montenegro < Gabriel.Montenegro@microsoft.com> wrote: > No disagreement on the present. However, in what I quoted from you, the > verb is in the future tense. I interpreted this as a prediction of the > future. Furthermore, I interpreted what I quoted as your saying that it is > a non-signal when clients prefer better behaved servers that don’t fire > upon sight of the client. I think it is a signal, admittedly not a very > explicit nor particularly good one.**** > > ** ** > > I agree with your assessment that it would be much better to have a clear > signal that would allow a client to not be fed more by the server, than the > client explicitly requests for.**** > > ** ** > > *From:* willchan@google.com [mailto:willchan@google.com] *On Behalf Of *William > Chan (???) > *Sent:* Tuesday, 26 February, 2013 18:52 > > *To:* Gabriel Montenegro > *Cc:* Amos Jeffries; HTTP Working Group > *Subject:* Re: #40 - HTTP2 default value for client supported > max_concurrent_streams**** > > ** ** > > Sorry, can you clarify your disagreement here? Are you disagreeing that > servers push content anyways today? Or are you saying that users already > stop browsing such websites?**** > > ** ** > > My assertion was that it's simply a fact of life today that servers push > content. I'll go even further, websites push content and users still seem > to use those websites anyway. My evidence: bing.com uses data URIs. Check > out view-source:http://www.bing.com/search?q=flowers and search for > 'data:image'.**** > > ** ** > > On Tue, Feb 26, 2013 at 11:54 AM, Gabriel Montenegro < > Gabriel.Montenegro@microsoft.com> wrote:**** > > I don’t agree with this: “I think we also agree that the current reality > is that many servers push content anyways.” I thought I had said that > already: I think clients’ abandoning such servers and going elsewhere is a > signal, but agree that an explicit one would be much better.**** > > **** > > *From:* willchan@google.com [mailto:willchan@google.com] *On Behalf Of *William > Chan (???) > *Sent:* Saturday, 23 February, 2013 18:24 > *To:* Gabriel Montenegro > *Cc:* Amos Jeffries; HTTP Working Group**** > > > *Subject:* Re: #40 - HTTP2 default value for client supported > max_concurrent_streams**** > > **** > > I think we agree that, in certain cases, such as mobile clients worried > about data usage, pushing content is bad. I think we also agree that the > current reality is that many servers push content anyways. And you're right > that the users may very well decide not to use those servers if the servers > abuse push mechanisms. Creating better user feedback mechanisms to let them > know when servers are hurting them would be a good thing.**** > > **** > > I think what we disagree on is your optimism that the push mechanism in > HTTP/2 will make it possible for the client to prevent the server from > unduly pushing content by having a low default max streams limit. If the > default is low/zero, and there's no explicit signal from the client that it > doesn't want extra content, then the server will try to make the best > choice, as it already does today, on whether or not to push and how.**** > > **** > > I think what you want is a method for the client to signal to the server > that it doesn't want to be pushed content, regardless of the mechanism > (HTTP/2 push or resource inlining). I assert that having a low/zero > *default* max streams limit won't help here, since defaults do *not* signal > intent. Create an actual signal, don't take away the HTTP/2 push mechanism > (a low/zero default is effectively equivalent to taking it away, since it > requires a roundtrip to re-enable push, which defeats the purpose of push - > saving roundtrips), since servers will just inline instead.**** > > **** > > On Sat, Feb 23, 2013 at 5:23 PM, Gabriel Montenegro < > Gabriel.Montenegro@microsoft.com> wrote:**** > > “where the server wants”**** > > **** > > 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 [mailto:willchan@google.com] *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> > 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 <mailto: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 > <mailto:grmocg@gmail.com>] > *Sent:* Friday, 22 February, 2013 08:24 > *To:* Martin Thomson > *Cc:* Osama Mazahir; ietf-http-wg@w3.org > <mailto: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 <mailto:martin.thomson@gmail.com>> wrote: > > On 22 February 2013 05:29, Roberto Peon <grmocg@gmail.com**** > > <mailto: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.**** > > **** > > **** > > **** > > ** ** >
- #40 - HTTP2 default value for client supported ma… Osama Mazahir
- Re: #40 - HTTP2 default value for client supporte… Roberto Peon
- Re: #40 - HTTP2 default value for client supporte… Martin Thomson
- Re: #40 - HTTP2 default value for client supporte… Roberto Peon
- RE: #40 - HTTP2 default value for client supporte… Gabriel Montenegro
- Re: #40 - HTTP2 default value for client supporte… William Chan (陈智昌)
- Re: #40 - HTTP2 default value for client supporte… Amos Jeffries
- Re: #40 - HTTP2 default value for client supporte… William Chan (陈智昌)
- RE: #40 - HTTP2 default value for client supporte… Gabriel Montenegro
- Re: #40 - HTTP2 default value for client supporte… William Chan (陈智昌)
- RE: #40 - HTTP2 default value for client supporte… Gabriel Montenegro
- Re: #40 - HTTP2 default value for client supporte… William Chan (陈智昌)
- RE: #40 - HTTP2 default value for client supporte… Gabriel Montenegro
- Re: #40 - HTTP2 default value for client supporte… William Chan (陈智昌)
- Re: #40 - HTTP2 default value for client supporte… Amos Jeffries
- Re: #40 - HTTP2 default value for client supporte… Roberto Peon
- RE: #40 - HTTP2 default value for client supporte… DRUTA, DAN
- Re: #40 - HTTP2 default value for client supporte… William Chan (陈智昌)