HTTPbis Working Group M. Bishop Internet-Draft Microsoft Expires: November 23, 2014 May 22, 2014 Extension Frames in HTTP/2 draft-bishop-http2-extension-frames-01 Abstract This document describes a proposed modification to the HTTP/2 specification to better support the creation of extensions without the need to version the core protocol or invoke additional protocol identifiers. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on November 23, 2014. Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Bishop Expires November 23, 2014 [Page 1] Internet-Draft Extensions May 2014 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Conventions and Terminology . . . . . . . . . . . . . . . 3 2. Problems an extension model must solve . . . . . . . . . . . 3 3. Extension Functionality . . . . . . . . . . . . . . . . . . . 4 3.1. Extension Identification and Negotiation . . . . . . . . 4 3.2. Extension Negotiation . . . . . . . . . . . . . . . . . . 5 3.3. New Frames and Modifications . . . . . . . . . . . . . . 5 3.4. Settings . . . . . . . . . . . . . . . . . . . . . . . . 8 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 Appendix A. Example Extensions . . . . . . . . . . . . . . . . . 11 A.1. Blocked Flow-Control Announcement Extension . . . . . . . 11 A.2. Alternate-Service Announcement . . . . . . . . . . . . . 12 A.3. Compressed Data Frames . . . . . . . . . . . . . . . . . 14 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 18 1. Introduction HTTP/2 previously offered an inconsistent story about the use of extensions. Following a discussion of the previous version of this draft, the working group reached consensus to prohibit all extensibility, declaring that any new functionality would constitute the creation of a new protocol with a new ALPN identifier. This was driven in large part by a desire not to delay the specification while an extension model was finalized and implemented. In the wake of this decision, a number of new frames and subfeatures have been proposed (BLOCKED (Appendix A.1), ALTSVC (Appendix A.2), compression of DATA frames (Appendix A.3)), delaying the specification and introducing a dependency on a draft [I-D.ietf-httpbis-alt-svc] which is not as close to ready for last call as the core HTTP/2 specification. Others, such as DRAINING, have been suggested on the mailing list though not introduced to the specification. Many of these features are optional either to use or to process, limiting their broad applicability. In the words of Antoine de Saint-Exupery, "Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away." Many of these frames represent concerns which, while worth addressing, are not fundamental to the goals of HTTP/2. The HTTP/2 specification should be the minimal set of features which enables two peers to communicate efficiently and achieve the goals laid out in the working group charter. This working group is empowered by its charter to work on additional extensions to HTTP provided that "[t]he Working Group Chairs ... Bishop Expires November 23, 2014 [Page 2] Internet-Draft Extensions May 2014 believe that it will not interfere with the work described above [definition of HTTP/2]." The working group is explicitly prohibited from defining HTTP/2 extensions until the HTTP/2 work is complete. This draft contends that some or all of these late-breaking features could be easily recast as extensions, simplifying and unblocking the core specification. Existing implementations of these features would test the extensibility model in the process of interoperating with others who have chosen not to implement them, permitting us to finalize HTTP/2 and turn our attention to the set of extensions the working group has already reached consensus should be explored. 1.1. Conventions and Terminology 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 RFC 2119 [RFC2119]. All numeric values are in network byte order. Values are unsigned unless otherwise indicated. Literal values are provided in decimal or hexadecimal as appropriate. Hexadecimal literals are prefixed with "0x" to distinguish them from decimal literals. 2. Problems an extension model must solve Possible extensions vary along a number of pivots. Any extension model must define how extensions will work along each pivot, which may include disallowing certain combinations. Possible variants of extensions include: o Changes session state, or strictly informative o Flow-controlled third-party data or freely-sent control data o Hop-by-hop or end-to-end There is no way to know whether the peer supports a given extension before sending extension-specific information. This can be simply addressed by saying that implementations MUST ignore frame types and settings values they don't understand. However, this model only works for strictly informative frames and/or settings. An extension model must define a way to determine whether a peer supports a given extension, if non-informative extensions are supported. Another concern is that with only 256 frame types, the frame type space may be exhausted if many extensions are defined. Different extensions could collide with each other in the choice of frame type identifiers, since the space is limited. RFC 6709 [RFC6709] Bishop Expires November 23, 2014 [Page 3] Internet-Draft Extensions May 2014 discusses in detail the trade-offs that must be considered by any protocol's extension model. One key risk is that a difficult registration process will encourage the use of unregistered extensions, which leads to collisions, but a small space requires rigorous control over the identifier space. Another risk that arises when extension is overly constrained is the emergence of protocol variations. RFC 6709 [RFC6709] has this to say: "Protocol variations -- specifications that look very similar to the original but don't interoperate with each other or with the original -- are even more harmful to interoperability than extensions." Where no extensions are possible, implementers who wish to extend HTTP/2 will quickly move to define a new protocol which looks remarkably similar to HTTP/2, but is not interoperable. Future protocols using the HTTP/2 framing layer will face exactly the same problem as extension authors, since they share a frame type and setting value space with any extensions. Thus, a new frame introduced with, for example, HTTP/3 must avoid collision with any HTTP/2 extensions and must deal with space exhaustion. Any means of resolving such adoption after the fact complicates forward-porting of existing extensions. This document proposes an alternative method of supporting extension frames and settings, with the following goals: o Reduce the probability of collision among extensions and between extensions and future versions of HTTP o Enable peers to quickly discover support for a particular extension on the far side o Enable extension implementers to interoperate with minimal procedural overhead 3. Extension Functionality 3.1. Extension Identification and Negotiation An extension to HTTP/2 is identified by an Extension ID. An Extension ID is a 32-bit identifier registered with IANA. Extension identifiers above 0xFFFF0000 are reserved for experimental use, as described below (Section 3.1.1). Bishop Expires November 23, 2014 [Page 4] Internet-Draft Extensions May 2014 3.1.1. Experimental Extensions The designer of an extension MAY self-allocate an extension ID in the experimental range defined above without interaction with IANA. Such an extension MUST use only frame numbers and setting IDs from the experimental range. These extensions MUST NOT be generally deployed until a non-experimental extension ID has been allocated. As a further guard against accidental collisions, an experimental extension SHOULD define a random 32-bit number, and include this number as the first four bytes of each frame used by the extension. Received frames which do not include this identifier MUST be treated as an unrecognized frame type. 3.2. Extension Negotiation An implementation which supports extensions SHOULD send an EXTENSIONS (Section 3.3.2) frame immediately following its SETTINGS frame at connection establishment, listing all extensions that it wishes to use during the lifetime of the connection. After receiving a corresponding EXTENSIONS frame, any extensions which were present in both frames are considered to be in effect for the lifetime of the connection. The EXTENSIONS frame may be sent only once per connection. An empty EXTENSIONS frame declares that the sender does not wish to employ any hop-by-hop extensions beyond the negotiated protocol. Extension-defined hop-by-hop frames and settings which modify stream or session state (including flow control) MUST NOT be sent until the EXTENSIONS frame has been received from the remote endpoint declaring support for the associated extension ID. Extension-defined frames and settings which are strictly informative MAY be sent between sending the EXTENSIONS frame and before receiving the peer's EXTENSIONS frame. Implementations SHOULD NOT send informative frames or settings from any extension after receiving an EXTENSIONS frame which does not list support for that extension, since the receiver likely will not understand the extra information. 3.3. New Frames and Modifications 3.3.1. Definition of Frames Bishop Expires November 23, 2014 [Page 5] Internet-Draft Extensions May 2014 To support the notion of end-to-end extension frames, one Reserved bit from the Frame Header is given a defined meaning: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | R | Length (14) | Type (8) | Flags (8) | +-+-+-----------+---------------+-------------------------------+ |E| Stream Identifier (31) | +-+-------------------------------------------------------------+ | Frame Payload (0...) ... +---------------------------------------------------------------+ Frame Header The newly-added "E" field marks whether a frame is intended for end- to-end transmission or hop-by-hop transmission. End-to-end frames MUST be relayed by intermediaries, even if the frame type is unknown. Such frames do not imply any changes to stream or session state. End-to-end frames are always subject to flow control. An end-to-end frame on stream zero is meaningless, and MUST be discarded upon receipt. Of the frames defined in the base HTTP/2 spec, DATA frames MUST set the E bit; all other control frames (WINDOW_UPDATE, PUSH_PROMISE, HEADERS, etc.) MUST NOT set the E bit. Receipt of a base HTTP/2 frame with the E bit set improperly indicates a fundamental error in the remote implementation, and MUST trigger a connection error of type PROTOCOL_ERROR. 3.3.2. EXTENSIONS Frame The EXTENSIONS frame (number TBD) carries a list of zero or more extensions supported by the sender: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extension ID (32) | +---------------------------------------------------------------+ | Extension-specific data (32) | +---------------------------------------------------------------+ EXTENSIONS format Bishop Expires November 23, 2014 [Page 6] Internet-Draft Extensions May 2014 For each extension, the sender includes 32 bits of inital state. The semantics of this value are completely defined by the extension. 3.3.3. EXPANDED Frame The EXPANDED frame (number 0xFF) expands the space of frame types by supplying additional bits for the frame type: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| Expanded Frame Type (31) | +---------------------------------------------------------------+ | Frame Payload (0...) ... +---------------------------------------------------------------+ EXPANDED Format In order to mitigate the concern that 256 frame types are too few to allow free access to extensions, the EXPANDED frame defines an additional 31 bits that can be used for the frame type space. Frame types numbered 256 or greater are encoded within an EXPANDED frame, and the Expanded Frame Type field set to the desired frame type value minus 256. This increases the maximum frame type to 0x80000100 without increasing the frame size for common frame types. Implementations which have no knowledge of frame types greater than 255 MAY ignore any EXPANDED frames upon receipt, though intermediaries MUST still relay end-to-end EXPANDED frames. 3.3.4. Extension-Defined Frames An extension MAY define new frame types, which are registered with IANA. Frame types greater than 0x80000000 will not be allocated by IANA and are reserved for use by experimental extensions. Frame types less than 256 are reserved for assignment by standards-track RFCs. As part of the definition of the extension and frame type, the extension MUST specify whether the frames it defines modify session state in any way, including being flow-controlled. (Any frame which modifies session state MUST NOT be sent prior to receipt of an EXTENSIONS frame declaring support for the specified extension.) Only frames which do not change stream or session state may be marked as end-to-end, since intermediaries which do not understand the frame Bishop Expires November 23, 2014 [Page 7] Internet-Draft Extensions May 2014 type would not be able to track the state changes. Because end-to- end frames have unknown payload and provenance, end-to-end frames are always flow-controlled. Frames which do not modify stream or session state MAY be sent at any time. However, an implementation SHOULD NOT send hop-by-hop extension frames after receiving an EXTENSIONS frame indicating that the other party will not understand the frame being sent. An extension has complete freedom to define the payload, flags, and other semantics of the frames it specifies, including when and on what streams the frame may or may not be sent. 3.3.4.1. Handling by Intermediaries Intermediaries MUST forward all end-to-end frames regardless of whether they recognize the frame type. Endpoints (user agents and origin servers) MUST discard any frame types which they do not recognize. Such frames are, by definition, informational and can be safely ignored without affecting the shared state with the sender. All hop-by-hop extension-defined frames MUST be dropped by intermediaries which do not support the extension. However, each extension SHOULD specify how an intermediary translates the frames defined by the extension toward other peers which might or might not support the same extension. When an intermediary advertises support for an extension, it MUST abide by the extension-defined intermediary behavior. An intermediary which advertises support for an extension is explicitly not guaranteeing that all peers to which it will relay information support the same extensions. Extension definitions SHOULD define how intermediaries translate in the following situations: Relaying to HTTP/1.1 connection Relaying to HTTP/2 connection without extension support Relaying to HTTP/2 connection with extension support 3.4. Settings Bishop Expires November 23, 2014 [Page 8] Internet-Draft Extensions May 2014 This draft restores the definition of a setting value as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identifier (32) | +---------------------------------------------------------------+ | Value (32) | +---------------------------------------------------------------+ Modified Setting Value Format Extensions may define settings whose identifiers are registered with IANA. The semantics of any such setting value are defined strictly by the extension. Implementations MUST ignore unknown settings and MUST NOT emit settings defined by an extension which has not been announced in an EXTENSIONS (Section 3.3.2) frame. 4. IANA Considerations This draft proposes the restoration to the HTTP/2 spec of IANA registries for the following, pre-populated with the values defined in the HTTP/2 specification: o Frame types, with values less than 256 restricted to standards- track RFCs and values greater than 0x80000000 reserved for private experimental use o Setting identifiers, with values greater than 0xFFFF0000 reserved for private experimental use o Error codes And additionally, the creation of a registry for Extension IDs, with values above 0xFFFF0000 reserved for private experimental use. Given the expanded space, these registries should be allocated on a first-come-first-served [RFC5226] basis except as described above, though a publicly-available specification for each extension is strongly recommended. 5. References Bishop Expires November 23, 2014 [Page 9] Internet-Draft Extensions May 2014 [I-D.ietf-httpbis-alt-svc] Nottingham, M., McManus, P., and J. Reschke, "HTTP Alternative Services", draft-ietf-httpbis-alt-svc-01 (work in progress), April 2014. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [RFC6709] Carpenter, B., Aboba, B., and S. Cheshire, "Design Considerations for Protocol Extensions", RFC 6709, September 2012. Bishop Expires November 23, 2014 [Page 10] Internet-Draft Extensions May 2014 Appendix A. Example Extensions This section describes how certain extensions might leverage the above model. Because a number of recent additions to the HTTP/2 specifications are excellent candidates for extension definition, they are used as examples here. A.1. Blocked Flow-Control Announcement Extension A.1.1. EXTENSIONS Payload Support for the Blocked Flow Control Announcement Extension is indicated by including extension ID 0xB39D237F in an EXTENSIONS frame. The initial data in the EXTENSIONS frame MUST be zero when sent and MUST be ignored on receipt. A.1.2. BLOCKED Frame The BLOCKED frame defines no flags and contains no interpretable payload. Because the frame is experimental, each BLOCKED frame MUST contain the static payload 0xABED6142 for disambiguation. A receiver MUST treat the receipt of a BLOCKED frame with any other payload as an unknown frame type and ignore it. A.1.3. Use of BLOCKED Frame The BLOCKED frame is used to provide feedback about the performance of flow control for the purposes of performance tuning and debugging. The BLOCKED frame can be sent by a peer when flow controlled data cannot be sent due to the connection- or stream-level flow control window being zero or less. This frame MUST NOT be sent if there are other reasons preventing data from being sent, such as a lack of available data or the underlying transport being blocked. The BLOCKED frame MAY be sent on a connection prior to receiving an EXTENSIONS frame, but SHOULD NOT be sent after the receipt of an EXTENSIONS frame which does not include the BLOCKED extension ID. The BLOCKED frame is sent on the stream that is blocked, that is, the stream with a non-positive number of bytes available in the flow control window. A BLOCKED frame can be sent on stream 0x0 to indicate that connection-level flow control is blocked. An endpoint MUST NOT send any subsequent BLOCKED frames until the affected flow control window becomes positive. This means that WINDOW_UPDATE frames are received or SETTINGS_INITIAL_WINDOW_SIZE is increased before more BLOCKED frames can be sent. Bishop Expires November 23, 2014 [Page 11] Internet-Draft Extensions May 2014 A.1.4. Behavior by Intermediaries Because flow-control is hop-by-hop, intermediaries MUST NOT relay a BLOCKED frame onto any other connection. If the intermediary is blocked by flow control, they MAY generate BLOCKED frames independently on other connections where BLOCKED is supported. A.2. Alternate-Service Announcement A.2.1. EXTENSIONS Payload Support for the Alternate Service Announcement Extension is indicated by including extension ID 0x8877B974 in an EXTENSIONS frame. The initial data in the EXTENSIONS frame MUST be zero when sent and MUST be ignored on receipt. A.2.2. ALTSVC Frame 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max-Age (32) | +-------------------------------+---------------+---------------+ | Port (16) | Proto-Len (8) | +-------------------------------+---------------+---------------+ | Protocol-ID (*) | +---------------+-----------------------------------------------+ | Host-Len (8) | Host (*) ... +---------------+-----------------------------------------------+ | Origin? (*) ... +---------------------------------------------------------------+ ALTSVC Frame Payload The ALTSVC frame contains the following fields: Max-Age: An unsigned, 32-bit integer indicating the freshness lifetime of the alternative service association. Port: An unsigned, 16-bit integer indicating the port that the alternative service is available upon. Proto-Len: An unsigned, 8-bit integer indicating the length, in octets, of the Protocol-ID field. Bishop Expires November 23, 2014 [Page 12] Internet-Draft Extensions May 2014 Protocol-ID: A sequence of bytes (length determined by "Proto-Len") containing the ALPN protocol identifier of the alternative service. Host-Len: An unsigned, 8-bit integer indicating the length, in octets, of the Host field. Host: A sequence of characters (length determined by "Host-Len") containing an ASCII string indicating the host that the alternative service is available upon. An internationalized domain name MUST be expressed using A-labels. Origin: An optional sequence of characters (length determined by subtracting the length of all preceding fields from the frame length) containing the ASCII serialisation of an origin that the alternate service is applicable to. The ALTSVC frame does not define any flags. A.2.3. Use of ALTSVC Frame The ALTSVC frame (type=0xA) advertises the availability of an alternative service to the client. It can be sent at any time for an existing client-initiated stream or stream 0, and is intended to allow servers to load balance or otherwise segment traffic; see [I-D.ietf-httpbis-alt-svc] for details. An ALTSVC frame on a client-initiated stream indicates that the conveyed alternative service is associated with the origin of that stream. An ALTSVC frame on stream 0 indicates that the conveyed alternative service is associated with the origin contained in the Origin field of the frame. An association with an origin that the client does not consider authoritative for the current connection MUST be ignored. The ALTSVC frame is intended for receipt by clients; a server that receives an ALTSVC frame MAY treat it as a connection error of type PROTOCOL_ERROR. A server MAY send an ALTSVC frame before receiving an EXTENSIONS frame listing support for the Alternate-Service Availability Announcement extension, but SHOULD NOT send an ALTSVC frame after receiving an EXTENSIONS frame which does not declare support. Bishop Expires November 23, 2014 [Page 13] Internet-Draft Extensions May 2014 A.2.4. Behavior by Intermediaries The ALTSVC frame is processed hop-by-hop. An intermediary MUST NOT forward ALTSVC frames, though it can use the information contained in ALTSVC frames in forming new ALTSVC frames to send to its own clients. A.3. Compressed Data Frames The COMPRESSED_DATA frame (type=TBD) permits a frame-by-frame choice of transfer encoding, permitting connections to employ compression where appropriate while still enabling the separation of different data into different contexts as appropriate. A.3.1. EXTENSIONS Payload Support for the Compressed Data Extension is indicated by the following in an EXTENSIONS frame: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extension ID (32) | +---------------+-----------------------------------------------+ | Contexts (8) | Supported algorithms (24) | +---------------+-----------------------------------------------+ Compressed Data in EXTENSIONS The EXTENSIONS entry contains the following fields: Extension ID: The extension ID for the Compressed Data Extension is 0x53F9F537. Contexts An eight-bit count of the number of separate compression contexts the sender is willing to maintain. This SHOULD be greater than zero. Supported algorithms A bitmap of compression algorithms supported by the sender: 0x001: Compress The "compress" coding is an adaptive Lempel-Ziv- Welch (LZW) coding that is commonly produced by the UNIX file compression program "compress". Bishop Expires November 23, 2014 [Page 14] Internet-Draft Extensions May 2014 0x002: Deflate The "deflate" coding is a "zlib" data format [RFC1950] containing a "deflate" compressed data stream [RFC1951] that uses a combination of the Lempel-Ziv (LZ77) compression algorithm and Huffman coding. 0x003: GZip The "gzip" coding is an LZ77 coding with a 32 bit CRC that is commonly produced by the gzip file compression program [RFC1952]. Other bits: Reserved for future updates; MUST be zero when sent and ignored upon receipt Setting the corresponding bit indicates that the sender supports creating a compression context for the corresponding algorithm. A.3.2. COMPRESSED_DATA Frame The COMPRESSED_DATA frame defines the following flags: END_STREAM (0x1): Bit 1 being set indicates that this frame is the last that the endpoint will send for the identified stream. Setting this flag causes the stream to enter one of the "half closed" states or the "closed" state. END_SEGMENT (0x2): Bit 2 being set indicates that this frame is the last for the current segment. Intermediaries MUST NOT coalesce frames across a segment boundary and MUST preserve segment boundaries when forwarding frames. PAD_LOW (0x8): Bit 4 being set indicates that the Pad Low field is present. PAD_HIGH (0x10): Bit 5 being set indicates that the Pad High field is present. This bit MUST NOT be set unless the PAD_LOW flag is also set. Endpoints that receive a frame with PAD_HIGH set and PAD_LOW cleared MUST treat this as a connection error of type PROTOCOL_ERROR. Init_Context (0x20): Indicates the presence of the Algorithm and Initialization fields in the COMPRESSED_DATA frame. MUST be set on the first frame to reference a context which has not previously been used, or which has been cleared. If set on any other frame, the previous value of the context MUST be discarded before further processing. Clear_Context (0x40): Indicates that this is the last frame which will use the current context state, and that the context MUST be discarded after interpretation of the current frame. Bishop Expires November 23, 2014 [Page 15] Internet-Draft Extensions May 2014 The payload is formatted as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Pad High? (8) | Pad Low? (8) | Context (8) | Algorithm? (8)| +---------------+---------------+---------------+---------------+ | Compressed payload (*) ... +---------------+-----------------------------------------------+ | Padding? (*) ... +---------------------------------------------------------------+ COMPRESSED_DATA The fields are: Pad High: An 8-bit field containing an amount of padding in units of 256 octets. This field is optional and is only present if the PAD_HIGH flag is set. This field, in combination with Pad Low, determines how much padding there is on a frame. Pad Low: An 8-bit field containing an amount of padding in units of single octets. This field is optional and is only present if the PAD_LOW flag is set. This field, in combination with Pad High, determines how much padding there is on a frame. Context: An eight-bit value reflecting which of the connection's contexts the sender intends to use. This MUST be less than the value the recipient declared in EXTENSIONS. Algorithm: Present only if the Init_Context flag is set. Declares the compression algorithm the sender intends to employ on the new context. Integer taken from the same list employed in the EXTENSIONS frame to announce support. Compressed payload The remainder of the payload is the compressed content, interpreted using the selected compression context. Padding: Padding octets that contain no application semantic value. Padding octets MUST be set to zero when sending and ignored when receiving. Bishop Expires November 23, 2014 [Page 16] Internet-Draft Extensions May 2014 A.3.3. Use of COMPRESSED_DATA Frame The COMPRESSED_DATA frame may be sent instead of a DATA frame provided that both of the following are true: The sender is allowed to send a DATA frame at this time on this stream The recipient has advertised support for the Compressed Data Extension The sender SHOULD clear contexts, use different contexts, or compress selectively to prevent attacker-controlled data from being compressed in the same compression context as server-controlled data. COMPRESSED_DATA frames are subject to flow control and can only be sent when a stream is in the "open" or "half closed (remote)" states. The entire frame payload is included in flow control, including Pad Low, Pad High, Context, Algorithm, Initialization, and Padding fields if present. If a COMPRESSED_DATA frame is received whose stream is not in "open" or "half closed (local)" state, the recipient MUST respond with a stream error of type STREAM_CLOSED. After processing flow control, the frame is decompressed and the result processed as if a DATA frame with the decompressed payload had just been received. If the COMPRESSED_DATA frame had the Clear_Context flag set, the sender MUST discard the compression context immediately following compression, and the recipient MUST do likewise immediately after decompression. A.3.4. Behavior by Intermediaries COMPRESSED_DATA frames are processed hop-by-hop, though an intermediary MAY relay the same compressed content onto another connection if an identical compression context is available. Intermediaries MAY convert COMPRESSED_DATA frames to use different compression schemes on different connections, and MAY convert COMPRESSED_DATA frames into DATA frames on connections which do not support this extension or which do not support a compression algorithm to which the intermediary is willing to convert. Intermediaries MUST NOT convert DATA frames into COMPRESSED_DATA frames. Bishop Expires November 23, 2014 [Page 17] Internet-Draft Extensions May 2014 Appendix B. Acknowledgements This document includes input from Rob Trace, Gabriel Montenegro, and James Snell. Sample extensions are based largely on the work of Mark Nottingham, Roberto Peon, and Matthew Kerwin. Author's Address Mike Bishop Microsoft EMail: michbish@microsoft.com Bishop Expires November 23, 2014 [Page 18]