Network Working Group J. Snell
Internet-Draft October 3, 2012
Intended status: Informational
Expires: April 6, 2013
HTTP/2.0 Discussion: Binary Optimized Header Encoding
draft-snell-httpbis-bohe-01
Abstract
This memo describes a proposed alternative encoding for headers
within SPDY SYN_STREAM, SYN_REPLY and HEADERS frames.
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 April 6, 2013.
Copyright Notice
Copyright (c) 2012 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. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Snell Expires April 6, 2013 [Page 1]
Internet-Draft application/merge-patch October 2012
Table of Contents
1. Binary Optimized Header Encoding . . . . . . . . . . . . . . . 3
1.1. Registered Headers . . . . . . . . . . . . . . . . . . . . 3
1.2. Extension Headers . . . . . . . . . . . . . . . . . . . . 4
1.3. Binary vs. Character Values . . . . . . . . . . . . . . . 5
1.4. Example Headers . . . . . . . . . . . . . . . . . . . . . 7
2. Security Considerations . . . . . . . . . . . . . . . . . . . 8
3. Normative References . . . . . . . . . . . . . . . . . . . . . 9
Appendix A. Additional Examples . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12
Snell Expires April 6, 2013 [Page 2]
Internet-Draft application/merge-patch October 2012
1. Binary Optimized Header Encoding
Binary Optimized Header Encoding is a proposed alternative
serialization for headers within SPDY SYN_STREAM, SYN_REPLY and
HEADERS frames that is designed to optimize generation, consumption
and processing of the most commonly used HTTP headers.
Alternate Header Block Serialization:
+------------------------------------+
| Number of Headers (8bit) |
+------------------------------------+
|T| Header |
+------------------------------------+
| ... |
Within the existing SPDY Header Block, a 32-bit value is used to
identify the number of headers within the block. For all practical
purposes, it is exceedingly unlikely that a single block of headers
will contain anywhere near 4,294,967,295 distinct headers. Obviously
a 32-bit integer is significant overkill for this purpose. As an
alternative, an 8-bit value is suggested.
The header block consists of zero or more distinct headers, each of
which begin with a single Type-bit whose value indicates the type of
header. There are two header types: Registered and Extension. The
specific structure of the header depends on the type.
The header block MAY be compressed as described within
[draft-montenegro-httpbis-speed-mobility-02].
1.1. Registered Headers
Registered Headers are well-known and well-defined header fields for
which there is a published RFC and IANA registration. Each is
assigned an unsigned 15-bit integer identifier.
The structure of Registered Headers:
+------------------------------+
|0| id (15-bit) |
+------------------------------+
|E|M| len (22-bit) |
+------------------------------+
| value... |
+------------------------------+
The first single bit within the structure is the Type-bit. When this
Snell Expires April 6, 2013 [Page 3]
Internet-Draft application/merge-patch October 2012
bit is off, the header is a Registered Header.
The next fifteen bits specify the header's specific numeric
identifier as assigned within the IANA registry.
The next bit (E) indicates, when set, that the header field value
contains UTF-8 encoded character content. If the bit is not set, the
value is assumed to contain non-character-based binary data.
Following the identifier are 2 reserved bits:
o The first (E) indicates that the header value contains UTF-8
encoded character content. If the bit is not set, the value is
assumed to contain non-character-based binary data.
o The second (M) indicates that the value includes multiple NUL (0)
separated values. When set, processors MUST treat NUL (0) octets
within the value as a delimiter and not as part of the value
itself.
The remaining content of the structure consists of a 22-bit unsigned
integer specifying the remaining length of the header value. The
value MAY be zero length.
The minimum length of a registered header is 5-octets (40-bits).
When bit M is set, the header may contain multiple values separated
by a single NUL (0) byte. Each distinct value MUST NOT be zero-
length. When bits E and M are bot not set, NUL bytes contained
within the value are to be considered part of the value. The use of
NUL bytes within character-based values is not permitted except when
used as a delimiter separating multiple values.
When multiple values are included, the value length field MUST
specify the total length, in octets, of all values plus the number of
NUL (0) byte separators. For example, for a header value consisting
of the two strings "foo" and "bar", the total value length would be
7.
1.2. Extension Headers
Extension Headers are simple name+value pairs essentially as they
exist today, but with a number of important modifications.
Snell Expires April 6, 2013 [Page 4]
Internet-Draft application/merge-patch October 2012
The structure of Extension Headers
+------------------------------+
|1| namelen (7) | name |
+------------------------------+
|E|M| val len (22) | value |
+------------------------------+
The first single bit is the Type-bit. When this bit is on, the
header is an Extension Header.
The next 7-bits specify the length in octets of the ASCII-encoded
header name as unsigned integer, followed by the name itself. The
name MUST conform to the field-name construction as defined in
[draft-ietf-httpbis-p1-messaging-2].
Following the identifier are 2 reserved bits:
o The first (E) indicates that the header value contains UTF-8
encoded character content. If the bit is not set, the value is
assumed to contain non-character-based binary data.
o The second (M) indicates that the header specifies multiple NUL
(0) separated values. When set, processors MUST treat NUL (0)
octets within the value as a value-separator and not as part of
the value itself.
The length of the remaining value is specified as an unsigned 22-bit
integer, followed by the value itself. Zero length values are
permitted.
When bit M is set, the header may contain multiple values separated
by a single NUL (0) byte. Each distinct value MUST NOT be zero-
length. When bits E and M are bot not set, NUL bytes contained
within the value are to be considered part of the value. The use of
NUL bytes within character-based values is not permitted except when
used as a delimiter separating multiple values.
When multiple values are included, the value length field MUST
specify the total length, in octets, of all values plus the number of
NUL (0) byte separators. For example, for a header value consisting
of the two strings "foo" and "bar", the total value length would be
7.
1.3. Binary vs. Character Values
Specific header values can be encoded as either a stream of binary
octets or as UTF-8 encoded character data.
For example, within the existing SPDY specification, the HTTP Version
Snell Expires April 6, 2013 [Page 5]
Internet-Draft application/merge-patch October 2012
is represented as a header using the field-name ":version" with the
version number represented as an ASCII string, consuming 19-bytes in
all.
Version Header using the existing SPDY encoding:
00 00 00 08 3a 76 65 72 |....:ver|
73 69 6f 6e 00 00 00 03 |sion....|
31 2e 31 |2.0|
Using the Binary Optimized Header Encoding, this can be reduced to a
compact 7 or 8 bytes using either binary or character data:
Version Header using Character Data:
00 01 80 00 03 31 2e 31 |.....2.0|
Version Header using Binary Data:
00 01 00 00 02 02 00 |.......|
Likewise, SPDY uses a ":method" header to specify the HTTP Method
used for a particular request, with the value represented as an ASCII
string, consuming 18 bytes for GET requests.
Method Header using the existing SPDY encoding:
00 00 00 07 3a 6d 65 74 |....:met|
68 6f 64 00 00 00 03 47 |hod....G|
45 54 |GET|
Using optimized encoding, this can be reduced to a compact 6 or 8
bytes using either binary or character data:
Method Header using Character Data:
00 02 80 00 03 47 45 54 |.....GET|
Method Header using Binary Data, assuming the value 0x1 is defined to
represent the GET method:
00 02 00 00 01 01 |......|
There are many headers used within HTTP applications for which binary
encodings would be difficult or unnecessary. For those, utilizing
the character encoding option would be appropriate. With some work
it should be possible to define optimized binary encodings for many
of the existing complex headers.
Snell Expires April 6, 2013 [Page 6]
Internet-Draft application/merge-patch October 2012
1.4. Example Headers
Assume the following registered headers:
+--------------------+----+
| HTTP Header | ID |
+--------------------+----+
| Version | 1 |
| Method | 2 |
| Host | 3 |
| Path (Request URI) | 4 |
| Accept-Language | 5 |
+--------------------+----+
And the following values representing known HTTP Methods:
+---------+-------+
| Method | Value |
+---------+-------+
| GET | 1 |
| POST | 2 |
| PUT | 3 |
| DELETE | 4 |
| PATCH | 5 |
| HEAD | 6 |
| OPTIONS | 7 |
| CONNECT | 8 |
+---------+-------+
The Version header can be encoded as (7-bytes):
00 01 00 00 02 02 00 |.......|
The GET Method header can be encoded as (6-bytes):
00 02 00 00 01 01 |......|
The Host Header can be encoded as (20-bytes):
00 03 80 00 0f 77 77 77 |.....www|
2e 65 78 61 6d 70 6c 65 |.example|
2e 6f 72 67 |.org|
A simple Accept-Lang header would be encoded as (10-bytes):
00 05 80 00 05 65 6e 2d |.....en-|
55 53 |US|
Snell Expires April 6, 2013 [Page 7]
Internet-Draft application/merge-patch October 2012
A Path header encoding the request URI (45-bytes):
00 04 80 00 28 2f 74 68 |...../th|
69 73 2f 69 73 2f 74 68 |is/is/th|
65 2f 72 65 71 75 65 73 |e/reques|
74 3f 69 73 3d 69 74 26 |t?is=it&|
6e 6f 74 3d 62 65 61 75 |not=beau|
74 69 66 75 6c |tiful|
The combined serialization of the five headers into a single block
requires a total of 89 bytes. By comparison, the equivalent
serialization using the existing SPDY encoding requires 150 bytes
sans compression (28 bytes of which are wasted by the unnecessary use
of int32).
The equivalent SPDY encoding:
00 00 00 05 00 00 00 08 |........|
3a 76 65 72 73 69 6f 6e |:version|
00 00 00 03 31 2e 31 00 |....1.1.|
00 00 07 3a 6d 65 74 68 |...:meth|
6f 64 00 00 00 03 47 45 |od....GE|
54 00 00 00 05 3a 68 6f |T....:ho|
73 74 00 00 00 0f 77 77 |st....ww|
77 2e 65 78 61 6d 70 6c |w.exampl|
65 2e 6f 72 67 00 00 00 |e.org...|
0f 41 63 63 65 70 74 2d |.Accept-|
4c 61 6e 67 75 61 67 65 |Language|
00 00 00 05 65 6e 2d 55 |....en-U|
53 00 00 00 05 3a 70 61 |S....:pa|
74 68 00 00 00 28 2f 74 |th..../t|
68 69 73 2f 69 73 2f 74 |his/is/t|
68 65 2f 72 65 71 75 65 |he/reque|
73 74 3f 69 73 3d 69 74 |st?is=it|
26 6e 6f 74 3d 62 65 61 |¬=bea|
75 74 69 66 75 6c |utiful|
Note that the equivalent information encoded within an HTTP/1.1
request message requires 102 bytes.
2. Security Considerations
TBD
Snell Expires April 6, 2013 [Page 8]
Internet-Draft application/merge-patch October 2012
3. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Appendix A. Additional Examples
Assuming the following (intentionally incomplete) header
registrations adapted from the existing http-bis specifications.
+---------------------+----+
| HTTP Header | ID |
+---------------------+----+
| Version | 1 |
| Method | 2 |
| Host | 3 |
| Path (Request URI) | 4 |
| Status | 5 |
| Status-Text | 6 |
| Content-Length | 7 |
| Content-Type | 8 |
| Content-Encoding | 9 |
| Expect | 10 |
| Location | 11 |
| Last-Modified | 12 |
| ETag | 13 |
| If-Match | 14 |
| If-None-Match | 15 |
| If-Modified-Since | 16 |
| If-Unmodified-Since | 17 |
| Age | 18 |
| Cache-Control | 19 |
| Expires | 20 |
| Vary | 21 |
| Accept | 22 |
| Accept-Language | 23 |
| Accept-Charset | 24 |
| Accept-Encoding | 25 |
| Allow | 26 |
| Content-Language | 27 |
| Content-Location | 28 |
| Date | 29 |
| From | 30 |
| Warning | 31 |
+---------------------+----+
And the following values representing known HTTP Methods:
Snell Expires April 6, 2013 [Page 9]
Internet-Draft application/merge-patch October 2012
+---------+-------+
| Method | Value |
+---------+-------+
| GET | 1 |
| POST | 2 |
| PUT | 3 |
| DELETE | 4 |
| PATCH | 5 |
| HEAD | 6 |
| OPTIONS | 7 |
| CONNECT | 8 |
+---------+-------+
We can derive the following optimized encodings:
Version Header:
00 01 00 00 02 02 00 |.......|
Method Header (GET Request)
00 02 00 00 01 01 |......|
Method Header (PATCH Request)
00 02 00 00 01 05 |......|
Method Header (Custom "FOO" Method)
00 02 80 00 03 46 4F 4F |.....FOO|
Host Header:
00 03 80 00 0f 77 77 77 |.....www|
2e 65 78 61 6d 70 6c 65 |.example|
2e 6f 72 67 |.org|
Representation of HTTP Response Status ("200 OK") as two separate
headers, one containing the status code, the other containing the
status text:
00 05 00 00 01 C8 00 06 |........|
80 00 02 4F 4B |...OK|
Snell Expires April 6, 2013 [Page 10]
Internet-Draft application/merge-patch October 2012
An alternative would be represent the status as a single header
containing multiple values:
00 05 C0 00 04 C8 00 4F |.......O|
4B |K|
Content-Length Header (value encoded as uint32):
00 07 00 00 04 00 00 00 |........|
C8 |.|
Content-Type Header:
00 08 80 00 0A 69 6d 61 |.....ima|
67 65 2f 6a 70 65 67 |ge/jpeg|
Expect Header (Expect: 100):
00 0A 00 00 01 64 |......|
Last-Modified (Using RFC3339 Format):
00 0C 80 00 19 32 30 31 |.....201|
32 2d 30 38 2d 30 31 54 |2-08-01T|
30 34 3a 32 33 3a 31 32 |04:23:12|
2e 31 32 33 34 5a |.1234Z|
ETag (Strong Entity-Tag, String-format):
00 0D 80 00 07 22 61 62 |....."ab|
63 64 65 22 |cde"|
If-None-Match:
00 0F 80 00 07 22 61 62 |....."ab|
63 64 65 22 |cde"|
If-None-Match (Multiple values)
00 0F C0 00 0F 22 61 62 |....."ab|
63 64 65 22 00 22 61 62 |cde"."ab|
63 64 66 22 |cdf"|
Allow (GET, POST, FOO):
00 1A C0 00 07 01 00 02 |........|
00 46 4f 4f |.FOO|
Snell Expires April 6, 2013 [Page 11]
Internet-Draft application/merge-patch October 2012
Author's Address
James M Snell
Email: jasnell@gmail.com
Snell Expires April 6, 2013 [Page 12]