matthew@kerwin.net.au http://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 for non-destructive signalling of unsupported extension frames. Note to Readers 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 frame types to be sent on a connection, with or without prior agreement from either or both peers, 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”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in .

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 to indicate that a received frame was discarded without any 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 frame type the first time it discards such a frame. An endpoint MAY send a DROPPED_FRAME frame for a particular incoming 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 to not send further frames of that type to or to enter into extension negotiations with the peer. 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.

This specification does not introduce any new security considerations.

This document updates the registriy 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.