Re: Getting to Consensus: CONTINUATION-related issues

On 2014–07–18, at 1:37 PM, Roberto Peon <grmocg@gmail.com> wrote:

> Option a- I find this option to be an extremely poor option. I hate it, it should not happen.
> 
> It increases aggregate complexity while increasing the DoS surface as it would require state rewind in the compressor.
> 
Mark, may limit violation in option A still allow recipients to either streaming-decode the rejected block, or GOAWAY? Always-GOAWAY or attempting to proceed as if the HEADERS never happened simply are not workable. But, I think the real vote here is about CONTINUATION, and nothing more detailed. (I tried to get details from the Wiki page, but can’t find apples-to-apples in any of it.)

I favor option A because it provides a better sweet spot for simpler implementations. However, the spec should also be clear that the preferred intermediary behavior is to ignore MAX_FRAME/MAX_HEADERS and forward headers indefinitely. This works without CONTINUATION, since now we have jumbo frames.

I can live with option B because I’ll eventually do streaming anyway. But, given the discussions of the past few months, I don’t believe that header streaming is a reasonable implementation requirement. Some folks just won’t be able, or motivated, to do it. In practice, CONTINUATION will be poorly supported, and B just devolves to A with a slightly more complicated binary format.

TL;DR: We added jumbo frames already, now let’s require them to fix what they were supposed to fix.