idnits 2.17.1 draft-snell-httpbis-bohe-00.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 (August 2, 2012) is 4284 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 344, 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 August 2, 2012 4 Intended status: Informational 5 Expires: February 3, 2013 7 HTTP/2.0 Discussion: Binary Optimized Header Encoding 8 draft-snell-httpbis-bohe-00 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 February 3, 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 . . . . . . . . . . . . . . . . . . . . 5 52 1.3. Binary vs. Character Values . . . . . . . . . . . . . . . 5 53 1.4. Example Headers . . . . . . . . . . . . . . . . . . . . . 7 54 2. Security Considerations . . . . . . . . . . . . . . . . . . . 9 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 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 remaining header depends on the header 86 type. 88 The header block MAY be compressed as described within 89 [draft-montenegro-httpbis-speed-mobility-02]. 91 1.1. Registered Headers 93 Registered Headers are well-known and well-defined headers for which 94 there is a published RFC and IANA registration. Each is assigned an 95 unsigned 12-bit integer identifier and an unsigned 3-bit integer 96 codepage. If the codepage is 0, the implication is that the header 97 MUST be understood in order for the request or response message to be 98 handled properly. Codepages 1-5 represent "MUST-IGNORE" headers; 99 that is, such headers MUST be ignored by processors if they are 100 unrecognized by the processing application. Codepages 6 and 7 are 101 reserved for "Private Use", with Codepage 6 being used for "MUST 102 UNDERSTAND PRIVATE USE" headers. 104 The structure of Registered Headers: 106 +------------------------------+ 107 |0| cp(3-bit) | id (12-bit) | 108 +------------------------------+ 109 | flags(8-bit) | len (16-bit) | 110 +------------------------------+ 111 | value... | 112 +------------------------------+ 114 The first single bit within the structure is the Type-bit. When this 115 bit is off, the header is a Registered Header. 117 The next three bits identify the headers codepage. The value is 118 interpreted as an unsigned integer in the range 0-7. 120 The next twelve bits specify the header's specific numeric identifier 121 within the codepage. 123 Following the identifier are 8 reserved flag bits. 124 o Bit 0x1 indicates that the header value contains UTF-8 encoded 125 character content. If the bit is not set, the value is assumed to 126 contain non-character-based binary data. 127 o Bit 0x2 indicates that the header specifies multiple NUL (0) 128 separated values. When set, processors MUST treat NUL (0) octets 129 within the value as a delimiter and not as part of the value 130 itself. 132 The remaining content of the structure consists of a 16-bit unsigned 133 integer specifying the remaining length of the header value. The 134 value MAY be zero length. 136 The minimum length of a registered header is 5-octets (40-bits). 138 When Flag 0x2 is set, the header may contain multiple values 139 separated by a single NUL (0) byte. Each distinct value MUST NOT be 140 zero-length. When Flag 0x2 is not set, and Flag 0x1 is also not set, 141 NUL bytes contained within the value are to be considered part of the 142 value. The use of NUL bytes within character-based values is not 143 permitted except when used as a delimiter separating multiple values. 145 When multiple values are included, the value length field MUST 146 specify the total length, in octets, of all values plus the number of 147 NUL (0) byte separators. For example, for a header value consisting 148 of the two strings "foo" and "bar", the total value length would be 149 7. 151 1.2. Extension Headers 153 Extension Headers are simple name+value pairs essentially as they 154 exist today, but with a number of important modifications. 156 The structure of Extension Headers 158 +------------------------------+ 159 |1| flags(7-bit) | namelen (8) | 160 +------------------------------+ 161 | name | val len (16) | value | 162 +------------------------------+ 164 The first single bit is the Type-bit. When this bit is on, the 165 header is an Extension Header. 167 The next seven bits are reserved flags. 168 o Bit 0x1 indicates that the header value contains UTF-8 encoded 169 character content. If the bit is not set, the value is assumed to 170 contain non-character-based binary data. 171 o Bit 0x2 indicates that the header specifies multiple NUL (0) 172 separated values. When set, processors MUST treat NUL (0) octets 173 within the value as a value-separated and not as part of the value 174 itself. 176 The next 8-bits specify the length in octets of the ASCII-encoded 177 header name as unsigned integer, followed by the name itself. The 178 name MUST conform to the field-name construction as defined in 179 [draft-ietf-httpbis-p1-messaging-2]. 181 The length of the remaining value is specified as an unsigned 16-bit 182 integer, followed by the value itself. Zero length values are 183 permitted. 185 When Flag 0x2 is set, the header may contain multiple values 186 separated by a single NUL (0) byte. Each distinct value MUST be 187 zero-length. 189 When multiple values are included, the value length field MUST 190 specify the total length, in octets, of all values plus the number of 191 NUL (0) byte separators. For example, for a header value consisting 192 of the two strings "foo" and "bar", the total value length would be 193 7. 195 1.3. Binary vs. Character Values 197 Specific header values can be encoded as either a stream of binary 198 octets or as UTF-8 encoded character data. 200 For example, within the existing SPDY specification, the HTTP Version 201 is represented as a header using the field-name ":version" with the 202 version number represented as an ASCII string, consuming 19-bytes in 203 all. 205 Version Header using the existing SPDY encoding: 207 00 00 00 08 3a 76 65 72 |....:ver| 208 73 69 6f 6e 00 00 00 03 |sion....| 209 31 2e 31 |2.0| 211 Using the Binary Optimized Header Encoding, this can be reduced to a 212 compact 7 or 8 bytes using either binary or character data: 214 Version Header using Character Data: 216 00 01 01 00 03 31 2e 31 |.....2.0| 218 Version Header using Binary Data: 220 00 01 00 00 02 02 00 |.......| 222 Likewise, SPDY uses a ":method" header to specify the HTTP Method 223 used for a particular request, with the value represented as an ASCII 224 string, consuming 18 bytes for GET requests. 226 Method Header using the existing SPDY encoding: 228 00 00 00 07 3a 6d 65 74 |....:met| 229 68 6f 64 00 00 00 03 47 |hod....G| 230 45 54 |GET| 232 Using optimized encoding, this can be reduced to a compact 6 or 8 233 bytes using either binary or character data: 235 Method Header using Character Data: 237 00 02 01 00 03 47 45 54 |.....GET| 239 Method Header using Binary Data, assuming the value 0x1 is defined to 240 represent the GET method: 242 00 02 00 00 01 01 |......| 244 There are many headers used within HTTP applications for which binary 245 encodings would be difficult or unnecessary. For those, utilizing 246 the character encoding option would be appropriate. With some work 247 it should be possible to define optimized binary encodings for many 248 of the existing complex headers. 250 1.4. Example Headers 252 Assume the following registered headers: 254 +--------------------+----------+----+ 255 | HTTP Header | Codepage | ID | 256 +--------------------+----------+----+ 257 | Version | 0 | 1 | 258 | Method | 0 | 2 | 259 | Host | 0 | 3 | 260 | Path (Request URI) | 0 | 4 | 261 | Accept-Language | 1 | 1 | 262 +--------------------+----------+----+ 264 And the following values representing known HTTP Methods: 266 +---------+-------+ 267 | Method | Value | 268 +---------+-------+ 269 | GET | 1 | 270 | POST | 2 | 271 | PUT | 3 | 272 | DELETE | 4 | 273 | PATCH | 5 | 274 | HEAD | 6 | 275 | OPTIONS | 7 | 276 | CONNECT | 8 | 277 +---------+-------+ 279 The Version header can be encoded as (7-bytes): 281 00 01 00 00 02 02 00 |.......| 283 The GET Method header can be encoded as (6-bytes): 285 00 02 00 00 01 01 |......| 287 The Host Header can be encoded as (20-bytes): 289 00 03 01 00 0f 77 77 77 |.....www| 290 2e 65 78 61 6d 70 6c 65 |.example| 291 2e 6f 72 67 |.org| 293 A simple Accept-Lang header would be encoded as (10-bytes): 295 10 01 01 00 05 65 6e 2d |.....en-| 296 55 53 |US| 298 A Path header encoding the request URI (45-bytes): 300 00 04 01 00 28 2f 74 68 |...../th| 301 69 73 2f 69 73 2f 74 68 |is/is/th| 302 65 2f 72 65 71 75 65 73 |e/reques| 303 74 3f 69 73 3d 69 74 26 |t?is=it&| 304 6e 6f 74 3d 62 65 61 75 |not=beau| 305 74 69 66 75 6c |tiful| 307 The combined serialization of the five headers into a single block 308 requires a total of 89 bytes. By comparison, the equivalent 309 serialization using the existing SPDY encoding requires 150 bytes 310 sans compression (28 bytes of which are wasted by the unnecessary use 311 of int32). 313 The equivalent SPDY encoding: 315 00 00 00 05 00 00 00 08 |........| 316 3a 76 65 72 73 69 6f 6e |:version| 317 00 00 00 03 31 2e 31 00 |....1.1.| 318 00 00 07 3a 6d 65 74 68 |...:meth| 319 6f 64 00 00 00 03 47 45 |od....GE| 320 54 00 00 00 05 3a 68 6f |T....:ho| 321 73 74 00 00 00 0f 77 77 |st....ww| 322 77 2e 65 78 61 6d 70 6c |w.exampl| 323 65 2e 6f 72 67 00 00 00 |e.org...| 324 0f 41 63 63 65 70 74 2d |.Accept-| 325 4c 61 6e 67 75 61 67 65 |Language| 326 00 00 00 05 65 6e 2d 55 |....en-U| 327 53 00 00 00 05 3a 70 61 |S....:pa| 328 74 68 00 00 00 28 2f 74 |th..../t| 329 68 69 73 2f 69 73 2f 74 |his/is/t| 330 68 65 2f 72 65 71 75 65 |he/reque| 331 73 74 3f 69 73 3d 69 74 |st?is=it| 332 26 6e 6f 74 3d 62 65 61 |¬=bea| 333 75 74 69 66 75 6c |utiful| 335 Note that the equivalent information encoded within an HTTP/1.1 336 request message requires 102 bytes. 338 2. Security Considerations 340 TBD 342 3. Normative References 344 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 345 Requirement Levels", BCP 14, RFC 2119, March 1997. 347 Appendix A. Additional Examples 349 Assuming the following (intentionally incomplete) header 350 registrations adapted from the existing http-bis specifications. 352 +---------------------+----------+----+ 353 | HTTP Header | Codepage | ID | 354 +---------------------+----------+----+ 355 | Version | 0 | 1 | 356 | Method | 0 | 2 | 357 | Host | 0 | 3 | 358 | Path (Request URI) | 0 | 4 | 359 | Status | 0 | 5 | 360 | Status-Text | 0 | 6 | 361 | Content-Length | 0 | 7 | 362 | Content-Type | 0 | 8 | 363 | Content-Encoding | 0 | 9 | 364 | Expect | 0 | 10 | 365 | Location | 0 | 11 | 366 | Last-Modified | 0 | 12 | 367 | ETag | 0 | 13 | 368 | If-Match | 0 | 14 | 369 | If-None-Match | 0 | 15 | 370 | If-Modified-Since | 0 | 16 | 371 | If-Unmodified-Since | 0 | 17 | 372 | Age | 0 | 18 | 373 | Cache-Control | 0 | 19 | 374 | Expires | 0 | 20 | 375 | Vary | 0 | 21 | 376 | Accept | 1 | 1 | 377 | Accept-Language | 1 | 2 | 378 | Accept-Charset | 1 | 3 | 379 | Accept-Encoding | 1 | 4 | 380 | Allow | 1 | 5 | 381 | Content-Language | 1 | 6 | 382 | Content-Location | 1 | 7 | 383 | Date | 1 | 8 | 384 | From | 1 | 9 | 385 | Warning | 1 | 10 | 386 +---------------------+----------+----+ 388 And the following values representing known HTTP Methods: 390 +---------+-------+ 391 | Method | Value | 392 +---------+-------+ 393 | GET | 1 | 394 | POST | 2 | 395 | PUT | 3 | 396 | DELETE | 4 | 397 | PATCH | 5 | 398 | HEAD | 6 | 399 | OPTIONS | 7 | 400 | CONNECT | 8 | 401 +---------+-------+ 403 We can derive the following optimized encodings: 405 Version Header: 407 00 01 00 00 02 02 00 |.......| 409 Method Header (GET Request) 411 00 02 00 00 01 01 |......| 413 Method Header (PATCH Request) 415 00 02 00 00 01 05 |......| 417 Method Header (Custom "FOO" Method) 419 00 02 01 00 03 46 4F 4F |.....FOO| 421 Host Header: 423 00 03 01 00 0f 77 77 77 |.....www| 424 2e 65 78 61 6d 70 6c 65 |.example| 425 2e 6f 72 67 |.org| 427 Representation of HTTP Response Status ("200 OK"): 429 00 05 00 00 01 C8 00 06 |........| 430 01 00 02 4F 4B |...OK| 432 The status above is represented as two separate headers, one 433 containing the status code, the other containing the status text. 435 Content-Length Header (value encoded as uint32): 437 00 07 00 00 04 00 00 00 |........| 438 C8 |.| 440 Content-Type Header: 442 00 08 01 00 0A 69 6d 61 |.....ima| 443 67 65 2f 6a 70 65 67 |ge/jpeg| 445 Expect Header (Expect: 100): 447 00 0A 00 00 01 64 |......| 449 Last-Modified (Using RFC3339 Format): 451 00 0C 01 00 19 32 30 31 |.....201| 452 32 2d 30 38 2d 30 31 54 |2-08-01T| 453 30 34 3a 32 33 3a 31 32 |04:23:12| 454 2e 31 32 33 34 5a |.1234Z| 456 ETag (Strong Entity-Tag, String-format): 458 00 0D 01 00 07 22 61 62 |....."ab| 459 63 64 65 22 |cde"| 461 If-None-Match: 463 00 0F 01 00 07 22 61 62 |....."ab| 464 63 64 65 22 |cde"| 466 If-None-Match (Multiple values) 468 00 0F 03 00 0F 22 61 62 |....."ab| 469 63 64 65 22 00 22 61 62 |cde"."ab| 470 63 64 66 22 |cdf"| 472 Allow (GET, POST, FOO): 474 10 05 02 00 07 01 00 02 |........| 475 00 46 4f 4f |.FOO| 477 Author's Address 479 James M Snell 481 Email: jasnell@gmail.com