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 <w@1wt.eu>
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) <https://github.com/http2/http2-spec/issues/553>.
>
> Does anyone have a problem with that, or further comments?

Fine for me. +1

Willy



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