HTTP/2 "Dropped Frame" Framematthew@kerwin.net.auhttp://matthew.kerwin.net.au/
Applications and Real-Time
HTTPH2This 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 ReadersThe issues list for this draft can be found at https://github.com/phluid61/internet-drafts/labels/HTTP%2F2%20NAK%20FrameThe 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 TypeCodeSectionDROPPED_FRAMETBDKey words for use in RFCs to Indicate Requirement LevelsIn 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.Hypertext Transfer Protocol Version 2 (HTTP/2)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.