Network Working Group J.M. Snell
Internet-Draft May 20, 2013
Intended status: Informational
Expires: November 21, 2013
HTTP/2.0 Discussion: Extension Frame Types
draft-snell-httpbis-ext-frames-00
Abstract
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.
Status of This Memo
This Internet-Draft is submitted to IETF 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 21, 2013.
Copyright Notice
Copyright (c) 2013 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.
Table of Contents
Snell Expires November 21, 2013 [Page 1]
Internet-Draft Extension Frame Types for HTTP 2.0 May 2013
1. The 'CONTEXT' Frame Type . . . . . . . . . . . . . . . . . . 2
1.1. Using 'CONTEXT' as a 'Set-Cookie' and 'Cookie'
Replacement . . . . . . . . . . . . . . . . . . . . . . . 2
1.2. Using 'CONTEXT' as a replacement for MIME Multipart
Packaging . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Considerations for HTTP 2.0 Design . . . . . . . . . . . 4
1.3.1. Flow Control . . . . . . . . . . . . . . . . . . . . 5
1.3.2. Header Compression State . . . . . . . . . . . . . . 5
1.3.3. Handling of Unknown Headers Types . . . . . . . . . . 5
2. The 'CHECK' Frame Type . . . . . . . . . . . . . . . . . . . 6
2.1. Considerations for HTTP 2.0 Design . . . . . . . . . . . 7
3. Normative References . . . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7
1. The 'CONTEXT' Frame Type
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.
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.
The syntax of the 'CONTEXT' frame is identical to that of the
'HEADERS' frame but defines the following additional type specific
flags:
PERSIST (0x04) Store the context
CLEAR (0x08) Clear existing stored context
PERSISTED (0x10) From stored context
HTTPONLY (0x20) Equivalent to Set-Cookie HttpOnly parameter
SECURE (0x40) Equivalent to Set-Cookie Secure parameter
1.1. Using 'CONTEXT' as a 'Set-Cookie' and 'Cookie' Replacement
Snell Expires November 21, 2013 [Page 2]
Internet-Draft Extension Frame Types for HTTP 2.0 May 2013
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.
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.
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.
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.
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.
1.2. Using 'CONTEXT' as a replacement for MIME Multipart Packaging
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.
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.
For example, a simple multipart form data package:
Snell Expires November 21, 2013 [Page 3]
Internet-Draft Extension Frame Types for HTTP 2.0 May 2013
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--
can be represented by a much more compact sequence of intermixed
'DATA' and 'CONTEXT' frames:
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...
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.
1.3. Considerations for HTTP 2.0 Design
Snell Expires November 21, 2013 [Page 4]
Internet-Draft Extension Frame Types for HTTP 2.0 May 2013
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.
1.3.1. Flow Control
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.
Because 'CONTEXT' frames consist of application-level data rather
than protocol-level data, 'CONTEXT' frames ought to be covered by
flow control mechanisms.
1.3.2. Header Compression State
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.
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.
1.3.3. Handling of Unknown Headers Types
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.
The rules ought to be simple. When detecting an unknown frame type
used in a stream, the endpoint can either:
Snell Expires November 21, 2013 [Page 5]
Internet-Draft Extension Frame Types for HTTP 2.0 May 2013
o Pass the unknown frame type untouched to an upstream destination,
just as it would a DATA frame, or
o Reject the frame and terminate the stream using an RST_STREAM with
an UNSUPPORTED_FRAME_TYPE error code.
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.
If these rules are not followed, the stream state or connection state
can be easily corrupted by out of sync client and server
implementations.
2. The 'CHECK' Frame Type
The 'CHECK' frame would be used to provide incremental verification
of data transmitted within a stream.
The syntax of the 'CHECK' frame consists of a header block containing
parameters of the hash algorithm being used.
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 (*) ...
+---------------------------------------------------------------+
CHECK Frame Payload Format
One frame-specific flag is defined:
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.
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.
Snell Expires November 21, 2013 [Page 6]
Internet-Draft Extension Frame Types for HTTP 2.0 May 2013
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.
For example, to specify an MD5 hash for a set of frames
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
If the calculated hash does not match that provided by the secondary
CHECK frame, the stream SHOULD be terminated with an RST_FRAME.
2.1. Considerations for HTTP 2.0 Design
The considerations for 'CHECK' are similar to those on the 'CONTEXT'
frame.
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.
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.
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.
3. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Author's Address
James M Snell
Email: jasnell@gmail.com
Snell Expires November 21, 2013 [Page 7]