One document matched: draft-bishop-http2-extension-frames-01.xml
<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="lib/rfc2629.xslt"?>
<?rfc toc="yes" ?>
<?rfc tocdepth="2" ?>
<?rfc tocindent="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes"?>
<?rfc subcompact="no" ?>
<?rfc linkmailto="no" ?>
<?rfc editing="no" ?>
<?rfc comments="yes" ?>
<?rfc inline="yes"?>
<?rfc rfcedstyle="yes"?>
<?rfc-ext allow-markup-in-artwork="yes" ?>
<?rfc-ext include-index="no" ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc5226 PUBLIC '' 'http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5226.xml'>
<!ENTITY rfc6709 PUBLIC '' 'http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6709.xml'>
<!ENTITY rfc2119 PUBLIC '' 'http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY alt-svc PUBLIC '' 'http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.draft-ietf-httpbis-alt-svc-01.xml'>
]>
<rfc ipr="trust200902" docName="draft-bishop-http2-extension-frames-01">
<!-- xmlns:x="http://purl.org/net/xml2rfc/ext">
<x:feedback template="mailto:michbish@microsoft.com?subject={docname},%20%22{section}%22&body=<{ref}>:"/> -->
<front>
<title abbrev="Extensions">Extension Frames in HTTP/2</title>
<author initials="M." surname="Bishop" fullname="Mike Bishop">
<organization>Microsoft</organization>
<address>
<email>michbish@microsoft.com</email>
</address>
</author>
<date month="May" year="2014" />
<area>Applications</area>
<workgroup>HTTPbis Working Group</workgroup>
<keyword>HTTP</keyword>
<abstract>
<t>
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.
</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>
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.
</t>
<t>
In the wake of this decision, a number of new frames and subfeatures have been proposed
(<xref target="BLOCKED">BLOCKED</xref>, <xref target="ALTSVC">ALTSVC</xref>,
<xref target="COMPRESSED_DATA">compression of DATA frames</xref>),
delaying the specification and introducing a dependency on
<xref target="I-D.ietf-httpbis-alt-svc">a draft</xref> 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.
</t>
<t>
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.
</t>
<t>
This working group is empowered by its charter to work on additional extensions to HTTP provided
that "[t]he Working Group Chairs ... 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.
</t>
<t>
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.
</t>
<section title="Conventions and Terminology">
<t>
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 <xref target="RFC2119">RFC 2119</xref>.
</t>
<t>
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 <spanx style="verb">0x</spanx> to distinguish them
from decimal literals.
</t>
</section>
</section>
<section anchor="problems" title="Problems an extension model must solve">
<t>
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:
<list style="symbols">
<t>Changes session state, or strictly informative</t>
<t>Flow-controlled third-party data or freely-sent control data</t>
<t>Hop-by-hop or end-to-end</t>
</list>
</t>
<t>
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.
</t>
<t>
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.
<xref target="RFC6709">RFC 6709</xref> 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.
</t>
<t>
Another risk that arises when extension is overly constrained is the emergence of protocol variations.
<xref target="RFC6709">RFC 6709</xref> 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.
</t>
<t>
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.
</t>
<t>
This document proposes an alternative method of supporting extension frames and settings, with the following goals:
<list style="symbols">
<t>Reduce the probability of collision among extensions and between extensions and future versions of HTTP</t>
<t>Enable peers to quickly discover support for a particular extension on the far side</t>
<t>Enable extension implementers to interoperate with minimal procedural overhead</t>
</list>
</t>
</section>
<section title="Extension Functionality">
<section anchor="ExtensionID" title="Extension Identification and Negotiation">
<t>
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 <xref target="Experimental">below</xref>.
</t>
<section anchor="Experimental" title="Experimental Extensions">
<t>
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.
</t>
<t>
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.
</t>
</section>
</section>
<section anchor="Negotiation" title="Extension Negotiation">
<t>
An implementation which supports extensions SHOULD send an <xref target="EXTENSIONS">EXTENSIONS</xref> 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.
</t>
<t>
An empty EXTENSIONS frame declares that the sender does not wish to employ any hop-by-hop extensions beyond
the negotiated protocol.
</t>
<t>
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.
</t>
</section>
<section anchor="Frames" title="New Frames and Modifications">
<section anchor="FrameDef" title="Definition of Frames">
<t>
</t>
<figure title="Frame Header">
<preamble>
To support the notion of end-to-end extension frames, one Reserved bit from the Frame Header
is given a defined meaning:
</preamble>
<artwork type="inline"><![CDATA[
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...) ...
+---------------------------------------------------------------+
]]></artwork>
</figure>
<t>
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.
</t>
<t>
An end-to-end frame on stream zero is meaningless, and MUST be discarded upon receipt.
</t>
<t>
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.
</t>
</section>
<section anchor="EXTENSIONS" title="EXTENSIONS Frame">
<t>
<figure title="EXTENSIONS format">
<preamble>
The EXTENSIONS frame (number TBD) carries a list of zero or more extensions supported
by the sender:
</preamble>
<artwork type="inline">
<![CDATA[
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) |
+---------------------------------------------------------------+
]]>
</artwork>
</figure>
</t>
<t>
For each extension, the sender includes 32 bits of inital state. The semantics of this value
are completely defined by the extension.
</t>
</section>
<section anchor="EXPANDED" title="EXPANDED Frame">
<t>
<figure title="EXPANDED Format">
<preamble>
The EXPANDED frame (number 0xFF) expands the space of frame types by supplying additional bits
for the frame type:
</preamble>
<artwork type="inline">
<![CDATA[
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...) ...
+---------------------------------------------------------------+
]]>
</artwork>
</figure>
</t>
<t>
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.
</t>
<t>
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.
</t>
</section>
<section anchor="ExtensionDefined" title="Extension-Defined Frames">
<t>
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.
</t>
<t>
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.)
</t>
<t>
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 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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<section anchor="Intermediaries" title="Handling by Intermediaries">
<t>
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.
</t>
<t>
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.
</t>
<t>
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:
<list style="symbol">
<t>Relaying to HTTP/1.1 connection</t>
<t>Relaying to HTTP/2 connection without extension support</t>
<t>Relaying to HTTP/2 connection with extension support</t>
</list>
</t>
</section>
</section>
</section>
<section anchor="Settings" title="Settings">
<figure title="Modified Setting Value Format">
<preamble>
This draft restores the definition of a setting value as follows:
</preamble>
<artwork type="inline">
<![CDATA[
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) |
+---------------------------------------------------------------+
]]>
</artwork>
</figure>
<t>
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 <xref target="EXTENSIONS">
EXTENSIONS</xref> frame.
</t>
</section>
</section>
<section title="IANA Considerations">
<t>
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:
<list style="symbols">
<t>Frame types, with values less than 256 restricted to standards-track RFCs and values
greater than 0x80000000 reserved for private experimental use</t>
<t>Setting identifiers, with values greater than 0xFFFF0000 reserved for private experimental use</t>
<t>Error codes</t>
</list>
And additionally, the creation of a registry for Extension IDs, with values above 0xFFFF0000
reserved for private experimental use.
</t>
<t>
Given the expanded space, these registries should be allocated on a <xref target="RFC5226">
first-come-first-served</xref> basis except as described above, though a publicly-available specification for each extension is
strongly recommended.
</t>
</section>
</middle>
<back>
<references title="References">
&rfc2119;
&rfc5226;
&rfc6709;
&alt-svc;
</references>
<section title="Example Extensions" anchor="Examples">
<t>
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.
</t>
<section anchor="BLOCKED" title="Blocked Flow-Control Announcement Extension">
<section title="EXTENSIONS Payload">
<t>
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.
</t>
</section>
<section title="BLOCKED Frame">
<t>
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.
</t>
</section>
<section title="Use of BLOCKED Frame">
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
</section>
<section title="Behavior by Intermediaries">
<t>
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.
</t>
</section>
</section>
<section anchor="ALTSVC" title="Alternate-Service Announcement">
<section title="EXTENSIONS Payload">
<t>
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.
</t>
</section>
<section title="ALTSVC Frame">
<figure title="ALTSVC Frame Payload">
<artwork>
<![CDATA[
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? (*) ...
+---------------------------------------------------------------+
]]>
</artwork>
</figure>
<t>
The ALTSVC frame contains the following fields:
<list style="hanging">
<t hangText="Max-Age:">
An unsigned, 32-bit integer indicating the freshness lifetime of the alternative
service association.
</t>
<t hangText="Port:">
An unsigned, 16-bit integer indicating the port that the alternative service is
available upon.
</t>
<t hangText="Proto-Len:">
An unsigned, 8-bit integer indicating the length, in octets, of the Protocol-ID field.
</t>
<t hangText="Protocol-ID:">
A sequence of bytes (length determined by <spanx style="verb">Proto-Len</spanx>)
containing the ALPN protocol identifier of the alternative service.
</t>
<t hangText="Host-Len:">
An unsigned, 8-bit integer indicating the length, in octets, of the Host field.
</t>
<t hangText="Host:">
A sequence of characters (length determined by <spanx style="verb">Host-Len</spanx>)
containing an ASCII string indicating the host that the alternative service is
available upon. An internationalized domain name MUST be
expressed using A-labels.
</t>
<t hangText="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.
</t>
</list>
</t>
<t>
The ALTSVC frame does not define any flags.
</t>
</section>
<section title="Use of ALTSVC Frame">
<t>
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 <xref
target="I-D.ietf-httpbis-alt-svc"/> for details.
</t>
<t>
An ALTSVC frame on a client-initiated stream indicates that the conveyed alternative
service is associated with the origin of that stream.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
</section>
<section title="Behavior by Intermediaries">
<t>
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.
</t>
</section>
</section>
<section anchor="COMPRESSED_DATA" title="Compressed Data Frames">
<t>
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.
</t>
<section title="EXTENSIONS Payload">
<figure title="Compressed Data in EXTENSIONS">
<preamble>
Support for the Compressed Data Extension is indicated by the following in an EXTENSIONS
frame:
</preamble>
<artwork>
<![CDATA[
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) |
+---------------+-----------------------------------------------+
]]>
</artwork>
</figure>
<t>
The EXTENSIONS entry contains the following fields:
<list style="hanging">
<t hangText="Extension ID:">
The extension ID for the Compressed Data Extension is 0x53F9F537.
</t>
<t hangText="Contexts">
An eight-bit count of the number of separate compression contexts
the sender is willing to maintain. This SHOULD be greater than zero.
</t>
<t hangText="Supported algorithms">
A bitmap of compression algorithms supported by the sender:
<list style="hanging">
<t hangText="0x001: Compress">The "compress" coding is an adaptive Lempel-Ziv-Welch (LZW) coding that
is commonly produced by the UNIX file compression program "compress".</t>
<t hangText="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.</t>
<t hangText="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].</t>
<t hangText="Other bits:">
Reserved for future updates; MUST be zero when sent
and ignored upon receipt
</t>
</list>
Setting the corresponding bit indicates that the sender supports creating
a compression context for the corresponding algorithm.
</t>
</list>
</t>
</section>
<section title="COMPRESSED_DATA Frame">
<t>
The COMPRESSED_DATA frame defines the following flags:
<list style="hanging">
<t hangText="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.
</t>
<t hangText="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.
</t>
<t hangText="PAD_LOW (0x8):">
Bit 4 being set indicates that the Pad Low field is present.
</t>
<t hangText="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.
</t>
<t hangText="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.
</t>
<t hangText="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.
</t>
</list>
</t>
<t>
<figure title="COMPRESSED_DATA">
<preamble>
The payload is formatted as follows:
</preamble>
<artwork>
<![CDATA[
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? (*) ...
+---------------------------------------------------------------+
]]>
</artwork>
</figure>
The fields are:
<list style="hanging">
<t hangText="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.
</t>
<t hangText="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.
</t>
<t hangText="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.
</t>
<t hangText="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.
</t>
<t hangText="Compressed payload">
The remainder of the payload is the compressed content,
interpreted using the selected compression context.
</t>
<t hangText="Padding:">
Padding octets that contain no application semantic value. Padding octets MUST be set
to zero when sending and ignored when receiving.
</t>
</list>
</t>
</section>
<section title="Use of COMPRESSED_DATA Frame">
<t>
The COMPRESSED_DATA frame may be sent instead of a DATA frame provided that both of the following
are true:
<list style="symbol">
<t>The sender is allowed to send a DATA frame at this time on this stream</t>
<t>The recipient has advertised support for the Compressed Data Extension</t>
</list>
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
</section>
<section title="Behavior by Intermediaries">
<t>
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.
</t>
<t>
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.
</t>
<t>
Intermediaries MUST NOT convert DATA frames into COMPRESSED_DATA frames.
</t>
</section>
</section>
</section>
<section title="Acknowledgements">
<t>
This document includes input from Rob Trace, Gabriel Montenegro, and James Snell.
</t>
<t>
Sample extensions are based largely on the work of Mark Nottingham,
Roberto Peon, and Matthew Kerwin.
</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 09:28:49 |