Subject: Encouraging a healthy HTTP/2 ecosystem (and not arguing about CONTINUATION frames)

From: William Chan (陈智昌) <[email-masked]>
Date: Tue, 1 Jul 2014 14:10:48 -0700

Forking my thread to regain sanity :) Learning from my mistake and deleting
the CONTINUATION frame bullet.

On Mon, Jun 30, 2014 at 8:37 PM, William Chan (陈智昌) <[email-masked]>
wrote:

> This has come up in a number of different discussions over time, and I
> thought it'd be nice to gather a list of things that it'd be useful if
> major implementations did in order to keep the ecosystem healthy. My
> interest is that, before lots of other vendors start implementing HTTP/2
> and we start getting a plethora of crappy implementations doing dumb things
> and see actual deployment, we try to enforce good behavior so that when
> they deploy and do stupid things, it breaks for them. I don't want HTTP/2
> to ossify the way that TCP options have essentially become undeployable.
> Here are some ideas for things to do:
>
> * In order to encourage sites to do feature detection as opposed to UA
> sniffing, it'd be nice if major client implementations, some percentage of
> the time, choose not to negotiate HTTP/2.
> * In order to prevent the extension mechanism from failing (due to
> intermediaries whitelisting extensions and disallowing all others, or some
> other sort of brokenness), it'd be nice for clients to negotiate random
> dummy extensions and, using out of band knowledge shared with the server,
> require that those extensions be negotiated. More than just negotiated,
> these extensions should probably use dummy logic like sending bogus
> extension frames and settings. A vendor that owned both an auto-updating
> client and popular website could enforce this.
> * Make sure to use features that aren't necessarily required, in order to
> make sure they remain viable.
>
> I feel like there were a number of other things that we wanted to do, but
> I forget. If anyone knows anything that they want early implementers to do
> in order to keep the ecosystem healthy, I'd love to hear.
>
> Cheers.
>
>
>

---

From: Cory Benfield <[email-masked]>
Date: Wed, 2 Jul 2014 20:32:49 +0100

On 1 July 2014 at 22:12:52, William Chan (陈智昌) ([email-masked](mailto:[email-masked])) wrote:

> Forking my thread to regain sanity :) Learning from my mistake and deleting the CONTINUATION frame bullet.  

Not a bad idea. =) 

So, I'd like to add my concern that "features that aren't necessarily 
required" is going to include plaintext HTTP/2. Chrome and FF have all 
acknowledged that they're not going to support this, which really only 
leaves IE as a major client implementation that will support it. 
Additionally, some of the smaller client implementations don't 
(okhttp2, hyper). Is anyone concerned about this being an area of the 
spec that has relatively little coverage? Should we be asking Chrome 
and FF to go against what they'd clearly like to do and to implement 
plaintext Upgrade?

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Wed, 02 Jul 2014 20:29:40 +0000

In message <[email-masked]>, Cory Benfield writes:
>On 1 July 2014 at 22:12:52, William Chan (陈智昌) (w
>Should we be asking Chrome and FF to go against what they'd clearly
>like to do and to implement plaintext Upgrade ?

I understand they have made that concious decision because they want
to improve encrypted connections over unencrypted ones, in order
to futher their preferred political agenda in this area.

Doing so they run the risk that somebody else deploys HTTP/2-plaintext
in competing browsers and by offering a better and faster user
experience wins market and mindshare.

I admire people who are willing to stand up put their bacon in the
pan for their principle.

For that reason alone I'm not going to ask or beg them to change
their minds.

The interesting question therefore is if HTTP/2-plaintext can
"improve the user experience" of porn over HTTP/1.

If yes, FF and Chrome will surely change their mind, rather than
conceede that market to IIS.

If no, HTTP/2 wasn't a very good protocol to begin with, was it ?

Poul-Henning

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
[email-masked]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

---

From: Mike Bishop <[email-masked]>
Date: Thu, 3 Jul 2014 17:29:13 +0000

I really like what you’re trying to do here.  I’m not convinced it will work.  Here’s why:

·         Some percentage of clients will be HTTP/2 capable but not negotiate it anyway, because of MITM and proxies.  That said bumping down a percentage for telemetry purposes might not be a bad thing for an implementation to do.

·         Someone else (Willy, I think?) already identified the issue here.  There are no dummy extensions, just those that aren’t defined yet.  If you pick a random frame or setting number each time, you’ll *create* the ossification because you’ll interact poorly with someone who actually does implement that extension.  If you pick a specific ID, you’ll just force people to whitelist that extension.

While it’s a circular argument, I’m afraid the best way to ensure a healthy ecosystem as HTTP/2 grows is to start with one.  Make sure extensions are supported by defining some, and if people introduce new ones from time to time, so much the better.

From: [email-masked] [mailto:[email-masked]] On Behalf Of William Chan (???)
Sent: Tuesday, July 1, 2014 2:11 PM
To: HTTP Working Group
Subject: Encouraging a healthy HTTP/2 ecosystem (and not arguing about CONTINUATION frames)

On Mon, Jun 30, 2014 at 8:37 PM, William Chan (陈智昌) <[email-masked]<mailto:[email-masked]>> wrote:
This has come up in a number of different discussions over time, and I thought it'd be nice to gather a list of things that it'd be useful if major implementations did in order to keep the ecosystem healthy. My interest is that, before lots of other vendors start implementing HTTP/2 and we start getting a plethora of crappy implementations doing dumb things and see actual deployment, we try to enforce good behavior so that when they deploy and do stupid things, it breaks for them. I don't want HTTP/2 to ossify the way that TCP options have essentially become undeployable. Here are some ideas for things to do:

* In order to encourage sites to do feature detection as opposed to UA sniffing, it'd be nice if major client implementations, some percentage of the time, choose not to negotiate HTTP/2.
* In order to prevent the extension mechanism from failing (due to intermediaries whitelisting extensions and disallowing all others, or some other sort of brokenness), it'd be nice for clients to negotiate random dummy extensions and, using out of band knowledge shared with the server, require that those extensions be negotiated. More than just negotiated, these extensions should probably use dummy logic like sending bogus extension frames and settings. A vendor that owned both an auto-updating client and popular website could enforce this.
* Make sure to use features that aren't necessarily required, in order to make sure they remain viable.

I feel like there were a number of other things that we wanted to do, but I forget. If anyone knows anything that they want early implementers to do in order to keep the ecosystem healthy, I'd love to hear.

Cheers.