Re: 3.5.1 Connection Error Handling

[Roberto Peon <[e-mail]>]

I think the text is fine as is unless someone wants to include some text
like the above indicating that the GOAWAY should actually hit the wire
before closing the connection. As you want to be sure that the GOAWAY is
actually emitted to the NIC's interface before doing close(). On many
systems, if you don't wait for this to drain, then you end up discarding
all queued data in the socket buffer.

The most correct text would be something like:
After generating and sending the GOAWAY the endpoint:
1) MUST not enqueue any more bytes to be sent to the endpoint.
2) SHOULD close the connection immediately after the send buffers including
the GOAWAY have drained onto the network.
3) MUST discard any further received bytes from its peer without processing.
4) MAY close the connection immediately if under resource pressure.

Note that with this wording one could still close the connection before the
GOAWAY has been sent/drained. This must always be a possibility, else you
subject yourself to resource exhaustion attacks.

-=R


On Thu, May 9, 2013 at 8:52 AM, William Chan (陈智昌) <[e-mail]>wrote;wrote:

> 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 <[e-mail]> 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 (陈智昌) <[e-mail]
>> > 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.]
>>> """
>>>
>>
>>
>