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

Re: Design Issue: Frame Size Items

From: 陈智昌 <willchan@chromium.org>
Date: Tue, 7 May 2013 18:17:53 -0300
Message-ID: <CAA4WUYgKnYhgvArS7FSWqRSf4MfhRbymCiGOC3E21E6R32KWCQ@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Cc: James M Snell <jasnell@gmail.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
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 Tuesday, 7 May 2013 21:18:21 UTC

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