idnits 2.17.1 draft-snell-httpbis-bohe-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (February 18, 2013) is 4085 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 301, but no explicit reference was found in the text Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Snell 3 Internet-Draft February 18, 2013 4 Intended status: Informational 5 Expires: August 22, 2013 7 HTTP/2.0 Discussion: Binary Optimized Header Encoding 8 draft-snell-httpbis-bohe-03 10 Abstract 12 This memo describes a proposed alternative encoding for headers 13 within SPDY SYN_STREAM, SYN_REPLY and HEADERS frames. 15 Status of this Memo 17 This Internet-Draft is submitted to IETF in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at http://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on August 22, 2013. 32 Copyright Notice 34 Copyright (c) 2013 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (http://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 Table of Contents 49 1. Binary Optimized Header Encoding . . . . . . . . . . . . . . . 3 50 2. Value Encoding . . . . . . . . . . . . . . . . . . . . . . . . 5 51 3. Example Headers . . . . . . . . . . . . . . . . . . . . . . . . 5 52 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 53 5. Normative References . . . . . . . . . . . . . . . . . . . . . 8 54 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 56 1. Binary Optimized Header Encoding 58 Binary Optimized Header Encoding is a proposed alternative 59 serialization for headers within SPDY SYN_STREAM, SYN_REPLY and 60 HEADERS frames that is designed to optimize generation, consumption 61 and processing of the most commonly used HTTP headers. 63 Alternate Header Block Serialization: 65 +-------+---------+ 66 | NUM | Headers | 67 +-------+---------+ 69 'NUM' is a single unsigned 8-bit value indicating the total number of 70 distinct headers contained in the encoded block. 72 'Headers' consists of the complete set of encoded headers. The 73 format for each header is determined by whether the header name (the 74 key) and the header value are included in the static "default 75 dictionary" defined by this specification. The first two bits of 76 each encoded header record identify the specific header format used. 78 Registered Key + Registered Value Pair 80 +--+---+--+ 81 |00|CNT|ID| 82 +--+---+--+ 84 If the header name and value are both included in the default 85 dictionary, the associated index of the header as provided by the 86 dictionary is encoded as a variable-length, unsigned integer in lists 87 of no more than 63 items. For example, the headers ":path=/", 88 ":method=GET" and ":scheme=https" would be compactly encoded as: 03 89 03 0F 06 91 Registered Key + Unregistered Value 93 +--+---+--+---+---+ 94 |01|FLG|ID|LEN|VAL| 95 +--+---+--+---+---+ 97 If the header name is included in the default dictionary, but the 98 value given is not, the header is encoded using five fields: the two- 99 bit opcode (01) followed by six flag bits as defined below, followed 100 by the numerically lowest index of the named header as provided by 101 the default dictionary encoded as a variable-length, unsigned 102 integer, followed by another variable-length, unsigned integer 103 specifying the length of the value, followed by the encoded value. 105 Unregistered Key + Value Pair 107 +--+---+------+---+------+---+ 108 |10|FLG|LENkey|key|LENval|val| 109 +--+---+------+---+------+---+ 111 If the header name and value are not included in the default 112 dictionary, the header is encoded using six distinct fields: the two- 113 bit opcode (10) followed by six flag bits as defined below, followed 114 by a variable-length, unsigned integer specifying the key length, 115 followed by the ISO-8859-1 encoded key name, followed by a variable- 116 length, unsigned integer specifying the value length, followed by the 117 encoded value. 119 Flags: 121 FLG = 000000 122 |||||| 123 |||||Reserved 124 ||||Date (Numeric val represents a date) 125 |||Numeric (val is one or more uvarints) 126 ||Huffman-encoded 127 |UTF-8 or ISO8859-1 (1 or 0) 128 Binary | Text (1 or 0) 130 When the opcode is either 01 or 10, the six-bit FLG field is used to 131 specify additional properties about the header value. When the 132 opcode is 00, the FLG bits are unused and MUST NOT be set. 134 Moving from the most significant bit to the least, the flags are: 135 o Binary or Text (0x32) - When set, the value is to be interpreted 136 as binary data. When unset, the value is to be interpreted as 137 encoded-text. 138 o UTF-8 or ISO-8859-1 (0x16) - When set, indicates that the text- 139 encoded value is UTF-8 encoded. Otherwise, ISO-8859-1 is assumed. 140 Only used if the Binary bit (0x32) is unset. 141 o Huffman-encoded (0x08) - When set, indicates that the text-encoded 142 value has been static huffman encoded. The static dictionary used 143 for the encoding is dependent on whether the text is UTF-8 or ISO- 144 8859-1 encoded. Only used if the Binary bit (0x32) is unset. 145 o Numeric (0x04) - When set, indicates that the value is encoded as 146 a variable-length unsigned integer. Only used if the Binary bit 147 (0x32) is set (indicating a binary value). 148 o Date (0x02) - When set, indicates that the value is a date and 149 time encoded as a variable-length unsigned integer representing 150 the total number of seconds that have ellapsed since midnight on 151 January 1st, 1990, GMT. Only used if the Binary (0x32) and 152 Numeric (0x04) bits are both set. 154 o The final bit (0x01) is reserved. 156 2. Value Encoding 158 Header values can be encoded as one of four distinct types: Binary, 159 Text, Numeric or Date. Each is indicated by the FLG field. 161 o Binary Header values are encoded as a raw, uninterpreted sequence 162 of binary octets. 163 o Numeric values are encoded as variable-length, unsigned integers. 164 o Date values are encoded as variable-length, unsigned integers 165 representing the total number of seconds that have ellapsed since 166 midnight on January 1st, 1990. 167 o Text values are encoded as a sequence one or more length-prefixed 168 octet sequences representing ISO-8859-1 or UTF-8 encoded 169 characters, conforming to the following structure: 171 string_val = COUNT 1*(LENGTH VAL) 173 Where COUNT is an unsigned 8-bit value specifying the number of octet 174 sequences, LENGTH is an unsigned variable-length integer specifying 175 the length of each sequence, and VAL is the specific sequence of 176 encoded octets. 178 3. Example Headers 180 Assuming the following (incomplete) default dictionary: 182 +----+-----------------------------+------------+ 183 | ID | Key | Value | 184 +----+-----------------------------+------------+ 185 | 0 | date | | 186 | 1 | :scheme | | 187 | 2 | :scheme | http | 188 | 3 | :scheme | https | 189 | 4 | :scheme | ftp | 190 | 5 | :method | | 191 | 6 | :method | get | 192 | 7 | :method | post | 193 | 8 | :method | put | 194 | 9 | :method | delete | 195 | 10 | :method | options | 196 | 11 | :method | connect | 197 | 12 | :method | patch | 198 | 13 | :method | link | 199 | 14 | :path | | 200 | 15 | :path | / | 201 | 16 | :host | | 202 | 17 | cookie | | 203 | 18 | :status | | 204 | 19 | :status | 200 | 205 | 20 | :status | 201 | 206 | 21 | :status | 202 | 207 | 22 | :status | 204 | 208 | 23 | :status | 205 | 209 | 24 | :status-text | | 210 | 25 | :status-text | OK | 211 | 26 | :version | | 212 | 27 | :version | 1.0 | 213 | 28 | :version | 1.1 | 214 | 29 | :version | 2.0 | 215 | 30 | accept | | 216 | 31 | accept-charset | | 217 | 32 | accept-encoding | | 218 | 33 | accept-language | | 219 | 34 | accept-ranges | | 220 | 35 | allow | | 221 | 36 | authorizations | | 222 | 37 | cache-control | | 223 | 38 | content-base | | 224 | 39 | content-encoding | | 225 | 40 | content-length | | 226 | 41 | content-location | | 227 | 42 | content-md5 | | 228 | 43 | content-range | | 229 | 44 | content-type | | 230 | 45 | etag | | 231 | 46 | expect | | 232 | 47 | expires | | 233 | 48 | from | | 234 | 49 | if-match | | 235 | 50 | if-modified-since | | 236 | 51 | if-none-match | | 237 | 52 | if-range | | 238 | 53 | if-unmodified-since | | 239 | 54 | last-modified | | 240 | 55 | location | | 241 | 56 | max-forwards | | 242 | 57 | origin | | 243 | 58 | pragma | | 244 | 59 | proxy-authenticate | | 245 | 60 | proxy-authorization | | 246 | 61 | range | | 247 | 62 | referer | | 248 | 63 | retry-after | | 249 | 64 | server | | 250 | 65 | set-cookie | | 251 | 66 | status | | 252 | 67 | te | | 253 | 68 | trailer | | 254 | 69 | transfer-encoding | | 255 | 70 | transfer-encoding | gzip | 256 | 71 | upgrade | | 257 | 72 | user-agent | | 258 | 73 | vary | | 259 | 74 | via | | 260 | 75 | warning | | 261 | 76 | www-authenticate | | 262 | 77 | access-control-allow-origin | | 263 | 78 | content-disposition | | 264 | 79 | get-dictionary | | 265 | 80 | p3p | | 266 | 81 | x-content-type-options | | 267 | 82 | x-frame-options | | 268 | 83 | x-powered-by | | 269 | 84 | x-xss-protection | | 270 | 85 | connection | | 271 | 86 | connection | keep-alive | 272 +----+-----------------------------+------------+ 274 The header :version=2.0 would be encoded as: 276 01 1D |..| 278 The header :method=GET would be encoded as: 280 01 06 |..| 282 The headers :version=2.0 and :method=GET would be encoded as: 284 02 06 1D |..| 286 The header :method=foo would be encoded as: 288 56 05 05 01 03 66 6F 6F |.....foo| 290 The header foo=bar would be encoded as: 292 b6 03 66 6f 6f 05 01 |..foo...| 293 03 62 61 72 |.bar| 295 4. Security Considerations 297 TBD 299 5. Normative References 301 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 302 Requirement Levels", BCP 14, RFC 2119, March 1997. 304 Author's Address 306 James M Snell 308 Email: jasnell@gmail.com