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

Re: Frame size errors and GOAWAY prose still ambiguous

From: Martin Thomson <martin.thomson@gmail.com>
Date: Mon, 29 Sep 2014 11:08:12 -0700
Message-ID: <CABkgnnXhy8A0ss3Jppv+hW58pCHMk+PymTY9si53OFx8BXLqhA@mail.gmail.com>
To: Jonathan Thackray <jthackray+http2@gmail.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Thanks for the comments.  You can find the commits in the usual place.

On 29 September 2014 03:33, Jonathan Thackray <jthackray+http2@gmail.com> wrote:
> However, I'm puzzled that all additions in Martin's commit are all
> connection-level frame size errors. Section 4.2 says:

Most have to be.  Though I was a little overzealous regarding
PRIORITY. [1885874]

> Likewise, if SETTINGS_MAX_FRAME_SIZE is still at the default value of 2^14
> octets, and a DATA frame is received of 2^15 octets, that would be a frame
> size stream error, I assume? Could we clarify this text to be more explicit?


> The description of the GOAWAY frame is slightly inconsistent on first
> reading, as its usage is mentioned in a few places. For example,
> section 5.4.1 says:
>   "A connection error is any error which prevents further processing of
>   the framing layer, or which corrupts any connection state. After sending
>   the GOAWAY frame, the endpoint MUST close the TCP connection."

This section is all about errors. [44aff204]

> So on one hand it appears that GOAWAY is used if corruption is detected
> and is immediately fatal, and the other sending multiple GOAWAY frames
> as an administrative convenience, and then eventually closing the TLS
> or TCP connection. Presumably it's too late to define a new "CLOSING"
> frame type, which might be more appropriate?

That's what NO_ERROR is.

> Other minor stylistic issues:

Received on Monday, 29 September 2014 18:08:40 UTC

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