11. Error Handling

An endpoint that detects an error SHOULD signal the existence of that error to its peer. Both transport-level and application-level errors can affect an entire connection; see Section 11.1. Only application-level errors can be isolated to a single stream; see Section 11.2.

The most appropriate error code (Section 20) SHOULD be included in the frame that signals the error. Where this specification identifies error conditions, it also identifies the error code that is used.

A stateless reset (Section 10.3) is not suitable for any error that can be signaled with a CONNECTION_CLOSE or RESET_STREAM frame. A stateless reset MUST NOT be used by an endpoint that has the state necessary to send a frame on the connection.

11.1 Connection Errors

Errors that result in the connection being unusable, such as an obvious violation of protocol semantics or corruption of state that affects an entire connection, MUST be signaled using a CONNECTION_CLOSE frame (Section 19.19).

An endpoint MAY close the connection in this manner, even if the error only affects a single stream.

An endpoint MUST limit the number of error frames it sends. An endpoint MAY send a CONNECTION_CLOSE frame in a packet that contains only that frame, and it SHOULD send this in response to receiving a CONNECTION_CLOSE frame.

11.2 Stream Errors

If an application-level error affects a single stream, but otherwise leaves the connection in a recoverable state, the endpoint can send a RESET_STREAM frame (Section 19.4) with an appropriate error code to terminate just the affected stream.

RESET_STREAM MUST be instigated by the application, though the reasons for sending RESET_STREAM could include detection of an error in the stream by the transport.

Other than RESET_STREAM, an endpoint MUST NOT send a frame on a stream in the "Reset Sent" state or any terminal state -- that is, after sending a RESET_STREAM frame.