idnits 2.17.1 draft-snell-httpbis-bohe-01.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 (October 3, 2012) is 4216 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 340, 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 October 3, 2012 4 Intended status: Informational 5 Expires: April 6, 2013 7 HTTP/2.0 Discussion: Binary Optimized Header Encoding 8 draft-snell-httpbis-bohe-01 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 April 6, 2013. 32 Copyright Notice 34 Copyright (c) 2012 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 1.1. Registered Headers . . . . . . . . . . . . . . . . . . . . 3 51 1.2. Extension Headers . . . . . . . . . . . . . . . . . . . . 4 52 1.3. Binary vs. Character Values . . . . . . . . . . . . . . . 5 53 1.4. Example Headers . . . . . . . . . . . . . . . . . . . . . 7 54 2. Security Considerations . . . . . . . . . . . . . . . . . . . 8 55 3. Normative References . . . . . . . . . . . . . . . . . . . . . 9 56 Appendix A. Additional Examples . . . . . . . . . . . . . . . . . 9 57 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 59 1. Binary Optimized Header Encoding 61 Binary Optimized Header Encoding is a proposed alternative 62 serialization for headers within SPDY SYN_STREAM, SYN_REPLY and 63 HEADERS frames that is designed to optimize generation, consumption 64 and processing of the most commonly used HTTP headers. 66 Alternate Header Block Serialization: 68 +------------------------------------+ 69 | Number of Headers (8bit) | 70 +------------------------------------+ 71 |T| Header | 72 +------------------------------------+ 73 | ... | 75 Within the existing SPDY Header Block, a 32-bit value is used to 76 identify the number of headers within the block. For all practical 77 purposes, it is exceedingly unlikely that a single block of headers 78 will contain anywhere near 4,294,967,295 distinct headers. Obviously 79 a 32-bit integer is significant overkill for this purpose. As an 80 alternative, an 8-bit value is suggested. 82 The header block consists of zero or more distinct headers, each of 83 which begin with a single Type-bit whose value indicates the type of 84 header. There are two header types: Registered and Extension. The 85 specific structure of the header depends on the type. 87 The header block MAY be compressed as described within 88 [draft-montenegro-httpbis-speed-mobility-02]. 90 1.1. Registered Headers 92 Registered Headers are well-known and well-defined header fields for 93 which there is a published RFC and IANA registration. Each is 94 assigned an unsigned 15-bit integer identifier. 96 The structure of Registered Headers: 98 +------------------------------+ 99 |0| id (15-bit) | 100 +------------------------------+ 101 |E|M| len (22-bit) | 102 +------------------------------+ 103 | value... | 104 +------------------------------+ 106 The first single bit within the structure is the Type-bit. When this 107 bit is off, the header is a Registered Header. 109 The next fifteen bits specify the header's specific numeric 110 identifier as assigned within the IANA registry. 112 The next bit (E) indicates, when set, that the header field value 113 contains UTF-8 encoded character content. If the bit is not set, the 114 value is assumed to contain non-character-based binary data. 116 Following the identifier are 2 reserved bits: 117 o The first (E) indicates that the header value contains UTF-8 118 encoded character content. If the bit is not set, the value is 119 assumed to contain non-character-based binary data. 120 o The second (M) indicates that the value includes multiple NUL (0) 121 separated values. When set, processors MUST treat NUL (0) octets 122 within the value as a delimiter and not as part of the value 123 itself. 125 The remaining content of the structure consists of a 22-bit unsigned 126 integer specifying the remaining length of the header value. The 127 value MAY be zero length. 129 The minimum length of a registered header is 5-octets (40-bits). 131 When bit M is set, the header may contain multiple values separated 132 by a single NUL (0) byte. Each distinct value MUST NOT be zero- 133 length. When bits E and M are bot not set, NUL bytes contained 134 within the value are to be considered part of the value. The use of 135 NUL bytes within character-based values is not permitted except when 136 used as a delimiter separating multiple values. 138 When multiple values are included, the value length field MUST 139 specify the total length, in octets, of all values plus the number of 140 NUL (0) byte separators. For example, for a header value consisting 141 of the two strings "foo" and "bar", the total value length would be 142 7. 144 1.2. Extension Headers 146 Extension Headers are simple name+value pairs essentially as they 147 exist today, but with a number of important modifications. 149 The structure of Extension Headers 151 +------------------------------+ 152 |1| namelen (7) | name | 153 +------------------------------+ 154 |E|M| val len (22) | value | 155 +------------------------------+ 157 The first single bit is the Type-bit. When this bit is on, the 158 header is an Extension Header. 160 The next 7-bits specify the length in octets of the ASCII-encoded 161 header name as unsigned integer, followed by the name itself. The 162 name MUST conform to the field-name construction as defined in 163 [draft-ietf-httpbis-p1-messaging-2]. 165 Following the identifier are 2 reserved bits: 166 o The first (E) indicates that the header value contains UTF-8 167 encoded character content. If the bit is not set, the value is 168 assumed to contain non-character-based binary data. 169 o The second (M) indicates that the header specifies multiple NUL 170 (0) separated values. When set, processors MUST treat NUL (0) 171 octets within the value as a value-separator and not as part of 172 the value itself. 174 The length of the remaining value is specified as an unsigned 22-bit 175 integer, followed by the value itself. Zero length values are 176 permitted. 178 When bit M is set, the header may contain multiple values separated 179 by a single NUL (0) byte. Each distinct value MUST NOT be zero- 180 length. When bits E and M are bot not set, NUL bytes contained 181 within the value are to be considered part of the value. The use of 182 NUL bytes within character-based values is not permitted except when 183 used as a delimiter separating multiple values. 185 When multiple values are included, the value length field MUST 186 specify the total length, in octets, of all values plus the number of 187 NUL (0) byte separators. For example, for a header value consisting 188 of the two strings "foo" and "bar", the total value length would be 189 7. 191 1.3. Binary vs. Character Values 193 Specific header values can be encoded as either a stream of binary 194 octets or as UTF-8 encoded character data. 196 For example, within the existing SPDY specification, the HTTP Version 197 is represented as a header using the field-name ":version" with the 198 version number represented as an ASCII string, consuming 19-bytes in 199 all. 201 Version Header using the existing SPDY encoding: 203 00 00 00 08 3a 76 65 72 |....:ver| 204 73 69 6f 6e 00 00 00 03 |sion....| 205 31 2e 31 |2.0| 207 Using the Binary Optimized Header Encoding, this can be reduced to a 208 compact 7 or 8 bytes using either binary or character data: 210 Version Header using Character Data: 212 00 01 80 00 03 31 2e 31 |.....2.0| 214 Version Header using Binary Data: 216 00 01 00 00 02 02 00 |.......| 218 Likewise, SPDY uses a ":method" header to specify the HTTP Method 219 used for a particular request, with the value represented as an ASCII 220 string, consuming 18 bytes for GET requests. 222 Method Header using the existing SPDY encoding: 224 00 00 00 07 3a 6d 65 74 |....:met| 225 68 6f 64 00 00 00 03 47 |hod....G| 226 45 54 |GET| 228 Using optimized encoding, this can be reduced to a compact 6 or 8 229 bytes using either binary or character data: 231 Method Header using Character Data: 233 00 02 80 00 03 47 45 54 |.....GET| 235 Method Header using Binary Data, assuming the value 0x1 is defined to 236 represent the GET method: 238 00 02 00 00 01 01 |......| 240 There are many headers used within HTTP applications for which binary 241 encodings would be difficult or unnecessary. For those, utilizing 242 the character encoding option would be appropriate. With some work 243 it should be possible to define optimized binary encodings for many 244 of the existing complex headers. 246 1.4. Example Headers 248 Assume the following registered headers: 250 +--------------------+----+ 251 | HTTP Header | ID | 252 +--------------------+----+ 253 | Version | 1 | 254 | Method | 2 | 255 | Host | 3 | 256 | Path (Request URI) | 4 | 257 | Accept-Language | 5 | 258 +--------------------+----+ 260 And the following values representing known HTTP Methods: 262 +---------+-------+ 263 | Method | Value | 264 +---------+-------+ 265 | GET | 1 | 266 | POST | 2 | 267 | PUT | 3 | 268 | DELETE | 4 | 269 | PATCH | 5 | 270 | HEAD | 6 | 271 | OPTIONS | 7 | 272 | CONNECT | 8 | 273 +---------+-------+ 275 The Version header can be encoded as (7-bytes): 277 00 01 00 00 02 02 00 |.......| 279 The GET Method header can be encoded as (6-bytes): 281 00 02 00 00 01 01 |......| 283 The Host Header can be encoded as (20-bytes): 285 00 03 80 00 0f 77 77 77 |.....www| 286 2e 65 78 61 6d 70 6c 65 |.example| 287 2e 6f 72 67 |.org| 289 A simple Accept-Lang header would be encoded as (10-bytes): 291 00 05 80 00 05 65 6e 2d |.....en-| 292 55 53 |US| 294 A Path header encoding the request URI (45-bytes): 296 00 04 80 00 28 2f 74 68 |...../th| 297 69 73 2f 69 73 2f 74 68 |is/is/th| 298 65 2f 72 65 71 75 65 73 |e/reques| 299 74 3f 69 73 3d 69 74 26 |t?is=it&| 300 6e 6f 74 3d 62 65 61 75 |not=beau| 301 74 69 66 75 6c |tiful| 303 The combined serialization of the five headers into a single block 304 requires a total of 89 bytes. By comparison, the equivalent 305 serialization using the existing SPDY encoding requires 150 bytes 306 sans compression (28 bytes of which are wasted by the unnecessary use 307 of int32). 309 The equivalent SPDY encoding: 311 00 00 00 05 00 00 00 08 |........| 312 3a 76 65 72 73 69 6f 6e |:version| 313 00 00 00 03 31 2e 31 00 |....1.1.| 314 00 00 07 3a 6d 65 74 68 |...:meth| 315 6f 64 00 00 00 03 47 45 |od....GE| 316 54 00 00 00 05 3a 68 6f |T....:ho| 317 73 74 00 00 00 0f 77 77 |st....ww| 318 77 2e 65 78 61 6d 70 6c |w.exampl| 319 65 2e 6f 72 67 00 00 00 |e.org...| 320 0f 41 63 63 65 70 74 2d |.Accept-| 321 4c 61 6e 67 75 61 67 65 |Language| 322 00 00 00 05 65 6e 2d 55 |....en-U| 323 53 00 00 00 05 3a 70 61 |S....:pa| 324 74 68 00 00 00 28 2f 74 |th..../t| 325 68 69 73 2f 69 73 2f 74 |his/is/t| 326 68 65 2f 72 65 71 75 65 |he/reque| 327 73 74 3f 69 73 3d 69 74 |st?is=it| 328 26 6e 6f 74 3d 62 65 61 |¬=bea| 329 75 74 69 66 75 6c |utiful| 331 Note that the equivalent information encoded within an HTTP/1.1 332 request message requires 102 bytes. 334 2. Security Considerations 336 TBD 338 3. Normative References 340 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 341 Requirement Levels", BCP 14, RFC 2119, March 1997. 343 Appendix A. Additional Examples 345 Assuming the following (intentionally incomplete) header 346 registrations adapted from the existing http-bis specifications. 348 +---------------------+----+ 349 | HTTP Header | ID | 350 +---------------------+----+ 351 | Version | 1 | 352 | Method | 2 | 353 | Host | 3 | 354 | Path (Request URI) | 4 | 355 | Status | 5 | 356 | Status-Text | 6 | 357 | Content-Length | 7 | 358 | Content-Type | 8 | 359 | Content-Encoding | 9 | 360 | Expect | 10 | 361 | Location | 11 | 362 | Last-Modified | 12 | 363 | ETag | 13 | 364 | If-Match | 14 | 365 | If-None-Match | 15 | 366 | If-Modified-Since | 16 | 367 | If-Unmodified-Since | 17 | 368 | Age | 18 | 369 | Cache-Control | 19 | 370 | Expires | 20 | 371 | Vary | 21 | 372 | Accept | 22 | 373 | Accept-Language | 23 | 374 | Accept-Charset | 24 | 375 | Accept-Encoding | 25 | 376 | Allow | 26 | 377 | Content-Language | 27 | 378 | Content-Location | 28 | 379 | Date | 29 | 380 | From | 30 | 381 | Warning | 31 | 382 +---------------------+----+ 384 And the following values representing known HTTP Methods: 386 +---------+-------+ 387 | Method | Value | 388 +---------+-------+ 389 | GET | 1 | 390 | POST | 2 | 391 | PUT | 3 | 392 | DELETE | 4 | 393 | PATCH | 5 | 394 | HEAD | 6 | 395 | OPTIONS | 7 | 396 | CONNECT | 8 | 397 +---------+-------+ 399 We can derive the following optimized encodings: 401 Version Header: 403 00 01 00 00 02 02 00 |.......| 405 Method Header (GET Request) 407 00 02 00 00 01 01 |......| 409 Method Header (PATCH Request) 411 00 02 00 00 01 05 |......| 413 Method Header (Custom "FOO" Method) 415 00 02 80 00 03 46 4F 4F |.....FOO| 417 Host Header: 419 00 03 80 00 0f 77 77 77 |.....www| 420 2e 65 78 61 6d 70 6c 65 |.example| 421 2e 6f 72 67 |.org| 423 Representation of HTTP Response Status ("200 OK") as two separate 424 headers, one containing the status code, the other containing the 425 status text: 427 00 05 00 00 01 C8 00 06 |........| 428 80 00 02 4F 4B |...OK| 430 An alternative would be represent the status as a single header 431 containing multiple values: 433 00 05 C0 00 04 C8 00 4F |.......O| 434 4B |K| 436 Content-Length Header (value encoded as uint32): 438 00 07 00 00 04 00 00 00 |........| 439 C8 |.| 441 Content-Type Header: 443 00 08 80 00 0A 69 6d 61 |.....ima| 444 67 65 2f 6a 70 65 67 |ge/jpeg| 446 Expect Header (Expect: 100): 448 00 0A 00 00 01 64 |......| 450 Last-Modified (Using RFC3339 Format): 452 00 0C 80 00 19 32 30 31 |.....201| 453 32 2d 30 38 2d 30 31 54 |2-08-01T| 454 30 34 3a 32 33 3a 31 32 |04:23:12| 455 2e 31 32 33 34 5a |.1234Z| 457 ETag (Strong Entity-Tag, String-format): 459 00 0D 80 00 07 22 61 62 |....."ab| 460 63 64 65 22 |cde"| 462 If-None-Match: 464 00 0F 80 00 07 22 61 62 |....."ab| 465 63 64 65 22 |cde"| 467 If-None-Match (Multiple values) 469 00 0F C0 00 0F 22 61 62 |....."ab| 470 63 64 65 22 00 22 61 62 |cde"."ab| 471 63 64 66 22 |cdf"| 473 Allow (GET, POST, FOO): 475 00 1A C0 00 07 01 00 02 |........| 476 00 46 4f 4f |.FOO| 478 Author's Address 480 James M Snell 482 Email: jasnell@gmail.com