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

3.5.1 Connection Error Handling

From: (wrong string) 陈智昌 <willchan@chromium.org>
Date: Thu, 9 May 2013 11:24:18 -0300
Message-ID: <CAA4WUYhavygi-3g6usUaXr-k4KdZ7_U2z9Xtry5ySF5N1AXbFA@mail.gmail.com>
To: HTTP Working Group <ietf-http-wg@w3.org>
http://http2.github.io/http2-spec/#ConnectionErrorHandler has this section
which says:
An endpoint that encounters a connection error MUST first send a GOAWAY
(Section 3.8.7) frame with the stream identifier of the last stream that it
successfully received from its peer. The GOAWAY frame includes an error
code that indicates why the connection is terminating. After sending the
GOAWAY frame, the endpoint MUST close the TCP connection.

I'm not sure how to interpret the last line. I see two possible
1) At some point after sending the GOAWAY, it must close the connection.
2) It must close the connection immediately after sending the GOAWAY.

I think interpretation (1) is boring and useless. I think interpretation
(2) would probably be a spec error, since we want to allow time for
completing processing on accepted streams.

I think the description in 3.8.7 gets it mostly correct -
http://http2.github.io/http2-spec/#GOAWAY. Except of course for the noted
issue in the text.
After sending a GOAWAY message, the sender can ignore frames for new

[rfc.comment.8: Issue: connection state that is established by those
"ignored" messages cannot be ignored without the state in the two peers
becoming unsynchronized.]
Received on Thursday, 9 May 2013 14:24:45 UTC

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