< draft-snell-httpbis-bohe-02.txt   draft-snell-httpbis-bohe-03.txt >
Network Working Group J. Snell Network Working Group J. Snell
Internet-Draft February 14, 2013 Internet-Draft February 18, 2013
Intended status: Informational Intended status: Informational
Expires: August 18, 2013 Expires: August 22, 2013
HTTP/2.0 Discussion: Binary Optimized Header Encoding HTTP/2.0 Discussion: Binary Optimized Header Encoding
draft-snell-httpbis-bohe-02 draft-snell-httpbis-bohe-03
Abstract Abstract
This memo describes a proposed alternative encoding for headers This memo describes a proposed alternative encoding for headers
within SPDY SYN_STREAM, SYN_REPLY and HEADERS frames. within SPDY SYN_STREAM, SYN_REPLY and HEADERS frames.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
skipping to change at page 1, line 31 skipping to change at page 1, line 31
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 18, 2013. This Internet-Draft will expire on August 22, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Binary Optimized Header Encoding . . . . . . . . . . . . . . . 3 1. Binary Optimized Header Encoding . . . . . . . . . . . . . . . 3
1.1. Example Headers . . . . . . . . . . . . . . . . . . . . . . 4 2. Value Encoding . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 3. Example Headers . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Normative References . . . . . . . . . . . . . . . . . . . . . 7 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 5. Normative References . . . . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8
1. Binary Optimized Header Encoding 1. Binary Optimized Header Encoding
Binary Optimized Header Encoding is a proposed alternative Binary Optimized Header Encoding is a proposed alternative
serialization for headers within SPDY SYN_STREAM, SYN_REPLY and serialization for headers within SPDY SYN_STREAM, SYN_REPLY and
HEADERS frames that is designed to optimize generation, consumption HEADERS frames that is designed to optimize generation, consumption
and processing of the most commonly used HTTP headers. and processing of the most commonly used HTTP headers.
Alternate Header Block Serialization: Alternate Header Block Serialization:
skipping to change at page 3, line 30 skipping to change at page 3, line 30
'Headers' consists of the complete set of encoded headers. The 'Headers' consists of the complete set of encoded headers. The
format for each header is determined by whether the header name (the format for each header is determined by whether the header name (the
key) and the header value are included in the static "default key) and the header value are included in the static "default
dictionary" defined by this specification. The first two bits of dictionary" defined by this specification. The first two bits of
each encoded header record identify the specific header format used. each encoded header record identify the specific header format used.
Registered Key + Registered Value Pair Registered Key + Registered Value Pair
+--+---+--+ +--+---+--+
|00|FLG|ID| |00|CNT|ID|
+--+---+--+ +--+---+--+
If the header name and value are both included in the default If the header name and value are both included in the default
dictionary, the header is encoded using only three distinct fields: dictionary, the associated index of the header as provided by the
the two-bit opcode (00) followed by six unused flag bits, followed by dictionary is encoded as a variable-length, unsigned integer in lists
the index of the header key+value pair as provided by the default of no more than 63 items. For example, the headers ":path=/",
dictionary, encoded as a variable-length, unsigned integer. ":method=GET" and ":scheme=https" would be compactly encoded as: 03
03 0F 06
Registered Key + Unregistered Value Registered Key + Unregistered Value
+--+---+--+---+---+ +--+---+--+---+---+
|01|FLG|ID|LEN|VAL| |01|FLG|ID|LEN|VAL|
+--+---+--+---+---+ +--+---+--+---+---+
If the header name is included in the default dictionary, but the If the header name is included in the default dictionary, but the
value given is not, the header is encoded using five fields: the two- value given is not, the header is encoded using five fields: the two-
bit opcode (01) followed by six flag bits as defined below, followed bit opcode (01) followed by six flag bits as defined below, followed
skipping to change at page 4, line 23 skipping to change at page 4, line 23
bit opcode (10) followed by six flag bits as defined below, followed bit opcode (10) followed by six flag bits as defined below, followed
by a variable-length, unsigned integer specifying the key length, by a variable-length, unsigned integer specifying the key length,
followed by the ISO-8859-1 encoded key name, followed by a variable- followed by the ISO-8859-1 encoded key name, followed by a variable-
length, unsigned integer specifying the value length, followed by the length, unsigned integer specifying the value length, followed by the
encoded value. encoded value.
Flags: Flags:
FLG = 000000 FLG = 000000
|||||| ||||||
||||Reserved |||||Reserved
||||Date (Numeric val represents a date)
|||Numeric (val is one or more uvarints) |||Numeric (val is one or more uvarints)
||Huffman-encoded ||Huffman-encoded
|UTF-8 or ISO8859-1 (1 or 0) |UTF-8 or ISO8859-1 (1 or 0)
Binary | Text (1 or 0) Binary | Text (1 or 0)
When the opcode is either 01 or 10, the six-bit FLG field is used to When the opcode is either 01 or 10, the six-bit FLG field is used to
specify additional properties about the header value. When the specify additional properties about the header value. When the
opcode is 00, the FLG bits are unused and MUST NOT be set. opcode is 00, the FLG bits are unused and MUST NOT be set.
Moving from the most significant bit to the least, the flags are: Moving from the most significant bit to the least, the flags are:
o Binary or Text (0x32) - When set, the value is to be interpreted o Binary or Text (0x32) - When set, the value is to be interpreted
as binary data. When unset, the value is to be interpreted as as binary data. When unset, the value is to be interpreted as
encoded-text. encoded-text.
o UTF-8 or ISO-8859-1 (0x16) - When set, indicates that the text- o UTF-8 or ISO-8859-1 (0x16) - When set, indicates that the text-
encoded value is UTF-8 encoded. Otherwise, ISO-8859-1 is assumed. encoded value is UTF-8 encoded. Otherwise, ISO-8859-1 is assumed.
Only used if the Binary or Text bit is unset. Only used if the Binary bit (0x32) is unset.
o Huffman-encoded (0x08) - When set, indicates that the text-encoded o Huffman-encoded (0x08) - When set, indicates that the text-encoded
value has been static huffman encoded. The static dictionary used value has been static huffman encoded. The static dictionary used
for the encoding is dependent on whether the text is UTF-8 or ISO- for the encoding is dependent on whether the text is UTF-8 or ISO-
8859-1 encoded. Only used if the Binary or Text bit is unset. 8859-1 encoded. Only used if the Binary bit (0x32) is unset.
o Numeric (0x04) - When set, indicates that the value is encoded as o Numeric (0x04) - When set, indicates that the value is encoded as
a variable-length unsigned integer. Only used if the Binary or a variable-length unsigned integer. Only used if the Binary bit
Text bit is set (indicating a binary value). (0x32) is set (indicating a binary value).
o The final two bits (0x02 and 0x01) are reserved. o Date (0x02) - When set, indicates that the value is a date and
time encoded as a variable-length unsigned integer representing
the total number of seconds that have ellapsed since midnight on
January 1st, 1990, GMT. Only used if the Binary (0x32) and
Numeric (0x04) bits are both set.
1.1. Example Headers o The final bit (0x01) is reserved.
2. Value Encoding
Header values can be encoded as one of four distinct types: Binary,
Text, Numeric or Date. Each is indicated by the FLG field.
o Binary Header values are encoded as a raw, uninterpreted sequence
of binary octets.
o Numeric values are encoded as variable-length, unsigned integers.
o Date values are encoded as variable-length, unsigned integers
representing the total number of seconds that have ellapsed since
midnight on January 1st, 1990.
o Text values are encoded as a sequence one or more length-prefixed
octet sequences representing ISO-8859-1 or UTF-8 encoded
characters, conforming to the following structure:
string_val = COUNT 1*(LENGTH VAL)
Where COUNT is an unsigned 8-bit value specifying the number of octet
sequences, LENGTH is an unsigned variable-length integer specifying
the length of each sequence, and VAL is the specific sequence of
encoded octets.
3. Example Headers
Assuming the following (incomplete) default dictionary: Assuming the following (incomplete) default dictionary:
+----+-----------------------------+------------+ +----+-----------------------------+------------+
| ID | Key | Value | | ID | Key | Value |
+----+-----------------------------+------------+ +----+-----------------------------+------------+
| 0 | date | | | 0 | date | |
| 1 | :scheme | | | 1 | :scheme | |
| 2 | :scheme | http | | 2 | :scheme | http |
| 3 | :scheme | https | | 3 | :scheme | https |
skipping to change at page 6, line 50 skipping to change at page 7, line 32
| 81 | x-content-type-options | | | 81 | x-content-type-options | |
| 82 | x-frame-options | | | 82 | x-frame-options | |
| 83 | x-powered-by | | | 83 | x-powered-by | |
| 84 | x-xss-protection | | | 84 | x-xss-protection | |
| 85 | connection | | | 85 | connection | |
| 86 | connection | keep-alive | | 86 | connection | keep-alive |
+----+-----------------------------+------------+ +----+-----------------------------+------------+
The header :version=2.0 would be encoded as: The header :version=2.0 would be encoded as:
00 1D |..| 01 1D |..|
The header :method=GET would be encoded as: The header :method=GET would be encoded as:
00 06 |..| 01 06 |..|
The headers :version=2.0 and :method=GET would be encoded as:
02 06 1D |..|
The header :method=foo would be encoded as: The header :method=foo would be encoded as:
01 76 05 05 00 03 66 6F |......fo| 56 05 05 01 03 66 6F 6F |.....foo|
6F |o|
The header foo=bar would be encoded as: The header foo=bar would be encoded as:
b6 03 66 6f 6f 05 00 |..foo...| b6 03 66 6f 6f 05 01 |..foo...|
03 62 61 72 |.bar| 03 62 61 72 |.bar|
2. Security Considerations 4. Security Considerations
TBD TBD
3. Normative References 5. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
Author's Address Author's Address
James M Snell James M Snell
Email: jasnell@gmail.com Email: jasnell@gmail.com
 End of changes. 18 change blocks. 
27 lines changed or deleted 61 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/