- From: Amos Jeffries <squid3@treenet.co.nz>
- Date: Thu, 28 Feb 2013 16:15:57 +1300
- To: ietf-http-wg@w3.org
On 28/02/2013 9:18 a.m., William Chan (陈智昌) wrote: > 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." > Indeed. Defaults signal the most liberal usage which is guarantee to work everywhere. As such I am against the proposals for 100+ defaults in view that the *few* websites which need this for high performance are far outweighed by the majority of other sites and services which only use or need a handful (or 1!) stream for the first RTT. Forcing every miniature embeded server or chip hardware implementation to cope with 100+ streams minimum just to cater for the way a few popular sites are implemented today seems like arrogance. Those big players will work just as well (if slowly) with a few streams - they needs a high _upper_ capacity with fast way to signal the need, not a high _default_. The big players of today will probably be replaced by flavour of next year anyway - who will be implemented differently for sure. Look to the 10+ year goalpost. Amos > > On Wed, Feb 27, 2013 at 11:59 AM, Gabriel Montenegro > <Gabriel.Montenegro@microsoft.com > <mailto: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> > [mailto: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 <http://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 > <mailto: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> > [mailto: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 > <mailto: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> > [mailto: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 <mailto: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> > <mailto: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> > <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> > <mailto: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> > <mailto: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> > > <mailto: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. > >
Received on Thursday, 28 February 2013 03:16:33 UTC