Re: 3.5.1 Connection Error Handling

Ah, I brainfarted when reading the section earlier and was thinking it was
general connection shutdown. Seeing as how this is specifically on
connection errors, it may indeed be reasonable to close the connection
immediately.


On Thu, May 9, 2013 at 12:07 PM, Jeff Pinner <jpinner@twitter.com> wrote:

> 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.]
>> """
>>
>
>