RE: Call for Consensus: Frame size (to address #553)

So in down step situations (e.g. changing the max_frame_size from 16K to 1K), the requirement will be to follow the standard SETTINGS/SETTINGS_ACK procedure in that the endpoint advertising the max_frame_size reduction must still be able to receive the larger frames until the SETTINGS_ACK comes back (e.g. SETTINGS and the larger frame cross in-flight)?  I just want to make sure that we are not creating design holes where a legitimate sender will violate the receiver.
From: Willy Tarreau <>
Sent: Saturday, July 12, 2014 12:58 AM
To: Mark Nottingham
Cc: HTTP Working Group
Subject: Re: Call for Consensus: Frame size (to address #553)

On Sat, Jul 12, 2014 at 04:46:31PM +1000, Mark Nottingham wrote:
> There has been a lot of discussion over the last two weeks about various proposals to address a number of issues. While we're not at the point where we have consensus to accept any of them wholesale, I do think we can reduce the surface area of the discussion by declaring consensus on the less controversial parts.
> So: it appears that we have consensus to address issue #553 by:
> * Expanding the frame size field to 24 bits
> * Reserving additional bits to align
> * Adding a setting advertising the maximum frame size allowed by the recipient, with a default of 16K octets and a minimum of 256 octets
> This would address (only) <>.
> Does anyone have a problem with that, or further comments?

Fine for me. +1


Received on Saturday, 12 July 2014 08:15:13 UTC