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

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

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>
Message-ID: <1405152884375.1411@microsoft.com>
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

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

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