Re: Design Issue: Frame Size Items

Reading back over that thread, it seems to me that the overall
majority opinion was in favor of a smaller default max thread size
(let's just say 8192 + 8 byte header).

Proposal: Let's define that 8192+8 is the default MAX_FRAME size. If
an endpoint wishes to allow for frames larger or smaller than that, up
to ((s^16)-1)+8 total, then they can specify a SETTINGS_MAX_FRAME_SIZE
in the SETTINGS frame.

Yes, I know this proposal won't please everyone, but at some point we
need to put a stake in the ground on it. 8192+8 seems like a
reasonable enough of a default.

On Tue, May 7, 2013 at 2:17 PM, William Chan (陈智昌)
<willchan@chromium.org> wrote:
> On Tue, May 7, 2013 at 5:58 PM, Martin Thomson <martin.thomson@gmail.com>
> wrote:
>>
>> On 7 May 2013 12:41, William Chan (陈智昌) <willchan@chromium.org> wrote:
>> > I need to re-read the framing continuation thread
>> > (http://lists.w3.org/Archives/Public/ietf-http-wg/2013JanMar/0600.html),
>> > but
>> > I thought all this was addressed by that (8192 max frames, with frame
>> > continuation bit). I see that the spec does not mention frame
>> > continuations,
>> > so maybe we just have to write the text, or perhaps the thread reached a
>> > different conclusion than I remember.
>>
>> That discussion never really concluded.
>
>
> OK, I think we should conclude that thread :) I believe that resolving that
> thread will resolve this issue.
>
>>
>>
>> What we have is MUST support 8192, but no upper limit (other than the
>> hard 65535 byte limit imposed by the frame length field size).
>>
>> You might infer from this that 8192 is the only safe upper limit,
>> especially for frames containing headers.  Other frames might trigger
>> RST_STREAM, but at least you don't lose the session.
>
>
> Yep, I indeed did infer that, since we don't (at least, that I know of) have
> a safe mechanism for not processing frames that affect session state.

Received on Wednesday, 8 May 2013 04:32:46 UTC