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

General Internet-Draft This document introduces a new frame type for transporting gzip-encoded data between peers in the Hypertext Transfer Protocol Version 2 (HTTP/2), and an associated error code for handling invalid encoding.

This document introduces a mechanism for applying gzip encoding to data transported between two endpoints in the Hypertext Transfer Protocol Version 2 (HTTP/2) , analogous to Transfer-Encoding in HTTP/1.1 .

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), a new HTTP/2 setting (, Section 11.3), and a new HTTP/2 error code (, Section 7), to allow the compression of data. Note that while compressing some or all data in a stream might affect the total length of the corresponding HTTP message body, the content-length header, if present, should continue to reflect the total length of the uncompressed data. This is particularly relevant when detecting malformed messages (, Section 8.1.2.6).

SETTINGS_ACCEPT_GZIPPED_DATA (0xTBA) is used to indicate the sender’s ability and willingness to receive GZIPPED_DATA frames. An endpoint MUST NOT send a GZIPPED_DATA frame unless it receives this setting with a value of 1. The initial value is 0, which indicates that GZIPPED_DATA frames are not supported. Any value other than 0 or 1 MUST be treated as a connection error (, Section 5.4.1) of type PROTOCOL_ERROR. An endpoint may advertise support for GZIPPED_DATA frames and later decide that it no longer supports them. After sending an ACCEPT_GZIPPED_DATA setting with the value 0, the endpoint SHOULD continue to accept GZIPPED_DATA frames for a reasonable amount of time to account for frames that may already be in flight.

GZIPPED_DATA frames (type code=0xTBA) are semantically identical to DATA frames (, Section 6.1), but their payload is encoded using gzip compression. Gzip compression is an LZ77 coding with a 32 bit CRC that is commonly produced by the gzip file compression program . Significantly, GZIPPED_DATA frames are subject to flow control (, Section 5.2). Any compression or decompression context for a GZIPPED_DATA frame is unique to that frame.

The GZIPPED_DATA frame contains the following fields: Pad Length: An 8-bit field containing the length of the frame padding in units of octets. This field is optional and is only present if the PADDED flag is set. Data: Encoded application data. The amount of compressed data is the remainder of the frame payload after subtracting the length of the other fields that are present. Padding: Padding octets that contain no application semantic value. Padding octets MUST be set to zero when sending and ignored when receiving. The GZIPPED_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 (, Section 5.1). PADDED (0x8): Bit 4 being set indicates that the Pad Length field is present. A GZIPPED_DATA frame MUST NOT be sent if the ACCEPT_GZIPPED_DATA setting of the peer is set to 0. An intermediary, on receiving a GZIPPED_DATA frame, MAY decode the data and forward it to its downstream peer in one or more DATA frames. If the downstream peer has not advertised support for GZIPPED_DATA frames (by sending an ACCEPT_GZIPPED_DATA setting with the value 1) the intermediary MUST decode the data before forwarding it. If an endpoint detects that the payload of a GZIPPED_DATA frame is not encoded correctly, for example with an incorrect checksum, the endpoint MUST treat this as a stream error (see , Section 5.4.2) of type DATA_ENCODING_ERROR (). The endpoint MAY then choose to immediately send an ACCEPT_GZIPPED_DATA setting with the value 0. If an intermediary propagates a GZIPPED_DATA frame from the source peer to the destination peer without modifying the payload or its encoding, and receives a DATA_ENCODING_ERROR from the receiving peer, it SHOULD pass the error on to the source peer. GZIPPED_DATA frames MUST be associated with a stream. If a GZIPPED_DATA frame is received whose stream identifier field is 0x0, the recipient MUST respond with a connection error (, Section 5.4.1) of type PROTOCOL_ERROR. GZIPPED_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 GZIPPED_DATA frame payload is included in flow control, including the Pad Length and Padding fields if present. If a GZIPPED_DATA frame is received whose stream is not in “open” or “half closed (local)” state, the recipient MUST respond with a stream error (, Section 5.4.2) of type STREAM_CLOSED. The total number of padding octets is determined by the value of the Pad Length field. If the length of the padding is greater than the length of the remainder of the frame payload, the recipient MUST treat this as a connection error (, Section 5.4.1) of type PROTOCOL_ERROR. Note: A frame can be increased in size by one octet by including a Pad Length field with a value of zero. Padding is a security feature; see Section 10.7 of .

The following new error code is defined: DATA_ENCODING_ERROR (0xTBA): The endpoint detected that its peer sent a GZIPPED_DATA frame with an invalid encoding.

Traversing a network segment with small frame size limits introduces the risk of fragmenting an encoded stream.

Further to the Use of Compression in HTTP/2 (, Section 10.6), intermediaries MUST NOT apply compression to DATA frames, or alter the compression of GZIPPED_DATA frames other than decompressing, unless additional information is available that allows the intermediary to identify the source of data. In particular, frames that are not compressed cannot be compressed, and frames that are separately compressed cannot be merged into a single compressed frame.

This document updates the registries for frame types and error codes in the “Hypertext Transfer Protocol (HTTP) 2 Parameters” section. This document also establishes a new registry for HTTP/2 encoding scheme codes. This new registry is entered into 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 GZIPPED_DATA TBD

This document updates the “HTTP/2 Settings” registry (, Section 11.3). The entries in the following table are registered by this document. Frame Type Code Initial Value Specification ACCEPT_GZIPPED_DATA TBD 0

This document updates the “HTTP/2 Error Code” registry (, Section 11.4). The entries in the following table are registered by this document. Name Code Description Specification DATA_ENCODING_ERROR TBD Invalid encoding detected

Thanks to Keith Morgan for his advice, input, and editorial contributions.

Aladdin Enterprises

203 Santa Margarita Ave. Menlo Park CA 94025 US +1 415 322 0103 +1 415 322 1734 ghost@aladdin.com

gzip@prep.ai.mit.edu

madler@alumni.caltech.edu

ghost@aladdin.com

randeg@alumni.rpi.edu

This specification defines a lossless compressed data format that is compatible with the widely used GZIP utility. The format includes a cyclic redundancy check value for detecting data corruption. The format presently uses the DEFLATE method of compression but can be easily extended to use other compression methods. The format can be implemented readily in a manner not covered by patents. Harvard University

1350 Mass. Ave. Cambridge MA 02138 - +1 617 495 3864 sob@harvard.edu

General keyword 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. Authors who follow these guidelines should incorporate this phrase near the beginning of their document: 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. Note that the force of these words is modified by the requirement level of the document in which they are used. 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.</t><t> This specification is an alternative to, but does not obsolete, the HTTP/1.1 message syntax. HTTP's existing semantics remain unchanged. The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document provides an overview of HTTP architecture and its associated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes related security concerns for implementations.

Since -05: changed ACCEPT_ENCODED_DATA back from a frame to a setting, since it carries a single scalar value now Since -04: reduced encoding options to only gzip (suggested by Martin Thomson) remove fragmentation and segment stuff, including reference to ‘http2-segments’ I-D updated HTTP/2 reference from I-D to (freshly published) RFC7230 Since -03: added ‘identity’ encoding; removed ‘compress’ and ‘zlib’ (suggested by PHK) added SEGMENT flag, for segments that don’t continue clarified that ACCEPT is for a connection, and ENCODED_DATA is for a stream copied “padding” text from HTTP/2 draft Since -02: moved all discussion of fragmentation and segments to its own section Since -01: referenced new draft-kerwin-http2-segments to handle fragmentation Since -00: changed ACCEPT_ENCODED_DATA from a complex setting to a frame improved IANA Considerations section (with lots of input from Keith Morgan)