Re: Options for CONTINUATION-related issues

On 17 Jul 2014, at 1:42 am, Jason Greene <> wrote:

> On Jul 16, 2014, at 9:53 AM, Greg Wilkins <> wrote:
>> On 16 July 2014 17:08, Mark Nottingham <> wrote:
>> Are there any other realistic (i.e., capable of achieving consensus, NOT just your favourite approach) options that we should be considering?
>> hmmmm I am probably being unrealistic.... but let's tilt at this windmill 
>> c) Remove CONTINUATION from the specification, allow HEADERS to be fragmented and add a new setting that advises the maximum header set size (i.e,. uncompressed) a peer is willing to receive (but might not imply PROTOCOL_ERROR or STREAM_ERROR on receipt).
> I have a fourth option to add to the mix which is based on all of the feedback I have seen.
> AFAICT there is only one limited use-case that can not be covered by the recent move to allow large frames. That is the ability to split a frame into chunks so that a 1:1 proxy doesn’t have to buffer. 
> We could have a more narrow form of CONTINUATION: 
> - The sum of all continuation frames can not exceed max_frame_size.

The default of max_frame_size is 16k; that means that a server can't ever send more than 16k (or 32k, depending on whether you intend to include HEADERS in the max) of response headers without some adjustment by the browser...

> Since this use case is avoiding buffering, they may not know the exact size has exceeded the max until the Nth continuation is sent. Therefore:
> - Add a discard flag on the last HEADER/CONTINUATION frame, which instructs the endpoint to discard the request and all buffered data.

Why not just reset the stream?

> Pros:
> - Addresses 551
> - There is only one max setting
> - Encourages reduction of gigantic headers
> - As a side-effect of the discard flag, it provides a client the ability to inform the server that a request was too large and would have generated a 431 (not really significant but it came up in a thread and worth mentioning)
> Cons:
> - As with all other length limited proposals, sender has to rewind encoder state to that of last sent frame.


Mark Nottingham

Received on Thursday, 17 July 2014 04:45:09 UTC