Re: New Version Notification for draft-kerwin-http2-encoded-data-01.txt

[Matthew Kerwin <[e-mail]>]

On 23/07/2014, Roberto Peon <[e-mail]> 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/