W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2013

Re: Design Issue: Frame Size Items

From: Martin Thomson <martin.thomson@gmail.com>
Date: Tue, 7 May 2013 11:07:28 -0700
Message-ID: <CABkgnnWDvyUajrhYLvGzqeenUsyq9h720LYZNUzqzHNR8r0LxQ@mail.gmail.com>
To: James M Snell <jasnell@gmail.com>
Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
On 7 May 2013 08:19, James M Snell <jasnell@gmail.com> wrote:
> 1. There is an existing ed note in the draft indicating that we
> currently do not have any way of specifying the maximum frame size.
> There are several possibilities:
>
>   a. We decide we don't need to report a maximum frame size.

This has been discussed.  The problem is that you have to then FIX the
maximum frame size and require that all implementations support that
size.  No one can decide on a goldilocks number: 4096, 8192, 16384,
32768 or 65536 have all been variously proposed.  Others want to add
extra bits to the length field to open up other options (i.e.,
petabytes).

>   b. We introduce a MAX_FRAME_SIZE setting for the SETTINGS frame.

This introduces another "known state" issue (see Gabriel's issues).
You have to have a default (see above), and then a robust way to
change.

>   c. We add a headers block to the RST_FRAME and GOAWAY frames ;-) ..

I'm not following you.

>   I think I prefer option (a) but (b) works too.
>
> 2. In the current draft we say that all implementations MUST be
> capable of supporting frames up to 8192 octets in length. We don't
> say, however, whether that size includes the 8-byte header or is that
> just payload octets?

That's a simple fix.  Toss a coin.  ;)
Received on Tuesday, 7 May 2013 18:07:59 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:11 UTC