Re: 3.5.1 Connection Error Handling

FWIW I believe we implemented interpretation (2) and the only code paths
that we have that lead to connection errors are:

1) receiving a invalid stream-id on a stream open frame
2) receiving a corrupt/invalid frame

Note, if the framing layer cannot continue to process frames, then there is
no reason not to close the connection immediately since you cannot
gracefully close the remaining open streams (assuming flow control is
enabled).

I think (2) is correct and should probably be made explicit in the spec.



On Thu, May 9, 2013 at 7:24 AM, William Chan (陈智昌) <willchan@chromium.org>wrote:

> 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
> interpretations:
> 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
> streams.
>
> [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.]
> """
>