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

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.****
>
>  ****
>
>   ****
>
>    ****
>
>  ** **
>