idnits 2.17.1 draft-nir-httpbis-che-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 9, 2012) is 4185 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Y. Nir 3 Internet-Draft Check Point 4 Intended status: Informational November 9, 2012 5 Expires: May 13, 2013 7 HTTP/2.0 Discussion: Compact Header Encoding 8 draft-nir-httpbis-che-01 10 Abstract 12 This document proposes an alternative encoding for HTTP headers. 13 This encoding is considerably more compact than the uncompressed 14 textual encoding in HTTP/1.1 and current HTTP/2.0 draft. 16 Status of this Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on May 13, 2013. 33 Copyright Notice 35 Copyright (c) 2012 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 1.1. Conventions Used in This Document . . . . . . . . . . . . 3 52 2. The Binary Encoding . . . . . . . . . . . . . . . . . . . . . 3 53 2.1. Flags . . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 2.2. Short Type-Value . . . . . . . . . . . . . . . . . . . . . 4 55 2.3. Long Type-Value . . . . . . . . . . . . . . . . . . . . . 4 56 2.4. Type-Length-Value . . . . . . . . . . . . . . . . . . . . 4 57 3. Header Encoding . . . . . . . . . . . . . . . . . . . . . . . 4 58 4. Custom Headers and Custom Enumerations . . . . . . . . . . . . 5 59 5. Default Headers . . . . . . . . . . . . . . . . . . . . . . . 6 60 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 61 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 62 8. Changes from Previous Versions . . . . . . . . . . . . . . . . 7 63 9. Normative References . . . . . . . . . . . . . . . . . . . . . 7 64 Appendix A. Additional Examples . . . . . . . . . . . . . . . . . 7 65 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 67 1. Introduction 69 HTTP/1.x and the current draft of HTTP/2.0 encode headers using text 70 labels and text values. HTTP/2.0 attempts to make this more 71 efficient by compressing the textual headers. This proposes a 72 binary-only alternative. 74 1.1. Conventions Used in This Document 76 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 77 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 78 document are to be interpreted as described in [RFC2119]. 80 2. The Binary Encoding 82 The header block is formatted as follows: 84 +------------------------------------+ 85 |1| version | 8 | 86 +------------------------------------+ 87 | Flags (8) | Length (24 bits) | 88 +------------------------------------+ 89 |X| Stream-ID (31bits) | 90 +------------------------------------+ 91 | Sequence of headers | 92 | | 93 +------------------------------------+ 95 The sequence of headers is just a list of the headers in one of 5 96 formats: 97 o Flags - These are headers with no associated data. The only 98 information they convey is by their mere presence. 99 o Short Type-Value - where the header is associated with a 16-bit 100 value. 101 o Long Type-Value - where the header is associated with a 32-bit 102 value. 103 o Type-Length-Value - where the length is specified in the header. 105 All formats include a 16-bit header identifier (see below), and those 106 identifiers will be allocated through a new IANA registry (see 107 Section 6). The header identifier specifies which format applies. 109 2.1. Flags 111 These headers are 16-bit numbers containing the header identifier. 113 +-----------------+ 114 |header identifier| 115 +-----------------+ 117 2.2. Short Type-Value 119 These headers have the 16-bit identifier, and also the 16-bit value. 121 +------------------------------------+ 122 |header identifier| Value | 123 +------------------------------------+ 125 2.3. Long Type-Value 127 These headers have the 16-bit identifier, and also a 32-bit value. 129 +------------------------------------+ 130 |header identifier| Value | 131 +-----------------+------------------+ 132 | Value (cont) | 133 +-----------------+ 135 2.4. Type-Length-Value 137 These headers have the 16-bit identifier, and also a 24-bit length 138 field, and a value of variable length. 140 +------------------------------------+ 141 |header identifier| Length | 142 +---------+-------+------------------+ 143 | Length | Value... | 144 +---------+--------------------------+ 146 3. Header Encoding 148 The encoding of each header is specified in the specification that 149 describes it. For convenience, this document describes some common 150 encodings. Specification writers SHOULD use these formats whenever 151 they are appropriate. 153 Unsigned integer numbers can be represented by either the short or 154 long type-value, depending on their range. Cache ages measured in 155 seconds, such as in HSTS should use the long type-value, whereas a 156 header specifying an age in days should probably use a short type- 157 value. Either way, the encoding can be called "INT". 159 Headers that hold an enumeration (such as Method) SHOULD use a short 160 type-value, and SHOULD reserve one value (0xffff) for custom values. 162 Time values should be encoded as strings using the RFC3339 format. 164 Strings such as names should use the TLV format, and SHOULD be 165 encoded as UTF-8. String headers should be specified by their 166 encoding, so "UTF8", or "ASCII". 168 For headers with multiple values, the general format is always TLV, 169 and the specification should list their type as either of three 170 things: 171 o Short values - a list of 16-bit values 172 o Short strings - a sequence of strings, each prefixed by a 1-octet 173 length field. 174 o Long strings - a sequence of strings, each prefixed by 1 2-octet 175 length field. 177 4. Custom Headers and Custom Enumerations 179 For each type of header, a range will be allocated for experimental 180 and custom headers. To avoid collisions, we define here a special 181 header to denote what kind of header this is. The header is has 182 identifier 49160 (0xC008), so it is TLV-formatted, and its value is 183 formatted as follows: 185 Custom header format 187 +------------------------------------+ 188 |header identifier| Flags | Name... | 189 +---------+-------+------------------+ 191 For example, suppose draft-nir-httpbis-copyright-notice defines a 192 header that contains a copyright notice for the content. I will use 193 65530 (0xFFFA). Note that the two headers don't have to be 194 consecutive. If the sender knows that the receiver recognizes this 195 header with this identifier, the Custom header MAY be omitted. 197 Custom and Copyright Headers 199 C0 08 00 00 0C FF FA 00 4C 4F 50 59 52 49 47 48 |........COPYRIGH| 200 54 FF FA 00 00 43 6f 70 79 72 69 67 68 74 20 28 |T....Copyright (| 201 63 29 20 32 30 31 32 20 49 45 54 46 20 54 72 75 |c) 2012 IETF Tru| 202 73 74 20 61 6e 64 20 74 68 65 20 70 65 72 73 6f |st and the perso| 203 6e 73 20 69 64 65 6e 74 69 66 69 65 64 20 61 73 |ns identified as| 204 20 74 68 65 20 64 6f 63 75 6d 65 6e 74 20 61 75 | the document au| 205 74 68 6f 72 73 2e 20 41 6c 6c 20 72 69 67 68 74 |thors. All right| 206 73 20 72 65 73 65 72 76 65 64 2e |s reserved. | 208 For custom values in enumerations we define the Custom-Value header 209 with identifier 49161 (0vC009), where the content is the string name 210 of the custom value. This header MUST follow the enumeration header. 212 5. Default Headers 214 Many requests share a lot of their headers. For example, the Cookie, 215 User-Agents, Host, Connection, and Accept* headers pretty much remain 216 constant between consecutive requests. 218 To make the per-stream Headers block even smaller, we allow a default 219 Headers block. This block is distinguished by having Stream-ID fixed 220 to all zeros. Additionally a new flag is defined: 222 0x02 = FLAG_UPD - marks that this frame updates the default headers 224 Every subsequent request is deemed to include all the default 225 headers, except where such headers are overridden by that request. 226 The default headers are persistent for the connection. 228 A default HEADERS with the FLAG_UPD flag cleared replaces the default 229 headers for this connection. A default HEADERS block with the 230 FLAG_UPD set updates the default headers for this connection by 231 replacing those that had already been set, and adding those that had 232 not been set. This is useful for example, if a cookie had been set 233 by the server. The only way to delete a header from the default 234 headers is by replacement - a default HEADERS block with FLAG_UPD 235 cleared. 237 6. IANA Considerations 239 IANA is requested to set up a new registry of header identifiers. 240 The value is 16-bit, and the range is partitioned as follows: 242 o 0-16383 - these values are allocated to flag headers, where the 243 format is as in Section 2.1 244 o 16384-32767 - these values are allocated to short type-value 245 headers, where the format is as in Section 2.2 246 o 32768-49151 - these values are allocated to long type-value 247 headers, where the format is as in Section 2.3 248 o 49152-65535 - these values are allocated to type-length-value 249 headers, where the format is as in Section 2.4 251 The ending quarter of each range shall be reserved for experimental 252 and custom usage, and shall not be allocated by standards action. 253 For example, the range 45056-49151 will be reserved for experimental 254 and custom long type-value headers. 256 7. Security Considerations 258 There are no security considerations for this draft. 260 8. Changes from Previous Versions 262 First version 264 9. Normative References 266 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 267 Requirement Levels", BCP 14, RFC 2119, March 1997. 269 Appendix A. Additional Examples 271 NOTE: Most of the below examples were shamelessly copied from 272 draft-snell-httpbis-bohe-01. 274 Assuming the following (intentionally incomplete) header 275 registrations: 277 +--------------------+-------+------+---------------------------+ 278 | HTTP Header | ID | Hex | Format | 279 +--------------------+-------+------+---------------------------+ 280 | Version | 16384 | 4000 | Major.Minor in 16-bit | 281 | Method | 16385 | 4001 | Enumeration | 282 | Host | 49152 | c000 | UTF8 | 283 | Path (Request URI) | 49153 | c001 | UTF8 | 284 | Status | 16386 | 4002 | uint16 | 285 | Status-Text | 49386 | c0ea | UTF8 | 286 | Content-Length | 32768 | 8000 | uint32 | 287 | Content-Type | 49154 | c002 | ASCII | 288 | Expect | 16387 | 4003 | uint16 | 289 | Last-Modified | 49155 | c003 | RFC3339 | 290 | ETag | 49156 | c004 | sequence of short strings | 291 | If-None-Match | 49157 | c005 | sequence of short strings | 292 | Allow | 49158 | c006 | sequence of uint16 | 293 | Do-Not-Track | 58 | 003a | flag | 294 +--------------------+-------+------+---------------------------+ 296 And the following values representing known HTTP Methods: 298 +---------+-------+ 299 | Method | Value | 300 +---------+-------+ 301 | GET | 1 | 302 | POST | 2 | 303 | PUT | 3 | 304 | DELETE | 4 | 305 | PATCH | 5 | 306 | HEAD | 6 | 307 | OPTIONS | 7 | 308 | CONNECT | 8 | 309 +---------+-------+ 311 Here is what the encoding looks like: 313 Version Header: 315 40 00 02 00 |@...| 317 Method Header (GET Request) 319 40 01 00 01 |@...| 321 Method Header (PATCH Request) 323 40 01 00 05 |@...| 325 Method Header (Custom "FOO" Method) 327 40 01 FF FF C0 09 00 03 46 4F 4F |@.......FOO | 329 Do Not Track 331 00 3A |.:| 333 Host Header: 335 C0 00 00 00 0F 77 77 77 2e 65 78 61 6d 70 6c 65 |.....www.example| 336 2e 6f 72 67 |.org | 338 HTTP Response Status ("200 OK") as two separate headers, one 339 containing the status code, the other containing the status text: 341 40 02 00 C8 C0 EA 00 00 02 4F 4B |@........OK | 343 Content-Length Header (value encoded as uint32): 345 80 00 00 00 00 C8 |......| 347 Content-Type Header (although maybe it should become an enum: 349 C0 02 00 00 0A 69 6d 61 67 65 2f 6a 70 65 67 |.....image/jpeg | 351 Expect Header (Expect: 100): 353 40 03 00 64 |...d| 355 Last-Modified (Using RFC3339 Format): 357 C0 03 00 00 19 32 30 31 32 2d 30 38 2d 30 31 54 |.....2012-08-01T| 358 30 34 3a 32 33 3a 31 32 2e 31 32 33 34 5a |04:23:12.1234Z | 360 ETag (Strong Entity-Tag, String-format): 362 C0 04 00 00 06 05 61 62 63 64 65 |......abcde | 364 If-None-Match (Multiple values) 366 C0 05 00 00 0C 05 61 62 63 64 65 05 61 62 63 64 |......abcde.abcd| 367 66 |f | 369 Allow (GET, POST, FOO): 371 C0 06 00 00 06 00 01 00 02 FF FF C0 09 00 00 04 |................| 372 03 46 4f 4f |.FOO | 374 Author's Address 376 Yoav Nir 377 Check Point Software Technologies Ltd. 378 5 Hasolelim st. 379 Tel Aviv 67897 380 Israel 382 Email: ynir@checkpoint.com