Re: 3.5.1 Connection Error Handling

[James M Snell <[e-mail]>]

+1 seems reasonable. I would edit #4 to just say "MAY close the
connection immediately if necessary" as "resource pressure" is not
well defined at all.

On Thu, May 9, 2013 at 10:29 AM, Roberto Peon <[e-mail]> wrote:
>
> 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:
>>
>> 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.]
>>>> """
>>>
>>>
>>
>