- From: Matthew Kerwin <matthew@kerwin.net.au>
- Date: Wed, 23 Jul 2014 18:09:20 +1000
- To: Roberto Peon <grmocg@gmail.com>
- Cc: Amos Jeffries <squid3@treenet.co.nz>, HTTP Working Group <ietf-http-wg@w3.org>
On 23/07/2014, Roberto Peon <grmocg@gmail.com> wrote: > That is what the END_SEGMENT flag *was*, except without the overhead. Ah > well. Indeed. I'd even mentioned it as a potentially useful feature for preventing BREACH back in the "compressed data" discussions. I've come to realise, though, that flags aren't global; not all frames with FLAGS&0x8 necessarily have padding (or whatever 0x8 is), and certainly FLAGS&0x1 depends entirely on the frame type to know what it means; so an END_SEGMENT on data/continuation doesn't imply anything at all about the same flag being set on an extension frame. Thus, I didn't and still don't have a problem with END_SEGMENT being removed from the core frame types, in so far as this extension is concerned. > Unless the extensions are deployed along with the first versions of HTTP2, > it seems unlikely, given a requirement all intermediaries to understand a > new extension, that an extension will survive transit through any generic > intermediary. Intermediaries (that aren't controlled by the origin server > or client) almost always upgrade more slowly than everything else. Not just unlikely - disallowed, if it uses new frame types. This is a known risk. In this case the people I've heard most support from are those doing closed-network non-browser API stuff, and it'll probably be the same for any other extensions. That's a result of there not being a general end-to-end extension model, though, not just missing END_SEGMENT. -- Matthew Kerwin http://matthew.kerwin.net.au/
Received on Wednesday, 23 July 2014 08:09:47 UTC