matthew@kerwin.net.au https://matthew.kerwin.net.au/

Applications and Real-Time HTTP H2 This document defines an extension to the Hypertext Transfer Protocol Version 2 (HTTP/2) that allows an endpoint to signal to its peer that an unsupported extension frame was discarded. The issues list for this draft can be found at https://github.com/phluid61/internet-drafts/labels/HTTP%2F2%20NAK%20Frame The most recent (often unpublished) draft is at http://phluid61.github.io/internet-drafts/http2-nak-frame/

Out of the box, the Hypertext Transfer Protocol Version 2 (HTTP/2) makes provision for extension frames to be sent on a connection, with or without prior agreement from either peer, with the assertion that “implementations MUST discard frames that have unknown or unsupported types” (, Section 5.5). However it can be useful to explicitly notify the peer if such a frame is discarded. This document defines an extension to HTTP/2 that allows a peer to signal that a received frame was discarded, without altering the stream or connection state (, Section 5.1), and in particular without triggering an error condition.

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

This document introduces a new HTTP/2 frame type (, Section 11.2).

DROPPED_FRAME frames (type code=0xTBA) can be sent on a connection at any time after the connection preface except in the middle of a header block (, Section 4.3) to indicate that a received extension frame was discarded without any other action being taken.

The DROPPED_FRAME frame contains a single 8-bit integer containing the value of the Type field from the discarded frame. The DROPPED_FRAME frame does not define any flags. An endpoint SHOULD send a DROPPED_FRAME frame for an unknown or unsupported extension frame type the first time it discards a frame of that type. An endpoint MAY send a DROPPED_FRAME frame for a particular frame type only once, even if it discards multiple frames of that type. An endpoint that receives a DROPPED_FRAME frame ought to take it as an indication that the extension is not supported by the peer, and MAY subsequently choose not to send further frames of that type or to attempt extension negotiation with the peer. Receipt of a DROPPED_FRAME frame does not necessarily mean that all frames on that connection with the discarded type will be discarded in future. A transparent intermediary that forwards an extension frame in one direction and a corresponding DROPPED_FRAME frame in the other direction MUST NOT intercept future frames of that type and preemptively reply with a DROPPED_FRAME frame. DROPPED_FRAME frames are not associated with any individual stream. If a DROPPED_FRAME frame is received with a stream identifier field value other than 0x0, the recipient MUST respond with a connection error (, Section 5.4.1) of type PROTOCOL_ERROR. Receipt of a DROPPED_FRAME frame with a length field value other than 1 MUST be treated as a connection error (, Section 5.4.1) of type FRAME_SIZE_ERROR. An endpoint MUST NOT send a DROPPED_FRAME frame with a Type of DROPPED_FRAME (0xTBA). If a DROPPED_FRAME frame is received with a Type field value of 0xTBA, the recipient MUST respond with a connection error (, Section 5.4.1) of type PROTOCOL_ERROR. Extensions that define new HTTP/2 frame types MAY specify behaviours in response to DROPPED_FRAME frames with those types, however extensions that change the semantics of existing protocol components, including those defined in this document, MUST be negotiated before being used (, Section 5.5).

Receipt of a DROPPED_FRAME frame does not guarantee that the sending peer will send one for every frame type it drops, and the absence of a DROPPED_FRAME frame does not imply that the peer has not discarded a frame. Implementations MUST NOT depend on the use of DROPPED_FRAME frames to indicate acceptance or rejection of extension frames.

This document updates the registry for frame types in the “Hypertext Transfer Protocol (HTTP) 2 Parameters” section.

This document updates the “HTTP/2 Frame Type” registry (, Section 11.2). The entries in the following table are registered by this document. Frame Type Code Section DROPPED_FRAME TBD

In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This specification describes an optimized expression of the semantics of the Hypertext Transfer Protocol (HTTP), referred to as HTTP version 2 (HTTP/2). HTTP/2 enables a more efficient use of network resources and a reduced perception of latency by introducing header field compression and allowing multiple concurrent exchanges on the same connection. It also introduces unsolicited push of representations from servers to clients.This specification is an alternative to, but does not obsolete, the HTTP/1.1 message syntax. HTTP's existing semantics remain unchanged. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.