rfc9651.original | rfc9651.txt | |||
---|---|---|---|---|
HTTP M. Nottingham | Internet Engineering Task Force (IETF) M. Nottingham | |||
Internet-Draft Cloudflare | Request for Comments: 9651 Cloudflare | |||
Obsoletes: 8941 (if approved) P.-H. Kamp | Obsoletes: 8941 P.-H. Kamp | |||
Intended status: Standards Track The Varnish Cache Project | Category: Standards Track The Varnish Cache Project | |||
Expires: 23 October 2024 21 April 2024 | ISSN: 2070-1721 August 2024 | |||
Structured Field Values for HTTP | Structured Field Values for HTTP | |||
draft-ietf-httpbis-sfbis-06 | ||||
Abstract | Abstract | |||
This document describes a set of data types and associated algorithms | This document describes a set of data types and associated algorithms | |||
that are intended to make it easier and safer to define and handle | that are intended to make it easier and safer to define and handle | |||
HTTP header and trailer fields, known as "Structured Fields", | HTTP header and trailer fields, known as "Structured Fields", | |||
"Structured Headers", or "Structured Trailers". It is intended for | "Structured Headers", or "Structured Trailers". It is intended for | |||
use by specifications of new HTTP fields that wish to use a common | use by specifications of new HTTP fields that wish to use a common | |||
syntax that is more restrictive than traditional HTTP field values. | syntax that is more restrictive than traditional HTTP field values. | |||
This document obsoletes RFC 8941. | This document obsoletes RFC 8941. | |||
About This Document | ||||
This note is to be removed before publishing as an RFC. | ||||
Status information for this document may be found at | ||||
https://datatracker.ietf.org/doc/draft-ietf-httpbis-sfbis/. | ||||
Discussion of this document takes place on the HTTP Working Group | ||||
mailing list (mailto:ietf-http-wg@w3.org), which is archived at | ||||
https://lists.w3.org/Archives/Public/ietf-http-wg/. Working Group | ||||
information can be found at https://httpwg.org/. | ||||
Source for this draft and an issue tracker can be found at | ||||
https://github.com/httpwg/http-extensions/labels/header-structure. | ||||
Status of This Memo | Status of This Memo | |||
This Internet-Draft is submitted in full conformance with the | This is an Internet Standards Track document. | |||
provisions of BCP 78 and BCP 79. | ||||
Internet-Drafts are working documents of the Internet Engineering | ||||
Task Force (IETF). Note that other groups may also distribute | ||||
working documents as Internet-Drafts. The list of current Internet- | ||||
Drafts is at https://datatracker.ietf.org/drafts/current/. | ||||
Internet-Drafts are draft documents valid for a maximum of six months | This document is a product of the Internet Engineering Task Force | |||
and may be updated, replaced, or obsoleted by other documents at any | (IETF). It represents the consensus of the IETF community. It has | |||
time. It is inappropriate to use Internet-Drafts as reference | received public review and has been approved for publication by the | |||
material or to cite them other than as "work in progress." | Internet Engineering Steering Group (IESG). Further information on | |||
Internet Standards is available in Section 2 of RFC 7841. | ||||
This Internet-Draft will expire on 23 October 2024. | Information about the current status of this document, any errata, | |||
and how to provide feedback on it may be obtained at | ||||
https://www.rfc-editor.org/info/rfc9651. | ||||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2024 IETF Trust and the persons identified as the | Copyright (c) 2024 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents (https://trustee.ietf.org/ | Provisions Relating to IETF Documents | |||
license-info) in effect on the date of publication of this document. | (https://trustee.ietf.org/license-info) in effect on the date of | |||
Please review these documents carefully, as they describe your rights | publication of this document. Please review these documents | |||
and restrictions with respect to this document. Code Components | carefully, as they describe your rights and restrictions with respect | |||
extracted from this document must include Revised BSD License text as | to this document. Code Components extracted from this document must | |||
described in Section 4.e of the Trust Legal Provisions and are | include Revised BSD License text as described in Section 4.e of the | |||
provided without warranty as described in the Revised BSD License. | Trust Legal Provisions and are provided without warranty as described | |||
in the Revised BSD License. | ||||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction | |||
1.1. Intentionally Strict Processing . . . . . . . . . . . . . 4 | 1.1. Intentionally Strict Processing | |||
1.2. Notational Conventions . . . . . . . . . . . . . . . . . 5 | 1.2. Notational Conventions | |||
2. Defining New Structured Fields . . . . . . . . . . . . . . . 5 | 2. Defining New Structured Fields | |||
2.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . 6 | 2.1. Example | |||
2.2. Error Handling . . . . . . . . . . . . . . . . . . . . . 7 | 2.2. Error Handling | |||
2.3. Preserving Extensibility . . . . . . . . . . . . . . . . 7 | 2.3. Preserving Extensibility | |||
2.4. Using New Structured Types in Extensions . . . . . . . . 8 | 2.4. Using New Structured Types in Extensions | |||
3. Structured Data Types . . . . . . . . . . . . . . . . . . . . 9 | 3. Structured Data Types | |||
3.1. Lists . . . . . . . . . . . . . . . . . . . . . . . . . . 9 | 3.1. Lists | |||
3.1.1. Inner Lists . . . . . . . . . . . . . . . . . . . . . 10 | 3.1.1. Inner Lists | |||
3.1.2. Parameters . . . . . . . . . . . . . . . . . . . . . 10 | 3.1.2. Parameters | |||
3.2. Dictionaries . . . . . . . . . . . . . . . . . . . . . . 11 | 3.2. Dictionaries | |||
3.3. Items . . . . . . . . . . . . . . . . . . . . . . . . . . 13 | 3.3. Items | |||
3.3.1. Integers . . . . . . . . . . . . . . . . . . . . . . 13 | 3.3.1. Integers | |||
3.3.2. Decimals . . . . . . . . . . . . . . . . . . . . . . 13 | 3.3.2. Decimals | |||
3.3.3. Strings . . . . . . . . . . . . . . . . . . . . . . . 14 | 3.3.3. Strings | |||
3.3.4. Tokens . . . . . . . . . . . . . . . . . . . . . . . 14 | 3.3.4. Tokens | |||
3.3.5. Byte Sequences . . . . . . . . . . . . . . . . . . . 15 | 3.3.5. Byte Sequences | |||
3.3.6. Booleans . . . . . . . . . . . . . . . . . . . . . . 15 | 3.3.6. Booleans | |||
3.3.7. Dates . . . . . . . . . . . . . . . . . . . . . . . . 15 | 3.3.7. Dates | |||
3.3.8. Display Strings . . . . . . . . . . . . . . . . . . . 16 | 3.3.8. Display Strings | |||
4. Working with Structured Fields in HTTP . . . . . . . . . . . 16 | 4. Working with Structured Fields in HTTP | |||
4.1. Serializing Structured Fields . . . . . . . . . . . . . . 16 | 4.1. Serializing Structured Fields | |||
4.1.1. Serializing a List . . . . . . . . . . . . . . . . . 17 | 4.1.1. Serializing a List | |||
4.1.2. Serializing a Dictionary . . . . . . . . . . . . . . 19 | 4.1.2. Serializing a Dictionary | |||
4.1.3. Serializing an Item . . . . . . . . . . . . . . . . . 20 | 4.1.3. Serializing an Item | |||
4.1.4. Serializing an Integer . . . . . . . . . . . . . . . 21 | 4.1.4. Serializing an Integer | |||
4.1.5. Serializing a Decimal . . . . . . . . . . . . . . . . 21 | 4.1.5. Serializing a Decimal | |||
4.1.6. Serializing a String . . . . . . . . . . . . . . . . 22 | 4.1.6. Serializing a String | |||
4.1.7. Serializing a Token . . . . . . . . . . . . . . . . . 22 | 4.1.7. Serializing a Token | |||
4.1.8. Serializing a Byte Sequence . . . . . . . . . . . . . 23 | 4.1.8. Serializing a Byte Sequence | |||
4.1.9. Serializing a Boolean . . . . . . . . . . . . . . . . 23 | 4.1.9. Serializing a Boolean | |||
4.1.10. Serializing a Date . . . . . . . . . . . . . . . . . 23 | 4.1.10. Serializing a Date | |||
4.1.11. Serializing a Display String . . . . . . . . . . . . 24 | 4.1.11. Serializing a Display String | |||
4.2. Parsing Structured Fields . . . . . . . . . . . . . . . . 25 | 4.2. Parsing Structured Fields | |||
4.2.1. Parsing a List . . . . . . . . . . . . . . . . . . . 26 | 4.2.1. Parsing a List | |||
4.2.2. Parsing a Dictionary . . . . . . . . . . . . . . . . 28 | 4.2.2. Parsing a Dictionary | |||
4.2.3. Parsing an Item . . . . . . . . . . . . . . . . . . . 29 | 4.2.3. Parsing an Item | |||
4.2.4. Parsing an Integer or Decimal . . . . . . . . . . . . 31 | 4.2.4. Parsing an Integer or Decimal | |||
4.2.5. Parsing a String . . . . . . . . . . . . . . . . . . 33 | 4.2.5. Parsing a String | |||
4.2.6. Parsing a Token . . . . . . . . . . . . . . . . . . . 33 | 4.2.6. Parsing a Token | |||
4.2.7. Parsing a Byte Sequence . . . . . . . . . . . . . . . 34 | 4.2.7. Parsing a Byte Sequence | |||
4.2.8. Parsing a Boolean . . . . . . . . . . . . . . . . . . 35 | 4.2.8. Parsing a Boolean | |||
4.2.9. Parsing a Date . . . . . . . . . . . . . . . . . . . 35 | 4.2.9. Parsing a Date | |||
4.2.10. Parsing a Display String . . . . . . . . . . . . . . 35 | 4.2.10. Parsing a Display String | |||
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 | 5. IANA Considerations | |||
6. Security Considerations . . . . . . . . . . . . . . . . . . . 38 | 6. Security Considerations | |||
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 38 | 7. References | |||
7.1. Normative References . . . . . . . . . . . . . . . . . . 38 | 7.1. Normative References | |||
7.2. Informative References . . . . . . . . . . . . . . . . . 39 | 7.2. Informative References | |||
Appendix A. Frequently Asked Questions . . . . . . . . . . . . . 39 | Appendix A. Frequently Asked Questions | |||
A.1. Why Not JSON? . . . . . . . . . . . . . . . . . . . . . . 40 | A.1. Why Not JSON? | |||
Appendix B. Implementation Notes . . . . . . . . . . . . . . . . 40 | Appendix B. Implementation Notes | |||
Appendix C. ABNF . . . . . . . . . . . . . . . . . . . . . . . . 41 | Appendix C. ABNF | |||
Appendix D. Changes from RFC 8941 . . . . . . . . . . . . . . . 42 | Appendix D. Changes from RFC 8941 | |||
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 43 | Acknowledgements | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43 | Authors' Addresses | |||
1. Introduction | 1. Introduction | |||
Specifying the syntax of new HTTP header (and trailer) fields is an | Specifying the syntax of new HTTP header (and trailer) fields is an | |||
onerous task; even with the guidance in Section 16.3.2 of [HTTP], | onerous task; even with the guidance in Section 16.3.2 of [HTTP], | |||
there are many decisions -- and pitfalls -- for a prospective HTTP | there are many decisions -- and pitfalls -- for a prospective HTTP | |||
field author. | field author. | |||
Once a field is defined, bespoke parsers and serializers often need | Once a field is defined, bespoke parsers and serializers often need | |||
to be written, because each field value has a slightly different | to be written, because each field value has a slightly different | |||
skipping to change at page 5, line 14 ¶ | skipping to change at line 177 ¶ | |||
Note that as a result of this strictness, if a field is appended to | Note that as a result of this strictness, if a field is appended to | |||
by multiple parties (e.g., intermediaries or different components in | by multiple parties (e.g., intermediaries or different components in | |||
the sender), an error in one party's value is likely to cause the | the sender), an error in one party's value is likely to cause the | |||
entire field value to fail parsing. | entire field value to fail parsing. | |||
1.2. Notational Conventions | 1.2. Notational Conventions | |||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | |||
"OPTIONAL" in this document are to be interpreted as described in BCP | "OPTIONAL" in this document are to be interpreted as described in | |||
14 [RFC2119] [RFC8174] when, and only when, they appear in all | BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all | |||
capitals, as shown here. | capitals, as shown here. | |||
This document uses the VCHAR, SP, DIGIT, ALPHA, and DQUOTE rules from | This document uses the VCHAR, SP, DIGIT, ALPHA, and DQUOTE rules from | |||
[RFC5234] to specify characters and/or their corresponding ASCII | [RFC5234] to specify characters and/or their corresponding ASCII | |||
bytes, depending on context. It uses the tchar and OWS rules from | bytes, depending on context. It uses the tchar and OWS rules from | |||
[HTTP] for the same purpose. | [HTTP] for the same purpose. | |||
This document uses algorithms to specify parsing and serialization | This document uses algorithms to specify parsing and serialization | |||
behaviors. When parsing from HTTP fields, implementations MUST have | behaviors. When parsing from HTTP fields, implementations MUST have | |||
behavior that is indistinguishable from following the algorithms. | behavior that is indistinguishable from following the algorithms. | |||
skipping to change at page 6, line 15 ¶ | skipping to change at line 226 ¶ | |||
Typically, this means that a field definition will specify the top- | Typically, this means that a field definition will specify the top- | |||
level type -- List, Dictionary, or Item -- and then define its | level type -- List, Dictionary, or Item -- and then define its | |||
allowable types and constraints upon them. For example, a header | allowable types and constraints upon them. For example, a header | |||
defined as a List might have all Integer members, or a mix of types; | defined as a List might have all Integer members, or a mix of types; | |||
a header defined as an Item might allow only Strings, and | a header defined as an Item might allow only Strings, and | |||
additionally only strings beginning with the letter "Q", or strings | additionally only strings beginning with the letter "Q", or strings | |||
in lowercase. Likewise, Inner Lists (Section 3.1.1) are only valid | in lowercase. Likewise, Inner Lists (Section 3.1.1) are only valid | |||
when a field definition explicitly allows them. | when a field definition explicitly allows them. | |||
Fields that use the Display String type are advised to carefully | Fields that use the Display String type are advised to carefully | |||
specify their allowable unicode code points; for example, specifying | specify their allowable Unicode code points; for example, specifying | |||
the use of a profile from [PRECIS]. | the use of a profile from [PRECIS]. | |||
Field definitions can only use this specification for the entire | Field definitions can only use this specification for the entire | |||
field value, not a portion thereof. | field value, not a portion thereof. | |||
Specifications can refer to a field name as a "structured header | Specifications can refer to a field name as a "Structured Header | |||
name", "structured trailer name", or "structured field name" as | name", "Structured Trailer name", or "Structured Field name" as | |||
appropriate. Likewise, they can refer its field value as a | appropriate. Likewise, they can refer its field value as a | |||
"structured header value", "structured trailer value", or "structured | "Structured Header value", "Structured Trailer value", or "Structured | |||
field value" as necessary. | Field value" as necessary. | |||
This specification defines minimums for the length or number of | This specification defines minimums for the length or number of | |||
various structures supported by implementations. It does not specify | various structures supported by implementations. It does not specify | |||
maximum sizes in most cases, but authors should be aware that HTTP | maximum sizes in most cases, but authors should be aware that HTTP | |||
implementations do impose various limits on the size of individual | implementations do impose various limits on the size of individual | |||
fields, the total number of fields, and/or the size of the entire | fields, the total number of fields, and/or the size of the entire | |||
header or trailer section. | header or trailer section. | |||
2.1. Example | 2.1. Example | |||
A fictitious Foo-Example header field might be specified as: | A fictitious Foo-Example header field might be specified as: | |||
| 42. Foo-Example Header Field | | 42. Foo-Example Header Field | |||
| | | | |||
| The Foo-Example HTTP header field conveys information about how | | The Foo-Example HTTP header field conveys information about how | |||
| much Foo the message has. | | much Foo the message has. | |||
| | | | |||
| Foo-Example is an Item Structured Header Field [RFCnnnn]. Its | | Foo-Example is an Item Structured Header Field [RFC9651]. Its | |||
| value MUST be an Integer (Section 3.3.1 of [RFCnnnn]). | | value MUST be an Integer (Section 3.3.1 of [RFC9651]). | |||
| | | | |||
| Its value indicates the amount of Foo in the message, and it MUST | | Its value indicates the amount of Foo in the message, and it MUST | |||
| be between 0 and 10, inclusive; other values MUST cause the entire | | be between 0 and 10, inclusive; other values MUST cause the entire | |||
| header field to be ignored. | | header field to be ignored. | |||
| | | | |||
| The following parameter is defined: | | The following parameter is defined: | |||
| | | | |||
| * A parameter whose key is "foourl", and whose value is a String | | * A parameter whose key is "foourl", and whose value is a String | |||
| (Section 3.3.3 of [RFCnnnn]), conveying the Foo URL for the | | (Section 3.3.3 of [RFC9651]), conveying the Foo URL for the | |||
| message. See below for processing requirements. | | message. See below for processing requirements. | |||
| | | | |||
| "foourl" contains a URI-reference (Section 4.1 of [RFC3986]). If | | "foourl" contains a URI-reference (Section 4.1 of [RFC3986]). If | |||
| its value is not a valid URI-reference, the entire header field | | its value is not a valid URI-reference, the entire header field | |||
| MUST be ignored. If its value is a relative reference | | MUST be ignored. If its value is a relative reference | |||
| (Section 4.2 of [RFC3986]), it MUST be resolved (Section 5 of | | (Section 4.2 of [RFC3986]), it MUST be resolved (Section 5 of | |||
| [RFC3986]) before being used. | | [RFC3986]) before being used. | |||
| | | | |||
| For example: | | For example: | |||
| | | | |||
| Foo-Example: 2; foourl="https://foo.example.com/" | | Foo-Example: 2; foourl="https://foo.example.com/" | |||
2.2. Error Handling | 2.2. Error Handling | |||
When parsing fails, the entire field is ignored (see Section 4.2). | When parsing fails, the entire field is ignored (see Section 4.2). | |||
Field definitions cannot override this, because doing so would | Field definitions cannot override this because doing so would | |||
preclude handling by generic software; they can only add additional | preclude handling by generic software; they can only add additional | |||
constraints (for example, on the numeric range of Integers and | constraints (for example, on the numeric range of Integers and | |||
Decimals, the format of Strings and Tokens, the types allowed in a | Decimals, the format of Strings and Tokens, the types allowed in a | |||
Dictionary's values, or the number of Items in a List). | Dictionary's values, or the number of Items in a List). | |||
When field-specific constraints are violated, the entire field is | When field-specific constraints are violated, the entire field is | |||
also ignored, unless the field definition defines other handling | also ignored, unless the field definition defines other handling | |||
requirements. For example, if a header field is defined as an Item | requirements. For example, if a header field is defined as an Item | |||
and required to be an Integer, but a String is received, it should be | and required to be an Integer, but a String is received, it should be | |||
ignored unless that field's definition explicitly specifies | ignored unless that field's definition explicitly specifies | |||
otherwise. | otherwise. | |||
2.3. Preserving Extensibility | 2.3. Preserving Extensibility | |||
Structured Fields are designed to be extensible, because experience | Structured Fields are designed to be extensible because experience | |||
has shown that even when it is not foreseen, it is often necessary to | has shown that, even when it is not foreseen, it is often necessary | |||
modify and add to the allowable syntax and semantics of a field in a | to modify and add to the allowable syntax and semantics of a field in | |||
controlled fashion. | a controlled fashion. | |||
Both Items and Inner Lists allow Parameters as an extensibility | Both Items and Inner Lists allow Parameters as an extensibility | |||
mechanism; this means that their values can later be extended to | mechanism; this means that their values can later be extended to | |||
accommodate more information, if need be. To preserve forward | accommodate more information, if need be. To preserve forward | |||
compatibility, field specifications are discouraged from defining the | compatibility, field specifications are discouraged from defining the | |||
presence of an unrecognized parameter as an error condition. | presence of an unrecognized parameter as an error condition. | |||
Field specifications are required to be either an Item, List, or | Field specifications are required to be either an Item, List, or | |||
Dictionary to preserve extensibility. Fields that erroneously | Dictionary to preserve extensibility. Fields that erroneously | |||
defined as another type (e.g., Integer) are assumed to be Items | defined as another type (e.g., Integer) are assumed to be Items | |||
skipping to change at page 8, line 31 ¶ | skipping to change at line 337 ¶ | |||
field value be ignored by a recipient that understands the extension | field value be ignored by a recipient that understands the extension | |||
if constraints on the value it defines are not met. | if constraints on the value it defines are not met. | |||
2.4. Using New Structured Types in Extensions | 2.4. Using New Structured Types in Extensions | |||
Because a field definition needs to reference a specific RFC for | Because a field definition needs to reference a specific RFC for | |||
Structured Fields, the types available for use in its value are | Structured Fields, the types available for use in its value are | |||
limited to those defined in that RFC. For example, a field whose | limited to those defined in that RFC. For example, a field whose | |||
definition references this document can have a value that uses the | definition references this document can have a value that uses the | |||
Date type (Section 3.3.7), whereas a field whose definition | Date type (Section 3.3.7), whereas a field whose definition | |||
references RFC 8941 cannot, because it will be treated as invalid | references RFC 8941 cannot because it will be treated as invalid (and | |||
(and therefore discarded) by implementations of that specification. | therefore discarded) by implementations of that specification. | |||
This limitation also applies to future extensions to a field; for | This limitation also applies to future extensions to a field; for | |||
example, a field that is defined with reference to RFC 8941 cannot | example, a field that is defined with a reference to RFC 8941 cannot | |||
use the Date type, because some recipients might still be using an | use the Date type because some recipients might still be using a | |||
RFC 8941 parser to process it. | parser based on RFC 8941 to process it. | |||
However, this document is designed to be backwards-compatible with | However, this document is designed to be backward compatible with RFC | |||
RFC 8941; a parser that implements the requirements here can also | 8941; a parser that implements the requirements here can also parse | |||
parse valid Structured Fields whose definitions reference RFC 8941. | valid Structured Fields whose definitions reference RFC 8941. | |||
Upgrading a Structured Fields implementation to support a newer | Upgrading a Structured Fields implementation to support a newer | |||
revision of the specification (such as this document) brings the | revision of the specification (such as this document) brings the | |||
possibility that some field values that were invalid according to the | possibility that some field values that were invalid according to the | |||
earlier RFC might become valid when processed. | earlier RFC might become valid when processed. | |||
For example, field instance might contain a syntactically valid Date | For example, a field instance might contain a syntactically valid | |||
(Section 3.3.7), even though that field's definition does not | Date (Section 3.3.7), even though that field's definition does not | |||
accommodate Dates. An RFC8941 implementation would fail parsing such | accommodate Dates. An implementation based on RFC 8941 would fail | |||
a field instance, because they are not defined in that specification. | parsing such a field instance because it is not defined in that | |||
If that implementation were upgraded to this specification, parsing | specification. If that implementation were upgraded to this | |||
would now succeed. In some cases, the resulting Date value will be | specification, parsing would now succeed. In some cases, the | |||
rejected by field-specific logic, but values in fields that are | resulting Date value will be rejected by field-specific logic, but | |||
otherwise ignored (such as extension parameters) might not be | values in fields that are otherwise ignored (such as extension | |||
detected and the field might subsequently be accepted and processed. | parameters) might not be detected, and the field might subsequently | |||
be accepted and processed. | ||||
3. Structured Data Types | 3. Structured Data Types | |||
This section provides an overview of the abstract types that | This section provides an overview of the abstract types that | |||
Structured Fields use, and gives a brief description and examples of | Structured Fields use and gives a brief description and examples of | |||
how each of those types are serialized into textual HTTP fields. | how each of those types are serialized into textual HTTP fields. | |||
Section 4 specifies the details of how they are parsed from and | Section 4 specifies the details of how they are parsed from and | |||
serialized into textual HTTP fields. | serialized into textual HTTP fields. | |||
In summary: | In summary: | |||
* There are three top-level types that an HTTP field can be defined | * There are three top-level types that an HTTP field can be defined | |||
as: Lists, Dictionaries, and Items. | as: Lists, Dictionaries, and Items. | |||
* Lists and Dictionaries are containers; their members can be Items | * Lists and Dictionaries are containers; their members can be Items | |||
skipping to change at page 11, line 49 ¶ | skipping to change at line 499 ¶ | |||
entire field. This implies that fields defined as Dictionaries have | entire field. This implies that fields defined as Dictionaries have | |||
a default empty value. | a default empty value. | |||
Typically, a field specification will define the semantics of | Typically, a field specification will define the semantics of | |||
Dictionaries by specifying the allowed type(s) for individual members | Dictionaries by specifying the allowed type(s) for individual members | |||
by their keys, as well as whether their presence is required or | by their keys, as well as whether their presence is required or | |||
optional. Recipients MUST ignore members whose keys are undefined or | optional. Recipients MUST ignore members whose keys are undefined or | |||
unknown, unless the field's specification specifically disallows | unknown, unless the field's specification specifically disallows | |||
them. | them. | |||
When serialized as a textual HTTP field, Members are ordered as | When serialized as a textual HTTP field, members are ordered as | |||
serialized and separated by a comma with optional whitespace. Member | serialized and separated by a comma with optional whitespace. Member | |||
keys cannot contain uppercase characters. Keys and values are | keys cannot contain uppercase characters. Keys and values are | |||
separated by "=" (without whitespace). For example: | separated by "=" (without whitespace). For example: | |||
Example-Dict: en="Applepie", da=:w4ZibGV0w6ZydGU=: | Example-Dict: en="Applepie", da=:w4ZibGV0w6ZydGU=: | |||
Note that in this example, the final "=" is due to the inclusion of a | Note that in this example, the final "=" is due to the inclusion of a | |||
Byte Sequence; see Section 3.3.5. | Byte Sequence; see Section 3.3.5. | |||
Members whose value is Boolean (see Section 3.3.6) true MUST omit | Members whose value is Boolean (see Section 3.3.6) true MUST omit | |||
skipping to change at page 14, line 4 ¶ | skipping to change at line 595 ¶ | |||
3.3.2. Decimals | 3.3.2. Decimals | |||
Decimals are numbers with an integer and a fractional component. The | Decimals are numbers with an integer and a fractional component. The | |||
integer component has at most 12 digits; the fractional component has | integer component has at most 12 digits; the fractional component has | |||
at most three digits. | at most three digits. | |||
For example, a header whose value is defined as a Decimal could look | For example, a header whose value is defined as a Decimal could look | |||
like: | like: | |||
Example-Decimal: 4.5 | Example-Decimal: 4.5 | |||
While it is possible to serialize Decimals with leading zeros (e.g., | While it is possible to serialize Decimals with leading zeros (e.g., | |||
"0002.5", "-01.334"), trailing zeros (e.g., "5.230", "-0.40"), and | "0002.5", "-01.334"), trailing zeros (e.g., "5.230", "-0.40"), and | |||
signed zero (e.g., "-0.0"), these distinctions may not be preserved | signed zero (e.g., "-0.0"), these distinctions may not be preserved | |||
by implementations. | by implementations. | |||
Note that the serialization algorithm (Section 4.1.5) rounds input | Note that the serialization algorithm (Section 4.1.5) rounds input | |||
with more than three digits of precision in the fractional component. | with more than three digits of precision in the fractional component. | |||
If an alternative rounding strategy is desired, this should be | If an alternative rounding strategy is desired, this should be | |||
specified by the field definition to occur before serialization. | specified by the field definition to occur before serialization. | |||
3.3.3. Strings | 3.3.3. Strings | |||
Strings are zero or more printable ASCII [RFC0020] characters (i.e., | Strings are zero or more printable ASCII [RFC0020] characters (i.e., | |||
the range %x20 to %x7E). Note that this excludes tabs, newlines, | the range %x20 to %x7E). Note that this excludes tabs, newlines, | |||
carriage returns, etc. | carriage returns, etc. | |||
Non-ASCII characters are not directly supported in Strings, because | Non-ASCII characters are not directly supported in Strings because | |||
they cause a number of interoperability issues, and -- with few | they cause a number of interoperability issues, and -- with few | |||
exceptions -- field values do not require them. | exceptions -- field values do not require them. | |||
When it is necessary for a field value to convey non-ASCII content, a | When it is necessary for a field value to convey non-ASCII content, a | |||
Display String (Section 3.3.8) can be specified. | Display String (Section 3.3.8) can be specified. | |||
When serialized in a textual HTTP field, Strings are delimited with | When serialized in a textual HTTP field, Strings are delimited with | |||
double quotes, using a backslash ("\") to escape double quotes and | double quotes, using a backslash ("\") to escape double quotes and | |||
backslashes. For example: | backslashes. For example: | |||
skipping to change at page 14, line 45 ¶ | skipping to change at line 637 ¶ | |||
escaped; other characters after "\" MUST cause parsing to fail. | escaped; other characters after "\" MUST cause parsing to fail. | |||
Parsers MUST support Strings (after any decoding) with at least 1024 | Parsers MUST support Strings (after any decoding) with at least 1024 | |||
characters. | characters. | |||
3.3.4. Tokens | 3.3.4. Tokens | |||
Tokens are short textual words that begin with an alphabetic | Tokens are short textual words that begin with an alphabetic | |||
character or "*", followed by zero to many token characters, which | character or "*", followed by zero to many token characters, which | |||
are the same as those allowed by the "token" ABNF rule defined in | are the same as those allowed by the "token" ABNF rule defined in | |||
[HTTP], plus the ":" and "/" characters. | [HTTP] plus the ":" and "/" characters. | |||
For example: | For example: | |||
Example-Token: foo123/456 | Example-Token: foo123/456 | |||
Parsers MUST support Tokens with at least 512 characters. | Parsers MUST support Tokens with at least 512 characters. | |||
Note that Tokens are defined largely for compatibility with the data | Note that Tokens are defined largely for compatibility with the data | |||
model of existing HTTP fields, and may require additional steps to | model of existing HTTP fields and may require additional steps to use | |||
use in some implementations. As a result, new fields are encouraged | in some implementations. As a result, new fields are encouraged to | |||
to use Strings. | use Strings. | |||
3.3.5. Byte Sequences | 3.3.5. Byte Sequences | |||
Byte Sequences can be conveyed in Structured Fields. | Byte Sequences can be conveyed in Structured Fields. | |||
When serialized in a textual HTTP field, a Byte Sequence is delimited | When serialized in a textual HTTP field, a Byte Sequence is delimited | |||
with colons and encoded using base64 ([RFC4648], Section 4). For | with colons and encoded using base64 ([RFC4648], Section 4). For | |||
example: | example: | |||
Example-ByteSequence: :cHJldGVuZCB0aGlzIGlzIGJpbmFyeSBjb250ZW50Lg==: | Example-ByteSequence: :cHJldGVuZCB0aGlzIGlzIGJpbmFyeSBjb250ZW50Lg==: | |||
skipping to change at page 16, line 12 ¶ | skipping to change at line 701 ¶ | |||
to 9999 (i.e., -62,135,596,800 to 253,402,214,400 delta seconds from | to 9999 (i.e., -62,135,596,800 to 253,402,214,400 delta seconds from | |||
1970-01-01T00:00:00Z). | 1970-01-01T00:00:00Z). | |||
3.3.8. Display Strings | 3.3.8. Display Strings | |||
Display Strings are similar to Strings, in that they consist of zero | Display Strings are similar to Strings, in that they consist of zero | |||
or more characters, but they allow Unicode scalar values (i.e., all | or more characters, but they allow Unicode scalar values (i.e., all | |||
Unicode code points except for surrogates), unlike Strings. | Unicode code points except for surrogates), unlike Strings. | |||
Display Strings are intended for use in cases where a value is | Display Strings are intended for use in cases where a value is | |||
displayed to end users, and therefore may need to carry non-ASCII | displayed to end users and therefore may need to carry non-ASCII | |||
content. It is NOT RECOMMENDED that they be used in situations where | content. It is NOT RECOMMENDED that they be used in situations where | |||
a String (Section 3.3.3) or Token (Section 3.3.4) would be adequate, | a String (Section 3.3.3) or Token (Section 3.3.4) would be adequate | |||
because Unicode has processing considerations (e.g., normalization) | because Unicode has processing considerations (e.g., normalization) | |||
and security considerations (e.g., homograph attacks) that make it | and security considerations (e.g., homograph attacks) that make it | |||
more difficult to handle correctly. | more difficult to handle correctly. | |||
Note that Display Strings do not indicate the language used in the | Note that Display Strings do not indicate the language used in the | |||
value; that can be done separately if necessary (e.g., with a | value; that can be done separately if necessary (e.g., with a | |||
parameter). | parameter). | |||
In textual HTTP fields, Display Strings are represented in a manner | In textual HTTP fields, Display Strings are represented in a manner | |||
similar to Strings, except that non-ASCII characters are percent- | similar to Strings, except that non-ASCII characters are percent- | |||
skipping to change at page 24, line 12 ¶ | skipping to change at line 1085 ¶ | |||
1. Let output be "@". | 1. Let output be "@". | |||
2. Append to output the result of running Serializing an Integer | 2. Append to output the result of running Serializing an Integer | |||
with input_date (Section 4.1.4). | with input_date (Section 4.1.4). | |||
3. Return output. | 3. Return output. | |||
4.1.11. Serializing a Display String | 4.1.11. Serializing a Display String | |||
Given a sequence of Unicode codepoints as input_sequence, return an | Given a sequence of Unicode code points as input_sequence, return an | |||
ASCII string suitable for use in an HTTP field value. | ASCII string suitable for use in an HTTP field value. | |||
1. If input_sequence is not a sequence of Unicode codepoints, fail | 1. If input_sequence is not a sequence of Unicode code points, fail | |||
serialization. | serialization. | |||
2. Let byte_array be the result of applying UTF-8 encoding | 2. Let byte_array be the result of applying UTF-8 encoding | |||
(Section 3 of [UTF8]) to input_sequence. If encoding fails, fail | (Section 3 of [UTF8]) to input_sequence. If encoding fails, fail | |||
serialization. | serialization. | |||
3. Let encoded_string be a string containing "%" followed by DQUOTE. | 3. Let encoded_string be a string containing "%" followed by DQUOTE. | |||
4. For each byte in byte_array: | 4. For each byte in byte_array: | |||
skipping to change at page 24, line 44 ¶ | skipping to change at line 1117 ¶ | |||
3. Append encoded_byte to encoded_string. | 3. Append encoded_byte to encoded_string. | |||
2. Otherwise, decode byte as an ASCII character and append the | 2. Otherwise, decode byte as an ASCII character and append the | |||
result to encoded_string. | result to encoded_string. | |||
5. Append DQUOTE to encoded_string. | 5. Append DQUOTE to encoded_string. | |||
6. Return encoded_string. | 6. Return encoded_string. | |||
Note that [UTF8] prohibits the encoding of codepoints between U+D800 | Note that [UTF8] prohibits the encoding of code points between U+D800 | |||
and U+DFFF (surrogates); if they occur in input_sequence, | and U+DFFF (surrogates); if they occur in input_sequence, | |||
serialization will fail. | serialization will fail. | |||
4.2. Parsing Structured Fields | 4.2. Parsing Structured Fields | |||
When a receiving implementation parses HTTP fields that are known to | When a receiving implementation parses HTTP fields that are known to | |||
be Structured Fields, it is important that care be taken, as there | be Structured Fields, it is important that care be taken, as there | |||
are a number of edge cases that can cause interoperability or even | are a number of edge cases that can cause interoperability or even | |||
security problems. This section specifies the algorithm for doing | security problems. This section specifies the algorithm for doing | |||
so. | so. | |||
skipping to change at page 35, line 50 ¶ | skipping to change at line 1642 ¶ | |||
3. Let output_date be the result of running Parsing an Integer or | 3. Let output_date be the result of running Parsing an Integer or | |||
Decimal (Section 4.2.4) with input_string. | Decimal (Section 4.2.4) with input_string. | |||
4. If output_date is a Decimal, fail parsing. | 4. If output_date is a Decimal, fail parsing. | |||
5. Return output_date. | 5. Return output_date. | |||
4.2.10. Parsing a Display String | 4.2.10. Parsing a Display String | |||
Given an ASCII string as input_string, return a sequence of Unicode | Given an ASCII string as input_string, return a sequence of Unicode | |||
codepoints. input_string is modified to remove the parsed value. | code points. input_string is modified to remove the parsed value. | |||
1. If the first two characters of input_string are not "%" followed | 1. If the first two characters of input_string are not "%" followed | |||
by DQUOTE, fail parsing. | by DQUOTE, fail parsing. | |||
2. Discard the first two characters of input_string. | 2. Discard the first two characters of input_string. | |||
3. Let byte_array be an empty byte array. | 3. Let byte_array be an empty byte array. | |||
4. While input_string is not empty: | 4. While input_string is not empty: | |||
skipping to change at page 37, line 7 ¶ | skipping to change at line 1694 ¶ | |||
1. Let byte be the result of applying ASCII encoding to | 1. Let byte be the result of applying ASCII encoding to | |||
char. | char. | |||
2. Append byte to byte_array. | 2. Append byte to byte_array. | |||
5. Reached the end of input_string without finding a closing DQUOTE; | 5. Reached the end of input_string without finding a closing DQUOTE; | |||
fail parsing. | fail parsing. | |||
5. IANA Considerations | 5. IANA Considerations | |||
Please add the following note to the "Hypertext Transfer Protocol | IANA has added the following note to the "Hypertext Transfer Protocol | |||
(HTTP) Field Name Registry": | (HTTP) Field Name Registry": | |||
The "Structured Type" column indicates the type of the field (per | | The "Structured Type" column indicates the type of the field (per | |||
RFC nnnn), if any, and may be "Dictionary", "List" or "Item". | | RFC 9651), if any, and may be "Dictionary", "List", or "Item". | |||
| | ||||
Note that field names beginning with characters other than ALPHA | | Note that field names beginning with characters other than ALPHA | |||
or "*" will not be able to be represented as a Structured Fields | | or "*" will not be able to be represented as a Structured Fields | |||
Token, and therefore may be incompatible with being mapped into | | Token and therefore may be incompatible with being mapped into | |||
field values that refer to it. | | field values that refer to it. | |||
Then, add a new column, "Structured Type". | A new column, "Structured Type", has been added to the registry. | |||
Then, add the indicated Structured Type for each existing registry | The indicated Structured Type for each existing registry entry listed | |||
entry listed in Table 1. | in Table 1 has also been added. | |||
+==========================================+=================+ | +==========================================+=================+ | |||
| Field Name | Structured Type | | | Field Name | Structured Type | | |||
+==========================================+=================+ | +==========================================+=================+ | |||
| Accept-CH | List | | | Accept-CH | List | | |||
+------------------------------------------+-----------------+ | +------------------------------------------+-----------------+ | |||
| Cache-Status | List | | | Cache-Status | List | | |||
+------------------------------------------+-----------------+ | +------------------------------------------+-----------------+ | |||
| CDN-Cache-Control | Dictionary | | | CDN-Cache-Control | Dictionary | | |||
+------------------------------------------+-----------------+ | +------------------------------------------+-----------------+ | |||
skipping to change at page 38, line 32 ¶ | skipping to change at line 1763 ¶ | |||
such as filtering or escaping untrusted content before displaying it. | such as filtering or escaping untrusted content before displaying it. | |||
See [PRECIS] and [UNICODE-SECURITY]. | See [PRECIS] and [UNICODE-SECURITY]. | |||
7. References | 7. References | |||
7.1. Normative References | 7.1. Normative References | |||
[HTTP] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, | [HTTP] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, | |||
Ed., "HTTP Semantics", STD 97, RFC 9110, | Ed., "HTTP Semantics", STD 97, RFC 9110, | |||
DOI 10.17487/RFC9110, June 2022, | DOI 10.17487/RFC9110, June 2022, | |||
<https://www.rfc-editor.org/rfc/rfc9110>. | <https://www.rfc-editor.org/info/rfc9110>. | |||
[RFC0020] Cerf, V., "ASCII format for network interchange", STD 80, | [RFC0020] Cerf, V., "ASCII format for network interchange", STD 80, | |||
RFC 20, DOI 10.17487/RFC0020, October 1969, | RFC 20, DOI 10.17487/RFC0020, October 1969, | |||
<https://www.rfc-editor.org/rfc/rfc20>. | <https://www.rfc-editor.org/info/rfc20>. | |||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
Requirement Levels", BCP 14, RFC 2119, | Requirement Levels", BCP 14, RFC 2119, | |||
DOI 10.17487/RFC2119, March 1997, | DOI 10.17487/RFC2119, March 1997, | |||
<https://www.rfc-editor.org/rfc/rfc2119>. | <https://www.rfc-editor.org/info/rfc2119>. | |||
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data | [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data | |||
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, | Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, | |||
<https://www.rfc-editor.org/rfc/rfc4648>. | <https://www.rfc-editor.org/info/rfc4648>. | |||
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | |||
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | |||
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>. | May 2017, <https://www.rfc-editor.org/info/rfc8174>. | |||
[UTF8] Yergeau, F., "UTF-8, a transformation format of ISO | [UTF8] Yergeau, F., "UTF-8, a transformation format of ISO | |||
10646", STD 63, RFC 3629, November 2003, | 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November | |||
<http://www.rfc-editor.org/info/std63>. | 2003, <https://www.rfc-editor.org/info/rfc3629>. | |||
7.2. Informative References | 7.2. Informative References | |||
[HPACK] Peon, R. and H. Ruellan, "HPACK: Header Compression for | [HPACK] Peon, R. and H. Ruellan, "HPACK: Header Compression for | |||
HTTP/2", RFC 7541, DOI 10.17487/RFC7541, May 2015, | HTTP/2", RFC 7541, DOI 10.17487/RFC7541, May 2015, | |||
<https://www.rfc-editor.org/rfc/rfc7541>. | <https://www.rfc-editor.org/info/rfc7541>. | |||
[HTTP/2] Thomson, M., Ed. and C. Benfield, Ed., "HTTP/2", RFC 9113, | [HTTP/2] Thomson, M., Ed. and C. Benfield, Ed., "HTTP/2", RFC 9113, | |||
DOI 10.17487/RFC9113, June 2022, | DOI 10.17487/RFC9113, June 2022, | |||
<https://www.rfc-editor.org/rfc/rfc9113>. | <https://www.rfc-editor.org/info/rfc9113>. | |||
[IEEE754] IEEE, "IEEE Standard for Floating-Point Arithmetic", | [IEEE754] IEEE, "IEEE Standard for Floating-Point Arithmetic", IEEE | |||
IEEE 754-2019, DOI 10.1109/IEEESTD.2019.8766229, | Std 754-2019, DOI 10.1109/IEEESTD.2019.8766229, | |||
ISBN 978-1-5044-5924-2, July 2019, | ISBN 978-1-5044-5924-2, July 2019, | |||
<https://ieeexplore.ieee.org/document/8766229>. | <https://ieeexplore.ieee.org/document/8766229>. | |||
[PRECIS] Saint-Andre, P. and M. Blanchet, "PRECIS Framework: | [PRECIS] Saint-Andre, P. and M. Blanchet, "PRECIS Framework: | |||
Preparation, Enforcement, and Comparison of | Preparation, Enforcement, and Comparison of | |||
Internationalized Strings in Application Protocols", | Internationalized Strings in Application Protocols", | |||
RFC 8264, DOI 10.17487/RFC8264, October 2017, | RFC 8264, DOI 10.17487/RFC8264, October 2017, | |||
<https://www.rfc-editor.org/rfc/rfc8264>. | <https://www.rfc-editor.org/info/rfc8264>. | |||
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax | [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax | |||
Specifications: ABNF", STD 68, RFC 5234, | Specifications: ABNF", STD 68, RFC 5234, | |||
DOI 10.17487/RFC5234, January 2008, | DOI 10.17487/RFC5234, January 2008, | |||
<https://www.rfc-editor.org/rfc/rfc5234>. | <https://www.rfc-editor.org/info/rfc5234>. | |||
[RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493, | [RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493, | |||
DOI 10.17487/RFC7493, March 2015, | DOI 10.17487/RFC7493, March 2015, | |||
<https://www.rfc-editor.org/rfc/rfc7493>. | <https://www.rfc-editor.org/info/rfc7493>. | |||
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data | [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data | |||
Interchange Format", STD 90, RFC 8259, | Interchange Format", STD 90, RFC 8259, | |||
DOI 10.17487/RFC8259, December 2017, | DOI 10.17487/RFC8259, December 2017, | |||
<https://www.rfc-editor.org/rfc/rfc8259>. | <https://www.rfc-editor.org/info/rfc8259>. | |||
[UNICODE-SECURITY] | [UNICODE-SECURITY] | |||
Davis, M. and M. Suignard, "Unicode Security | Davis, M. and M. Suignard, "Unicode Security | |||
Considerations", Unicode Technical Report #16, 19 | Considerations", Unicode Technical Report #36, 19 | |||
September 2014, <http://www.unicode.org/reports/tr36/>. | September 2014, | |||
<https://www.unicode.org/reports/tr36/tr36-15.html>. | ||||
Latest version available at | ||||
<https://www.unicode.org/reports/tr36/>. | ||||
Appendix A. Frequently Asked Questions | Appendix A. Frequently Asked Questions | |||
A.1. Why Not JSON? | A.1. Why Not JSON? | |||
Earlier proposals for Structured Fields were based upon JSON | Earlier proposals for Structured Fields were based upon JSON | |||
[RFC8259]. However, constraining its use to make it suitable for | [RFC8259]. However, constraining its use to make it suitable for | |||
HTTP fields required senders and recipients to implement specific | HTTP fields required senders and recipients to implement specific | |||
additional handling. | additional handling. | |||
For example, JSON has specification issues around large numbers and | For example, JSON has specification issues around large numbers and | |||
objects with duplicate members. Although advice for avoiding these | objects with duplicate members. Although advice for avoiding these | |||
issues is available (e.g., [RFC7493]), it cannot be relied upon. | issues is available (e.g., [RFC7493]), it cannot be relied upon. | |||
skipping to change at page 41, line 29 ¶ | skipping to change at line 1904 ¶ | |||
round to allowed values. | round to allowed values. | |||
Implementations are allowed to limit the size of different | Implementations are allowed to limit the size of different | |||
structures, subject to the minimums defined for each type. When a | structures, subject to the minimums defined for each type. When a | |||
structure exceeds an implementation limit, that structure fails | structure exceeds an implementation limit, that structure fails | |||
parsing or serialization. | parsing or serialization. | |||
Appendix C. ABNF | Appendix C. ABNF | |||
This section uses the Augmented Backus-Naur Form (ABNF) notation | This section uses the Augmented Backus-Naur Form (ABNF) notation | |||
[RFC5234] to illustrate expected syntax of Structured Fields. | [RFC5234] to illustrate the expected syntax of Structured Fields. | |||
However, it cannot be used to validate their syntax, because it does | However, it cannot be used to validate their syntax because it does | |||
not capture all requirements. | not capture all requirements. | |||
This section is non-normative. If there is disagreement between the | This section is non-normative. If there is disagreement between the | |||
parsing algorithms and ABNF, the specified algorithms take | parsing algorithms and ABNF, the specified algorithms take | |||
precedence. | precedence. | |||
sf-list = list-member *( OWS "," OWS list-member ) | sf-list = list-member *( OWS "," OWS list-member ) | |||
list-member = sf-item / inner-list | list-member = sf-item / inner-list | |||
inner-list = "(" *SP [ sf-item *( 1*SP sf-item ) *SP ] ")" | inner-list = "(" *SP [ sf-item *( 1*SP sf-item ) *SP ] ")" | |||
skipping to change at page 42, line 48 ¶ | skipping to change at line 1955 ¶ | |||
base64 = *( ALPHA / DIGIT / "+" / "/" ) *"=" | base64 = *( ALPHA / DIGIT / "+" / "/" ) *"=" | |||
unescaped = %x20-21 / %x23-24 / %x26-5B / %x5D-7E | unescaped = %x20-21 / %x23-24 / %x26-5B / %x5D-7E | |||
bs-escaped = "\" ( DQUOTE / "\" ) | bs-escaped = "\" ( DQUOTE / "\" ) | |||
pct-encoded = "%" lc-hexdig lc-hexdig | pct-encoded = "%" lc-hexdig lc-hexdig | |||
lc-hexdig = DIGIT / %x61-66 ; 0-9, a-f | lc-hexdig = DIGIT / %x61-66 ; 0-9, a-f | |||
Appendix D. Changes from RFC 8941 | Appendix D. Changes from RFC 8941 | |||
This revision of the Structured Field Values for HTTP specification | This revision of the "Structured Field Values for HTTP" specification | |||
has made the following changes: | has made the following changes: | |||
* Added the Date structured type. (Section 3.3.7) | * Added the Date Structured Type. (Section 3.3.7) | |||
* Stopped encouraging use of ABNF in definitions of new structured | ||||
fields. (Section 2) | * Stopped encouraging use of ABNF in definitions of new Structured | |||
Fields. (Section 2) | ||||
* Moved ABNF to an informative appendix. (Appendix C) | * Moved ABNF to an informative appendix. (Appendix C) | |||
* Added a "Structured Type" column to the HTTP Field Name Registry. | * Added a "Structured Type" column to the "Hypertext Transfer | |||
(Section 5) | Protocol (HTTP) Field Name Registry". (Section 5) | |||
* Refined parse failure handling. (Section 4.2) | * Refined parse failure handling. (Section 4.2) | |||
* Added the Display String structured type. (Section 3.3.8) | * Added the Display String Structured Type. (Section 3.3.8) | |||
Acknowledgements | Acknowledgements | |||
Many thanks to Matthew Kerwin for his detailed feedback and careful | Many thanks to Matthew Kerwin for his detailed feedback and careful | |||
consideration during the development of this specification. | consideration during the development of this specification. | |||
Thanks also to Ian Clelland, Roy Fielding, Anne van Kesteren, Kazuho | Thanks also to Ian Clelland, Roy Fielding, Anne van Kesteren, Kazuho | |||
Oku, Evert Pot, Julian Reschke, Martin Thomson, Mike West, and | Oku, Evert Pot, Julian Reschke, Martin Thomson, Mike West, and | |||
Jeffrey Yasskin for their contributions. | Jeffrey Yasskin for their contributions. | |||
End of changes. 56 change blocks. | ||||
180 lines changed or deleted | 169 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. |