- From: Mark Nottingham <mnot@mnot.net>
- Date: Thu, 17 Jul 2014 14:44:40 +1000
- To: Jason Greene <jason.greene@redhat.com>
- Cc: Greg Wilkins <gregw@intalio.com>, HTTP Working Group <ietf-http-wg@w3.org>
On 17 Jul 2014, at 1:42 am, Jason Greene <jason.greene@redhat.com> wrote: > > 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. 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. Cheers, -- Mark Nottingham https://www.mnot.net/
Received on Thursday, 17 July 2014 04:45:09 UTC