Network Working Group J.M. Snell
Internet-Draft February 2013
Intended status: Informational
Expires: August 05, 2013

HTTP/2.0 Discussion: Binary Optimized Header Encoding
draft-snell-httpbis-bohe-03

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 August 05, 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

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:

 +-------+---------+
 |  NUM  | Headers |
 +-------+---------+

'NUM' is a single unsigned 8-bit value indicating the total number of distinct headers contained in the encoded block.

'Headers' consists of the complete set of encoded headers. The format for each header is determined by whether the header name (the key) and the header value are included in the static "default dictionary" defined by this specification. The first two bits of each encoded header record identify the specific header format used.

Registered Key + Registered Value Pair

  +--+---+--+
  |00|CNT|ID| 
  +--+---+--+

If the header name and value are both included in the default dictionary, the associated index of the header as provided by the dictionary is encoded as a variable-length, unsigned integer in lists of no more than 63 items. For example, the headers ":path=/", ":method=GET" and ":scheme=https" would be compactly encoded as: 03 03 0F 06

Registered Key + Unregistered Value

  +--+---+--+---+---+
  |01|FLG|ID|LEN|VAL|
  +--+---+--+---+---+

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-bit opcode (01) followed by six flag bits as defined below, followed by the numerically lowest index of the named header as provided by the default dictionary encoded as a variable-length, unsigned integer, followed by another variable-length, unsigned integer specifying the length of the value, followed by the encoded value.

Unregistered Key + Value Pair

  +--+---+------+---+------+---+
  |10|FLG|LENkey|key|LENval|val|
  +--+---+------+---+------+---+

If the header name and value are not included in the default dictionary, the header is encoded using six distinct fields: the two-bit opcode (10) followed by six flag bits as defined below, followed by a variable-length, unsigned integer specifying the key length, followed by the ISO-8859-1 encoded key name, followed by a variable-length, unsigned integer specifying the value length, followed by the encoded value.

Flags:

  FLG = 000000
        ||||||
        |||||Reserved
        ||||Date (Numeric val represents a date)
        |||Numeric (val is one or more uvarints)
        ||Huffman-encoded
        |UTF-8 or ISO8859-1 (1 or 0)
        Binary | Text (1 or 0)

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 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:

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.

  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:

ID Key Value
0 date
1 :scheme
2 :scheme http
3 :scheme https
4 :scheme ftp
5 :method
6 :method get
7 :method post
8 :method put
9 :method delete
10 :method options
11 :method connect
12 :method patch
13 :method link
14 :path
15 :path /
16 :host
17 cookie
18 :status
19 :status 200
20 :status 201
21 :status 202
22 :status 204
23 :status 205
24 :status-text
25 :status-text OK
26 :version
27 :version 1.0
28 :version 1.1
29 :version 2.0
30 accept
31 accept-charset
32 accept-encoding
33 accept-language
34 accept-ranges
35 allow
36 authorizations
37 cache-control
38 content-base
39 content-encoding
40 content-length
41 content-location
42 content-md5
43 content-range
44 content-type
45 etag
46 expect
47 expires
48 from
49 if-match
50 if-modified-since
51 if-none-match
52 if-range
53 if-unmodified-since
54 last-modified
55 location
56 max-forwards
57 origin
58 pragma
59 proxy-authenticate
60 proxy-authorization
61 range
62 referer
63 retry-after
64 server
65 set-cookie
66 status
67 te
68 trailer
69 transfer-encoding
70 transfer-encoding gzip
71 upgrade
72 user-agent
73 vary
74 via
75 warning
76 www-authenticate
77 access-control-allow-origin
78 content-disposition
79 get-dictionary
80 p3p
81 x-content-type-options
82 x-frame-options
83 x-powered-by
84 x-xss-protection
85 connection
86 connection keep-alive

The header :version=2.0 would be encoded as:

  01 1D |..|

The header :method=GET would be encoded as:

  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:

  56 05 05 01 03 66 6F 6F |.....foo|

The header foo=bar would be encoded as:

  b6 03 66 6f 6f 05 01    |..foo...|
  03 62 61 72             |.bar|

4. Security Considerations

TBD

5. 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