idnits 2.17.1 draft-ietf-httpbis-header-structure-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 abstract seems to contain references ([2], [3], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 1, 2018) is 2273 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 767 -- Looks like a reference, but probably isn't: '2' on line 769 -- Looks like a reference, but probably isn't: '3' on line 771 == Missing Reference: 'RFCxxxx' is mentioned on line 187, but not defined ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) -- Obsolete informational reference (is this intentional?): RFC 7231 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 7540 (Obsoleted by RFC 9113) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HTTP M. Nottingham 3 Internet-Draft Fastly 4 Intended status: Standards Track P-H. Kamp 5 Expires: August 5, 2018 The Varnish Cache Project 6 February 1, 2018 8 Structured Headers for HTTP 9 draft-ietf-httpbis-header-structure-03 11 Abstract 13 This document describes a set of data types and parsing algorithms 14 associated with them that are intended to make it easier and safer to 15 define and handle HTTP header fields. It is intended for use by new 16 specifications of HTTP header fields as well as revisions of existing 17 header field specifications when doing so does not cause 18 interoperability issues. 20 Note to Readers 22 _RFC EDITOR: please remove this section before publication_ 24 Discussion of this draft takes place on the HTTP working group 25 mailing list (ietf-http-wg@w3.org), which is archived at 26 https://lists.w3.org/Archives/Public/ietf-http-wg/ [1]. 28 Working Group information can be found at https://httpwg.github.io/ 29 [2]; source code and issues list for this draft can be found at 30 https://github.com/httpwg/http-extensions/labels/header-structure 31 [3]. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at https://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on August 5, 2018. 50 Copyright Notice 52 Copyright (c) 2018 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3 69 2. Specifying Structured Headers . . . . . . . . . . . . . . . . 4 70 3. Parsing Text into Structured Headers . . . . . . . . . . . . 5 71 4. Structured Header Data Types . . . . . . . . . . . . . . . . 6 72 4.1. Dictionaries . . . . . . . . . . . . . . . . . . . . . . 6 73 4.2. Lists . . . . . . . . . . . . . . . . . . . . . . . . . . 8 74 4.3. Parameterised Labels . . . . . . . . . . . . . . . . . . 9 75 4.4. Items . . . . . . . . . . . . . . . . . . . . . . . . . . 10 76 4.5. Integers . . . . . . . . . . . . . . . . . . . . . . . . 11 77 4.6. Floats . . . . . . . . . . . . . . . . . . . . . . . . . 11 78 4.7. Strings . . . . . . . . . . . . . . . . . . . . . . . . . 12 79 4.8. Labels . . . . . . . . . . . . . . . . . . . . . . . . . 14 80 4.9. Binary Content . . . . . . . . . . . . . . . . . . . . . 15 81 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 82 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 83 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 84 7.1. Normative References . . . . . . . . . . . . . . . . . . 16 85 7.2. Informative References . . . . . . . . . . . . . . . . . 17 86 7.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 17 87 Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . 17 88 A.1. Since draft-ietf-httpbis-header-structure-02 . . . . . . 17 89 A.2. Since draft-ietf-httpbis-header-structure-01 . . . . . . 18 90 A.3. Since draft-ietf-httpbis-header-structure-00 . . . . . . 18 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 93 1. Introduction 95 Specifying the syntax of new HTTP header fields is an onerous task; 96 even with the guidance in [RFC7231], Section 8.3.1, there are many 97 decisions - and pitfalls - for a prospective HTTP header field 98 author. 100 Once a header field is defined, bespoke parsers for it often need to 101 be written, because each header has slightly different handling of 102 what looks like common syntax. 104 This document introduces structured HTTP header field values 105 (hereafter, Structured Headers) to address these problems. 106 Structured Headers define a generic, abstract model for header field 107 values, along with a concrete serialisation for expressing that model 108 in textual HTTP headers, as used by HTTP/1 [RFC7230] and HTTP/2 109 [RFC7540]. 111 HTTP headers that are defined as Structured Headers use the types 112 defined in this specification to define their syntax and basic 113 handling rules, thereby simplifying both their definition and 114 parsing. 116 Additionally, future versions of HTTP can define alternative 117 serialisations of the abstract model of Structured Headers, allowing 118 headers that use it to be transmitted more efficiently without being 119 redefined. 121 Note that it is not a goal of this document to redefine the syntax of 122 existing HTTP headers; the mechanisms described herein are only 123 intended to be used with headers that explicitly opt into them. 125 To specify a header field that uses Structured Headers, see 126 Section 2. 128 Section 4 defines a number of abstract data types that can be used in 129 Structured Headers. Dictionaries and lists are only usable at the 130 "top" level, while the remaining types can be specified appear at the 131 top level or inside those structures. 133 Those abstract types can be serialised into textual headers - such as 134 those used in HTTP/1 and HTTP/2 - using the algorithms described in 135 Section 3. 137 1.1. Notational Conventions 139 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 140 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 141 "OPTIONAL" in this document are to be interpreted as described in BCP 142 14 [RFC2119] [RFC8174] when, and only when, they appear in all 143 capitals, as shown here. 145 This document uses the Augmented Backus-Naur Form (ABNF) notation of 146 [RFC5234], including the DIGIT, ALPHA and DQUOTE rules from that 147 document. It also includes the OWS rule from [RFC7230]. 149 2. Specifying Structured Headers 151 A HTTP header that uses Structured Headers need to be defined to do 152 so explicitly; recipients and generators need to know that the 153 requirements of this document are in effect. The simplest way to do 154 that is by referencing this document in its definition. 156 The field's definition will also need to specify the field-value's 157 allowed syntax, in terms of the types described in Section 4, along 158 with their associated semantics. 160 A header field definition cannot relax or otherwise modify the 161 requirements of this specification; doing so would preclude handling 162 by generic software. 164 However, header field authors are encouraged to clearly state 165 additional constraints upon the syntax, as well as the consequences 166 when those constraints are violated. Such additional constraints 167 could include additional structure (e.g., a list of URLs [RFC3986] 168 inside a string) that cannot be expressed using the primitives 169 defined here. 171 For example: 173 # FooExample Header 175 The FooExample HTTP header field conveys a list of integers about how 176 much Foo the sender has. 178 FooExample is a Structured header [RFCxxxx]. Its value MUST be a 179 dictionary ([RFCxxxx], Section Y.Y). 181 The dictionary MUST contain: 183 * A member whose key is "foo", and whose value is an integer 184 ([RFCxxxx], Section Y.Y), indicating the number of foos in 185 the message. 186 * A member whose key is "barUrls", and whose value is a string 187 ([RFCxxxx], Section Y.Y), conveying the Bar URLs for the message. 188 See below for processing requirements. 190 If the parsed header field does not contain both, it MUST be ignored. 192 "barUrls" contains a space-separated list of URI-references ([RFC3986], 193 Section 4.1): 195 barURLs = URI-reference *( 1*SP URI-reference ) 197 If a member of barURLs is not a valid URI-reference, it MUST be ignored. 199 If a member of barURLs is a relative reference ([RFC3986], Section 4.2), 200 it MUST be resolved ([RFC3986], Section 5) before being used. 202 Note that empty header field values are not allowed by the syntax, 203 and therefore will be considered errors. 205 3. Parsing Text into Structured Headers 207 When a receiving implementation parses textual HTTP header fields 208 (e.g., in HTTP/1 or HTTP/2) that are known to be Structured Headers, 209 it is important that care be taken, as there are a number of edge 210 cases that can cause interoperability or even security problems. 211 This section specifies the algorithm for doing so. 213 Given an ASCII string input_string that represents the chosen 214 header's field-value, return the parsed header value. 216 1. Discard any leading OWS from input_string. 218 2. If the field-value is defined to be a dictionary, let output be 219 the result of Parsing a Dictionary from Textual headers 220 (Section 4.1.1). 222 3. If the field-value is defined to be a list, let output be the 223 result of Parsing a List from Text (Section 4.2.1). 225 4. If the field-value is defined to be a parameterised label, let 226 output be the result of Parsing a Parameterised Label from 227 Textual headers (Section 4.3.1). 229 5. Otherwise, let output be the result of Parsing an Item from Text 230 (Section 4.4.1). 232 6. Discard any leading OWS from input_string. 234 7. If input_string is not empty, throw an error. 236 8. Otherwise, return output. 238 When generating input_string for a given header field, parsers MUST 239 combine all instances of it into one comma-separated field-value, as 240 per [RFC7230], Section 3.2.2; this assures that the header is 241 processed correctly. 243 Note that in the case of lists and dictionaries, this has the effect 244 of coalescing all of the values for that field. However, for 245 singular items and parameterised labels, it will result in an error 246 being thrown. 248 Additionally, note that the effect of the parsing algorithms as 249 specified is generally intolerant of syntax errors; if one is 250 encountered, the typical response is to throw an error, thereby 251 discarding the entire header field value. This includes any non- 252 ASCII characters in input_string. 254 4. Structured Header Data Types 256 This section defines the abstract value types that can be composed 257 into Structured Headers, along with the textual HTTP serialisations 258 of them. 260 4.1. Dictionaries 262 Dictionaries are unordered maps of key-value pairs, where the keys 263 are labels (Section 4.8) and the values are items (Section 4.4). 264 There can be between 1 and 1024 members, and keys are required to be 265 unique. 267 In the textual HTTP serialisation, keys and values are separated by 268 "=" (without whitespace), and key/value pairs are separated by a 269 comma with optional whitespace. Duplicate keys MUST be considered an 270 error. 272 dictionary = label "=" item *1023( OWS "," OWS label "=" item ) 274 For example, a header field whose value is defined as a dictionary 275 could look like: 277 ExampleDictHeader: foo=1.23, en="Applepie", da=*w4ZibGV0w6ZydGUK 279 Typically, a header field specification will define the semantics of 280 individual keys, as well as whether their presence is required or 281 optional. Recipients MUST ignore keys that are undefined or unknown, 282 unless the header field's specification specifically disallows them. 284 4.1.1. Parsing a Dictionary from Text 286 Given an ASCII string input_string, return a mapping of (label, 287 item). input_string is modified to remove the parsed value. 289 1. Let dictionary be an empty, unordered mapping. 291 2. While input_string is not empty: 293 1. Let this_key be the result of running Parse Label from Text 294 (Section 4.8.1) with input_string. If an error is 295 encountered, throw it. 297 2. If dictionary already contains this_key, throw an error. 299 3. Consume a "=" from input_string; if none is present, throw 300 an error. 302 4. Let this_value be the result of running Parse Item from Text 303 (Section 4.4.1) with input_string. If an error is 304 encountered, throw it. 306 5. Add key this_key with value this_value to dictionary. 308 6. If dictionary has more than 1024 members, throw an error. 310 7. Discard any leading OWS from input_string. 312 8. If input_string is empty, return dictionary. 314 9. Consume a COMMA from input_string; if no comma is present, 315 throw an error. 317 10. Discard any leading OWS from input_string. 319 3. Return dictionary. 321 4.2. Lists 323 Lists are arrays of items (Section 4.4) or parameterised labels 324 (Section 4.3), with one to 1024 members. 326 In the textual HTTP serialisation, each member is separated by a 327 comma and optional whitespace. 329 list = list_member 0*1023( OWS "," OWS list_member ) 330 list_member = item / parameterised 332 For example, a header field whose value is defined as a list of 333 labels could look like: 335 ExampleLabelListHeader: foo, bar, baz_45 337 and a header field whose value is defined as a list of parameterised 338 labels could look like: 340 ExampleParamListHeader: abc/def; g="hi";j, klm/nop 342 4.2.1. Parsing a List from Text 344 Given an ASCII string input_string, return a list of items. 345 input_string is modified to remove the parsed value. 347 1. Let items be an empty array. 349 2. While input_string is not empty: 351 1. Let item be the result of running Parse Item from Text 352 (Section 4.4.1) with input_string. If an error is 353 encountered, throw it. 355 2. Append item to items. 357 3. If items has more than 1024 members, throw an error. 359 4. Discard any leading OWS from input_string. 361 5. If input_string is empty, return items. 363 6. Consume a COMMA from input_string; if no comma is present, 364 throw an error. 366 7. Discard any leading OWS from input_string. 368 3. Return items. 370 4.3. Parameterised Labels 372 Parameterised Labels are labels (Section 4.8) with up to 256 373 parameters; each parameter has a label and an optional value that is 374 an item (Section 4.4). Ordering between parameters is not 375 significant, and duplicate parameters MUST be considered an error. 377 The textual HTTP serialisation uses semicolons (";") to delimit the 378 parameters from each other, and equals ("=") to delimit the parameter 379 name from its value. 381 parameterised = label *256( OWS ";" OWS label [ "=" item ] ) 383 For example, 385 ExampleParamHeader: abc_123;a=1;b=2; c 387 4.3.1. Parsing a Parameterised Label from Text 389 Given an ASCII string input_string, return a label with an mapping of 390 parameters. input_string is modified to remove the parsed value. 392 1. Let primary_label be the result of Parsing a Label from Text 393 (Section 4.8.1) from input_string. 395 2. Let parameters be an empty, unordered mapping. 397 3. In a loop: 399 1. Discard any leading OWS from input_string. 401 2. If the first character of input_string is not ";", exit the 402 loop. 404 3. Consume a ";" character from the beginning of input_string. 406 4. Discard any leading OWS from input_string. 408 5. let param_name be the result of Parsing a Label from Text 409 (Section 4.8.1) from input_string. 411 6. If param_name is already present in parameters, throw an 412 error. 414 7. Let param_value be a null value. 416 8. If the first character of input_string is "=": 418 1. Consume the "=" character at the beginning of 419 input_string. 421 2. Let param_value be the result of Parsing an Item from 422 Text (Section 4.4.1) from input_string. 424 9. If parameters has more than 255 members, throw an error. 426 10. Add param_name to parameters with the value param_value. 428 4. Return the tuple (primary_label, parameters). 430 4.4. Items 432 An item is can be a integer (Section 4.5), float (Section 4.6), 433 string (Section 4.7), label (Section 4.8) or binary content 434 (Section 4.9). 436 item = integer / float / string / label / binary 438 4.4.1. Parsing an Item from Text 440 Given an ASCII string input_string, return an item. input_string is 441 modified to remove the parsed value. 443 1. Discard any leading OWS from input_string. 445 2. If the first character of input_string is a "-" or a DIGIT, 446 process input_string as a number (Section 4.5.1) and return the 447 result, throwing any errors encountered. 449 3. If the first character of input_string is a DQUOTE, process 450 input_string as a string (Section 4.7.1) and return the result, 451 throwing any errors encountered. 453 4. If the first character of input_string is "*", process 454 input_string as binary content (Section 4.9.1) and return the 455 result, throwing any errors encountered. 457 5. If the first character of input_string is an lcalpha, process 458 input_string as a label (Section 4.8.1) and return the result, 459 throwing any errors encountered. 461 6. Otherwise, throw an error. 463 4.5. Integers 465 Abstractly, integers have a range of -9,223,372,036,854,775,808 to 466 9,223,372,036,854,775,807 inclusive (i.e., a 64-bit signed integer). 468 integer = ["-"] 1*19DIGIT 470 Parsers that encounter an integer outside the range defined above 471 MUST throw an error. Therefore, the value "9223372036854775809" 472 would be invalid. Likewise, values that do not conform to the ABNF 473 above are invalid, and MUST throw an error. 475 For example, a header whose value is defined as a integer could look 476 like: 478 ExampleIntegerHeader: 42 480 4.5.1. Parsing a Number from Text 482 NOTE: This algorithm parses both Integers and Floats Section 4.6, and 483 returns the corresponding structure. 485 1. If the first character of input_string is not "-" or a DIGIT, 486 throw an error. 488 2. Let input_number be the result of consuming input_string up to 489 (but not including) the first character that is not in DIGIT, 490 "-", and ".". 492 3. If input_number contains ".", parse it as a floating point number 493 and let output_number be the result. 495 4. Otherwise, parse input_number as an integer and let output_number 496 be the result. 498 5. Return output_number. 500 4.6. Floats 502 Abstractly, floats are integers with a fractional part. They have a 503 maximum of fifteen digits available to be used in both of the parts, 504 as reflected in the ABNF below; this allows them to be stored as IEEE 505 754 double precision numbers (binary64) ([IEEE754]). 507 The textual HTTP serialisation of floats allows a maximum of fifteen 508 digits between the integer and fractional part, with at least one 509 required on each side, along with an optional "-" indicating negative 510 numbers. 512 float = ["-"] ( 513 DIGIT "." 1*14DIGIT / 514 2DIGIT "." 1*13DIGIT / 515 3DIGIT "." 1*12DIGIT / 516 4DIGIT "." 1*11DIGIT / 517 5DIGIT "." 1*10DIGIT / 518 6DIGIT "." 1*9DIGIT / 519 7DIGIT "." 1*8DIGIT / 520 8DIGIT "." 1*7DIGIT / 521 9DIGIT "." 1*6DIGIT / 522 10DIGIT "." 1*5DIGIT / 523 11DIGIT "." 1*4DIGIT / 524 12DIGIT "." 1*3DIGIT / 525 13DIGIT "." 1*2DIGIT / 526 14DIGIT "." 1DIGIT ) 528 Values that do not conform to the ABNF above are invalid, and MUST 529 throw an error. 531 For example, a header whose value is defined as a float could look 532 like: 534 ExampleFloatHeader: 4.5 536 See Section 4.5.1 for the parsing algorithm for floats. 538 4.7. Strings 540 Abstractly, strings are ASCII strings [RFC0020], excluding control 541 characters (i.e., the range 0x20 to 0x7E). Note that this excludes 542 tabs, newlines and carriage returns. They may be at most 1024 543 characters long. 545 The textual HTTP serialisation of strings uses a backslash ("") to 546 escape double quotes and backslashes in strings. 548 string = DQUOTE 0*1024(char) DQUOTE 549 char = unescaped / escape ( DQUOTE / "\" ) 550 unescaped = %x20-21 / %x23-5B / %x5D-7E 551 escape = "\" 553 For example, a header whose value is defined as a string could look 554 like: 556 ExampleStringHeader: "hello world" 557 Note that strings only use DQUOTE as a delimiter; single quotes do 558 not delimit strings. Furthermore, only DQUOTE and "" can be escaped; 559 other sequences MUST generate an error. 561 Unicode is not directly supported in Structured Headers, because it 562 causes a number of interoperability issues, and - with few exceptions 563 - header values do not require it. 565 When it is necessary for a field value to convey non-ASCII string 566 content, binary content (Section 4.9) SHOULD be specified, along with 567 a character encoding (most likely, UTF-8). 569 4.7.1. Parsing a String from Text 571 Given an ASCII string input_string, return an unquoted string. 572 input_string is modified to remove the parsed value. 574 1. Let output_string be an empty string. 576 2. If the first character of input_string is not DQUOTE, throw an 577 error. 579 3. Discard the first character of input_string. 581 4. While input_string is not empty: 583 1. Let char be the result of removing the first character of 584 input_string. 586 2. If char is a backslash ("\"): 588 1. If input_string is now empty, throw an error. 590 2. Else: 592 1. Let next_char be the result of removing the first 593 character of input_string. 595 2. If next_char is not DQUOTE or "\", throw an error. 597 3. Append next_char to output_string. 599 3. Else, if char is DQUOTE, return output_string. 601 4. Else, append char to output_string. 603 5. If output_string contains more than 1024 characters, throw an 604 error. 606 5. Otherwise, throw an error. 608 4.8. Labels 610 Labels are short (up to 256 characters) textual identifiers; their 611 abstract model is identical to their expression in the textual HTTP 612 serialisation. 614 label = lcalpha *255( lcalpha / DIGIT / "_" / "-"/ "*" / "/" ) 615 lcalpha = %x61-7A ; a-z 617 Note that labels can only contain lowercase letters. 619 For example, a header whose value is defined as a label could look 620 like: 622 ExampleLabelHeader: foo/bar 624 4.8.1. Parsing a Label from Text 626 Given an ASCII string input_string, return a label. input_string is 627 modified to remove the parsed value. 629 1. If the first character of input_string is not lcalpha, throw an 630 error. 632 2. Let output_string be an empty string. 634 3. While input_string is not empty: 636 1. Let char be the result of removing the first character of 637 input_string. 639 2. If char is not one of lcalpha, DIGIT, "_", "-", "*" or "/": 641 1. Prepend char to input_string. 643 2. Return output_string. 645 3. Append char to output_string. 647 4. If output_string contains more than 256 characters, throw an 648 error. 650 4. Return output_string. 652 4.9. Binary Content 654 Arbitrary binary content up to 16K in size can be conveyed in 655 Structured Headers. 657 The textual HTTP serialisation indicates their presence by a leading 658 "*", with the data encoded using Base 64 Encoding [RFC4648], 659 Section 4. 661 Parsers MUST consider encoded data that is padded an error, as "=" 662 might be confused with the use of dictionaries). See [RFC4648], 663 Section 3.2. 665 Likewise, parsers MUST consider encoded data that has non-zero pad 666 bits an error. See [RFC4648], Section 3.5. 668 This specification does not relax the requirements in [RFC4648], 669 Section 3.1 and 3.3; therefore, parsers MUST consider characters 670 outside the base64 alphabet and line feeds in encoded data as errors. 672 binary = "*" 0*21846(base64) "*" 673 base64 = ALPHA / DIGIT / "+" / "/" 675 For example, a header whose value is defined as binary content could 676 look like: 678 ExampleBinaryHeader: *cHJldGVuZCB0aGlzIGlzIGJpbmFyeSBjb250ZW50Lg* 680 4.9.1. Parsing Binary Content from Text 682 Given an ASCII string input_string, return binary content. 683 input_string is modified to remove the parsed value. 685 1. If the first character of input_string is not "*", throw an 686 error. 688 2. Discard the first character of input_string. 690 3. Let b64_content be the result of removing content of input_string 691 up to but not including the first instance of the character "_". 692 If there is not a "_" character before the end of input_string, 693 throw an error. 695 4. Consume the "*" character at the beginning of input_string. 697 5. If b64_content is has more than 21846 characters, throw an error. 699 6. Let binary_content be the result of Base 64 Decoding [RFC4648] 700 b64_content, synthesising padding if necessary. If an error is 701 encountered, throw it (note the requirements about recipient 702 behaviour in Section 4.9). 704 7. Return binary_content. 706 5. IANA Considerations 708 This draft has no actions for IANA. 710 6. Security Considerations 712 TBD 714 7. References 716 7.1. Normative References 718 [RFC0020] Cerf, V., "ASCII format for network interchange", STD 80, 719 RFC 20, DOI 10.17487/RFC0020, October 1969, 720 . 722 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 723 Requirement Levels", BCP 14, RFC 2119, 724 DOI 10.17487/RFC2119, March 1997, 725 . 727 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 728 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 729 . 731 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 732 Specifications: ABNF", STD 68, RFC 5234, 733 DOI 10.17487/RFC5234, January 2008, 734 . 736 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 737 Protocol (HTTP/1.1): Message Syntax and Routing", 738 RFC 7230, DOI 10.17487/RFC7230, June 2014, 739 . 741 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 742 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 743 May 2017, . 745 7.2. Informative References 747 [IEEE754] IEEE, "IEEE Standard for Floating-Point Arithmetic", 2008, 748 . 750 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 751 Resource Identifier (URI): Generic Syntax", STD 66, 752 RFC 3986, DOI 10.17487/RFC3986, January 2005, 753 . 755 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 756 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 757 DOI 10.17487/RFC7231, June 2014, 758 . 760 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 761 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 762 DOI 10.17487/RFC7540, May 2015, 763 . 765 7.3. URIs 767 [1] https://lists.w3.org/Archives/Public/ietf-http-wg/ 769 [2] https://httpwg.github.io/ 771 [3] https://github.com/httpwg/http-extensions/labels/header-structure 773 Appendix A. Changes 775 A.1. Since draft-ietf-httpbis-header-structure-02 777 o Split Numbers into Integers and Floats. 779 o Define number parsing. 781 o Tighten up binary parsing and give it an explicit end delimiter. 783 o Clarify that mappings are unordered. 785 o Allow zero-length strings. 787 o Improve string parsing algorithm. 789 o Improve limits in algorithms. 791 o Require parsers to combine header fields before processing. 793 o Throw an error on trailing garbage. 795 A.2. Since draft-ietf-httpbis-header-structure-01 797 o Replaced with draft-nottingham-structured-headers. 799 A.3. Since draft-ietf-httpbis-header-structure-00 801 o Added signed 64bit integer type. 803 o Drop UTF8, and settle on BCP137 ::EmbeddedUnicodeChar for h1- 804 unicode-string. 806 o Change h1_blob delimiter to ":" since "'" is valid t_char 808 Authors' Addresses 810 Mark Nottingham 811 Fastly 813 Email: mnot@mnot.net 814 URI: https://www.mnot.net/ 816 Poul-Henning Kamp 817 The Varnish Cache Project 819 Email: phk@varnish-cache.org