W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2014

Re: Options for CONTINUATION-related issues

From: Jason Greene <jason.greene@redhat.com>
Date: Wed, 16 Jul 2014 10:42:46 -0500
Cc: Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <D29FD5A9-58CA-4CF9-9AF9-875036D894E5@redhat.com>
To: Greg Wilkins <gregw@intalio.com>

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

This archive was generated by hypermail 2.3.1 : Wednesday, 30 March 2016 09:57:09 UTC