Re: Getting to Consensus: CONTINUATION-related issues

Nicholas,

I don't think A requires any rollback capability:

> a) Remove CONTINUATION from the specification and add a new setting that dictates the maximum HEADERS/PUSH_PROMISE frame size (as distinct from max_frame_size) a peer is willing to receive. I.e., the setting refers to the compressed header size.


I believe all that is being proposed here is to require headers to be sent in a single frame, whose maximum size is advertised by the recipient with a new setting.  HEADER and PUSH_PROMISE frames already require special handling, and the maximum header frame size would be a limit for the HPACK code generating the data for the frame - where is the increased complexity?

Nothing has been said about a required rollback capability, and I can't find any mention of rollback on the linked wiki page either.  The only proposal I've read recently that might even come close is a "reset the header table" mechanism to recover from a failed request without shutting down the connection, and that would not increase an implementation's memory requirements.

As for breaking backwards compatibility with HTTP/1.1, how?  HTTP/1.1 makes no guarantees that arbitrarily large headers can be sent, and in fact section 3.3.35 of RFC 7230 specifically says that the server can reject requests whose headers are too big.


On Jul 18, 2014, at 12:34 PM, Nicholas Hurley <hurley@todesschaf.org> wrote:

> My ultimate preference is to keep the status quo.
> 
> Failing that, I could live with (B).
> 
> I can not live with (A).
> 
> For one, it drastically increases the complexity of implementation for
> no discernible gain. This complexity comes from two sources - (1)
> special-casing the implementation of one particular frame type, by
> allowing for it to have a different max size from any other frame, and
> (2) requiring a rollback capability in the HPACK encoder. Down both of
> those roads lies the madness of subtle interop issues. Given that we've
> already shown good interop with CONTINUATION, I see no need to introduce
> two brand new sources of problems.
> 
> The required rollback capability that is implicit in (A) also gives us
> yet another issue - the memory and/or CPU requirements to implement it.
> The requirements aren't exactly pretty on desktop or server, and they're
> downright nasty on mobile or other low-powered devices.
> 
> Finally, (A) explicitly breaks backwards compatibility with HTTP/1.1,
> which is a horrible position to put ourselves in.
> -- 
> Peace,
>  -Nick
> 

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair