Re: Options for CONTINUATION-related issues

On Jul 16, 2014, at 9:53 AM, Greg Wilkins <gregw@intalio.com> wrote:

> 
> On 16 July 2014 17:08, Mark Nottingham <mnot@mnot.net> 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.

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.

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.


--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat

Received on Wednesday, 16 July 2014 15:43:19 UTC