- From: Osama Mazahir <OSAMAM@microsoft.com>
- Date: Sat, 12 Jul 2014 08:14:43 +0000
- To: Willy Tarreau <w@1wt.eu>, Mark Nottingham <mnot@mnot.net>
- CC: HTTP Working Group <ietf-http-wg@w3.org>
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