- From: Cory Benfield <cory@lukasa.co.uk>
- Date: Tue, 1 Jul 2014 09:04:55 +0100
- To: William Chan (陈智昌) <willchan@chromium.org>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
Leaving the CONTINUATION discussion to one side for the moment... On 1 July 2014 04:37, William Chan (陈智昌) <willchan@chromium.org> wrote: > * 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 principle this is a great idea. In practice this worries me a bit. You'll need to get all the browser vendors to agree to do this, and to agree to do it in roughly the same way, or you'll all start competing on how to do this in the most performant way (or indeed all just abandon it). The client library implementations will certainly not do this, for obvious reasons. > * 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. So, just Google then. _Maybe_ Mozilla depending on how Apache ends up exposing HTTP/2. ;) All jokes aside, this is a perfectly reasonable thing for Google to do, but it's unlikely to be anything anyone else can also do. Not a bad idea though. > * Make sure to use features that aren't necessarily required, in order to > make sure they remain viable. For example: > - If we think servers need to at least be able to support reading > continuation frames (if not necessarily use them themselves), then clients > should make sure to exercise this code path some part of the time. Good luck with this one, I'm certainly not touching it with a ten-foot pole. As I've said before, compatibility is hugely important to me. I'm much happier restricting myself to the subset of features that are necessary and guaranteed to be implemented. I'm not going to emit CONTINUATION frames unless I absolutely have to, because the risk of a server or intermediary blowing away my connection is too high. If that happens, I'm going to be the one that gets blamed. The risk is just too high for too little reward. While we're here, what about HTTP/1.1 Upgrade? I know that Chrome and FF have said that this isn't going to be supported by them: does that remain true? I worry that this section of the spec will be left out by a lot of people (I haven't implemented it yet), which makes it an easy bit of the spec to just have atrophy away.
Received on Tuesday, 1 July 2014 08:05:23 UTC