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]