One document matched: draft-snell-httpbis-ext-frames-00.xml
<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY rfc6265 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6265.xml'>
]>
<?rfc toc="yes"?>
<?rfc strict="yes"?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?>
<rfc category="info" ipr="trust200811" docName="draft-snell-httpbis-ext-frames-00">
<front>
<title abbrev="Extension Frame Types for HTTP 2.0">
HTTP/2.0 Discussion: Extension Frame Types
</title>
<author initials="J.M." surname="Snell" fullname="James M Snell">
<address>
<email>jasnell@gmail.com</email>
</address>
</author>
<date month="May" year="2013" />
<keyword>I-D</keyword>
<keyword>http</keyword>
<keyword>spdy</keyword>
<abstract>
<t>This memo describes the structure and use cases for a handful of
"extension" frames types for HTTP 2.0. The purpose of this document
is to add to the overall discussion around the development of HTTP 2.0
by describing ways in which the framing layer can be leveraged and
extended.</t>
</abstract>
</front>
<middle>
<section title="The 'CONTEXT' Frame Type" anchor="context-frames">
<t>The 'CONTEXT' frame type is modeled after the existing 'HEADERS'
frame and is intended to provide application-level contextual information.
It is intended to provide a clear separation between name+value pairs
intended for use as protocol headers (contained in HEADERS frames),
and name+value pairs intended for application use.</t>
<t>Currently, there are two distinct use cases identified for the
'CONTEXT' frame: 1) use as an efficient replacement for Set-Cookie
and Cookie headers and 2) use as an efficient replacement for the
use of Multipart MIME packaging in HTTP messages.</t>
<t>The syntax of the 'CONTEXT' frame is identical to that of the
'HEADERS' frame but defines the following additional type specific
flags:
<list style="hanging">
<t hangText="PERSIST (0x04)">Store the context</t>
<t hangText="CLEAR (0x08)">Clear existing stored context</t>
<t hangText="PERSISTED (0x10)">From stored context</t>
<t hangText="HTTPONLY (0x20)">Equivalent to Set-Cookie HttpOnly parameter</t>
<t hangText="SECURE (0x40)">Equivalent to Set-Cookie Secure parameter</t>
</list>
</t>
<section title="Using 'CONTEXT' as a 'Set-Cookie' and 'Cookie' Replacement">
<t>Currently, the Set-Cookie and Cookie header fields are used to
essentially provide a sub-layer of name-value pairs associated with
an HTTP request or response. The serialization of these header
field values is suboptimal. Even in the header compression proposals
being put forward for HTTP 2.0, special handling of these fields to
improve encoding efficiency has been suggested.</t>
<t>By replacing 'Set-Cookie' and 'Cookie' with the 'CONTEXT' frame,
we allow that sub-layer of name+value pairs to take full direct
advantage of the header compression proposals as well as the
typed-codec proposal introduced by the Stored Header Encoding
proposal.</t>
<t>The 'Set-Cookie' header can be replaced by a server sending a
'CONTEXT' frame in a stream with the 'PERSIST' flag set. This would
trigger the user-agent to store the included name+value pairs just
as it would store the information provided by a Set-Cookie header.
The 'HTTPONLY' and 'SECURE' flags would be used as direct alternatives
for the HttpOnly and Secure Set-Cookie parameters. The serialized
header block would contain ':host' and ':path' fields corresponding
to the Set-Cookie Domain and Path parameters.</t>
<t>The 'Cookie' header would be replace by a user-agent sending
a 'CONTEXT' frame in a stream with the 'PERSISTED' flag set. This
would tell the server that the name+value pairs contained are those
the server had previously asked the user-agent to store.</t>
<t>The critical advantage of using the 'CONTEXT' frame as a replacement
for Set-Cookie and Cookie is encoding efficiency. Experiments have
demonstrated that equivalent values can be encoded with 50-60% fewer
bytes.</t>
</section>
<section title="Using 'CONTEXT' as a replacement for MIME Multipart Packaging">
<t>Many existing HTTP based applications use variations on MIME multipart
packaging to enable sending multiple entities within a request or response.
Examples include HTML forms and multipart Atom posts. In every case,
the use of MIME multipart consists of sending sequences of data octets
separated by blocks of name+value pair headers.</t>
<t>Using 'CONTEXT' frames, we can eliminate the need for Multipart MIME
packaging entirely, addressing precisely the same use cases in a significantly
more efficient way.</t>
<figure><preamble>For example, a simple multipart form data package:</preamble><artwork><![CDATA[
POST /foo HTTP/1.0
Host: example.com
Content-type: multipart/form-data, boundary=abcdefg
Content-Length: ...
--abcdefg
content-disposition: form-data; name="f1"
12345
--abcdefg
content-disposition: form-data; name="f2"
678890
--abcdefg
content-disposition: form-data; name="f3"; filename="foo.jpg"
Content-Type: image/jpeg
Content-Transfer-Encoding: binary
...binary data...
--abcdefg--
]]></artwork></figure>
<figure><preamble>can be represented
by a much more compact sequence of intermixed 'DATA' and 'CONTEXT'
frames:</preamble><artwork>
HEADERS :method = POST
:host = example.com
:content-type = application/context-separated
CONTEXT content-disposition: form-data; name="f1"
DATA 12345
CONTEXT content-disposition: form-data; name="f2"
DATA 67890
CONTEXT content-disposition: form-data; name="f3";
filename="foo.jpg"
content-type: image/jpeg
DATA ...binary data...
</artwork></figure>
<t>Parsing and processing the sequence of frames is less
error prone and more efficient than parsing the Multipart
MIME packaging, and the fact that CONTEXT frames can make
use of the header compression mechanisms means the data
can be transmitted much more efficiently over the network.</t>
</section>
<section title="Considerations for HTTP 2.0 Design">
<t>For the 'CONTEXT' frame, the most significant considerations for
the HTTP 2.0 are Flow Control, Header Compression State and
handling of unknown header types.</t>
<section title="Flow Control">
<t>Currently, HTTP 2.0 states that only DATA frames are covered by
flow control. This means that CONTEXT and any other extension
headers are automatically ruled out of the flow control limits.
This is dangerous because it allows implementations to very easily
work around flow control limits end-to-end by using a new frame
type.</t>
<t>Because 'CONTEXT' frames consist of application-level data rather
than protocol-level data, 'CONTEXT' frames ought to be covered by
flow control mechanisms.</t>
</section>
<section title="Header Compression State">
<t>While the 'CONTEXT' frame can take advantage of the same header
compression mechanism used by HEADERS, HEADERS+PRIORITY and
PUSH_PROMISE frames, the fact that 'CONTEXT' frames express
application-level data and not protocol-level data means that
'CONTEXT' frames ought to have their own compression state
context. This allows intermediaries to pass such frames through
completely untouched, just as it would a DATA frame, without
any negative impact on the connection state.</t>
<t>Alternatively, the working group could rule that extension
frames MUST NOT use header blocks and the header compression
mechanism. Such a decision would place strict limitations on
the types of new frames permitted unless a new protocol version
is established. Such a decision is not out of the question but
raises a number of difficult issues with regards to the
deployment and support of new capabilities.</t>
</section>
<section title="Handling of Unknown Headers Types">
<t>The current HTTP 2.0 draft states that unknown and unsupported
frame types are to be ignored, but does not define exactly what
that means. An intermediary might ignore a frame by dropping it
completely from the stream and never passing it on, or it might
ignore the frame by passing it through untouched to an upstream
destination. Specific rules need to be put in place for handling
unknown frame types so that mechanisms like 'CONTEXT' can be
reliably deployed.</t>
<t>The rules ought to be simple. When detecting an unknown frame
type used in a stream, the endpoint can either:
<list style="symbols">
<t>Pass the unknown frame type untouched to an upstream
destination, just as it would a DATA frame, or</t>
<t>Reject the frame and terminate the stream using an
RST_STREAM with an UNSUPPORTED_FRAME_TYPE error code.</t>
</list>
</t>
<t>When detecting an unknown frame type whose stream ID is 0x0,
the endpoint can choose to ignore it completely or reject
the frame and terminate the connection using a GOAWAY with
an UNSUPPORTED_FRAME_TYPE error code.</t>
<t>If these rules are not followed, the stream state or connection
state can be easily corrupted by out of sync client and server
implementations.</t>
</section>
</section>
</section>
<section title="The 'CHECK' Frame Type">
<t>The 'CHECK' frame would be used to provide incremental verification of
data transmitted within a stream.</t>
<t>The syntax of the 'CHECK' frame consists of a header block containing
parameters of the hash algorithm being used.</t>
<figure title="CHECK Frame Payload Format">
<artwork type="inline">
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Header Block (*) ...
+---------------------------------------------------------------+
</artwork>
</figure>
<t>One frame-specific flag is defined:
<list style="hanging">
<t hangText="INIT (0x2)">
If set, tells the recipient to begin recording and calculating
a hash of the data of all subsequently received frames
for the same stream using the parameters specified in
the included Header Block. Any previously maintained hash
can be discarded.
</t>
</list>
</t>
<t>Once an endpoint receives a 'CHECK' frame with the INIT flag
set, it will initialize a verification context that will
incrementally calculate a hash of all frames subsequently
received on the same stream until a new 'CHECK' frame is
received. The complete frame data, including
the 8-byte header) is to be included in the hash calculation.</t>
<t>The sender would then, at some later point in the stream, send
and additional 'CHECK' frame without the INIT flag set. That
frame MUST include a ':hash' header whose value specifies
what the calculated hash ought to be.</t>
<figure><preamble>For example, to specify an MD5 hash for a set of frames
</preamble><artwork>
HEADERS :method = POST
:host = example.org
:content-type = application/json
CHECK :algorithm = http://.../md5 INIT = ON
DATA ...
DATA ...
DATA ...
CHECK :hash = {expected hash value} INIT = OFF
</artwork></figure>
<t>If the calculated hash does not match that provided by the
secondary CHECK frame, the stream SHOULD be terminated with an
RST_FRAME.</t>
<section title="Considerations for HTTP 2.0 Design">
<t>The considerations for 'CHECK' are similar to those on the
'CONTEXT' frame.</t>
<t>Because 'CHECK' uses a Header block it can
take advantage of the header compression mechanism but ought
not have an impact on the connections compression state. </t>
<t>It is unclear whether a frame such a 'CHECK' ought to be
covered by flow control. It is, essentially, a protocol-level
extension that is not really intended for application-level
use.</t>
<t>So long as the header compression state is isolated, an
implementation could choose to ignore the CHECK frame entirely
without risk of corrupting any connection or stream data.</t>
</section>
</section>
</middle>
<back>
<references title="Normative References">
&rfc2119;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 05:21:58 |