draft-ietf-httpbis-retrofit-05.txt | draft-ietf-httpbis-retrofit-latest.txt | |||
---|---|---|---|---|
Network Working Group M. Nottingham | HTTP Working Group M. Nottingham | |||
Internet-Draft December 4, 2022 | Internet-Draft February 9, 2023 | |||
Updates: 8941 (if approved) | ||||
Intended status: Standards Track | Intended status: Standards Track | |||
Expires: June 7, 2023 | Expires: August 13, 2023 | |||
Retrofit Structured Fields for HTTP | Retrofit Structured Fields for HTTP | |||
draft-ietf-httpbis-retrofit-05 | draft-ietf-httpbis-retrofit-latest | |||
Abstract | Abstract | |||
This specification nominates a selection of existing HTTP fields as | This specification nominates a selection of existing HTTP fields as | |||
having syntax that is compatible with Structured Fields, so that they | having syntax that is compatible with Structured Fields, so that they | |||
can be handled as such (subject to certain caveats). | can be handled as such (subject to certain caveats). | |||
To accommodate some additional fields whose syntax is not compatible, | To accommodate some additional fields whose syntax is not compatible, | |||
it also defines mappings of their semantics into new Structured | it also defines mappings of their semantics into new Structured | |||
Fields. It does not specify how to negotiate their use. | Fields. It does not specify how to negotiate their use. | |||
skipping to change at page 2, line 6 ¶ | skipping to change at page 2, line 4 ¶ | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts is at https://datatracker.ietf.org/drafts/current/. | Drafts is at https://datatracker.ietf.org/drafts/current/. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
This Internet-Draft will expire on August 13, 2023. | ||||
This Internet-Draft will expire on June 7, 2023. | ||||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2022 IETF Trust and the persons identified as the | Copyright (c) 2023 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 | Provisions Relating to IETF Documents | |||
(https://trustee.ietf.org/license-info) in effect on the date of | (https://trustee.ietf.org/license-info) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
carefully, as they describe your rights and restrictions with respect | carefully, as they describe your rights and restrictions with respect | |||
to this document. Code Components extracted from this document must | to this document. Code Components extracted from this document must | |||
include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||
the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||
described in the Simplified BSD License. | described in the Simplified BSD License. | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | |||
1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3 | 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3 | |||
2. Compatible Fields . . . . . . . . . . . . . . . . . . . . . . 4 | 2. Compatible Fields . . . . . . . . . . . . . . . . . . . . . . 3 | |||
3. Mapped Fields . . . . . . . . . . . . . . . . . . . . . . . . 7 | 3. Mapped Fields . . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
3.1. URLs . . . . . . . . . . . . . . . . . . . . . . . . . . 7 | 3.1. URLs . . . . . . . . . . . . . . . . . . . . . . . . . . 7 | |||
3.2. Dates . . . . . . . . . . . . . . . . . . . . . . . . . . 8 | 3.2. Dates . . . . . . . . . . . . . . . . . . . . . . . . . . 7 | |||
3.3. ETags . . . . . . . . . . . . . . . . . . . . . . . . . . 8 | 3.3. ETags . . . . . . . . . . . . . . . . . . . . . . . . . . 8 | |||
3.4. Links . . . . . . . . . . . . . . . . . . . . . . . . . . 9 | 3.4. Cookies . . . . . . . . . . . . . . . . . . . . . . . . . 8 | |||
3.5. Cookies . . . . . . . . . . . . . . . . . . . . . . . . . 9 | 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 | |||
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 | 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 | |||
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 | 6. Normative References . . . . . . . . . . . . . . . . . . . . 11 | |||
6. Normative References . . . . . . . . . . . . . . . . . . . . 12 | Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 | |||
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 | ||||
1. Introduction | 1. Introduction | |||
Structured Field Values for HTTP [STRUCTURED-FIELDS] introduced a | Structured Field Values for HTTP [STRUCTURED-FIELDS] introduced a | |||
data model with associated parsing and serialization algorithms for | data model with associated parsing and serialization algorithms for | |||
use by new HTTP field values. Fields that are defined as Structured | use by new HTTP field values. Fields that are defined as Structured | |||
Fields can realise a number of benefits, including: | Fields can realise a number of benefits, including: | |||
o Improved interoperability and security: precisely defined parsing | o Improved interoperability and security: precisely defined parsing | |||
and serialisation algorithms are typically not available for | and serialisation algorithms are typically not available for | |||
skipping to change at page 5, line 36 ¶ | skipping to change at page 5, line 29 ¶ | |||
| Vary | List | | | Vary | List | | |||
| X-Content-Type-Options | Item | | | X-Content-Type-Options | Item | | |||
| X-Frame-Options | Item | | | X-Frame-Options | Item | | |||
| X-XSS-Protection | List | | | X-XSS-Protection | List | | |||
+----------------------------------+-----------------+ | +----------------------------------+-----------------+ | |||
Table 1: Compatible Fields | Table 1: Compatible Fields | |||
Note the following caveats regarding compatibility: | Note the following caveats regarding compatibility: | |||
Parsing differences: Some values may fail to parse as Structured | ||||
Fields, even though they are valid according to their originally | ||||
specified syntax. For example, HTTP parameter names are case- | ||||
insensitive (per Section 5.6.6 of [HTTP]), but Structured Fields | ||||
require them to be all-lowercase. Likewise, many Dictionary-based | ||||
fields (e.g., Cache-Control, Expect-CT, Pragma, Prefer, | ||||
Preference-Applied, Surrogate-Control) have case-insensitive keys. | ||||
Similarly, the parameters rule in HTTP (see Section 5.6.6 of | ||||
[HTTP]) allows whitespace before the ";" delimiter, but Structured | ||||
Fields does not. And, Section 5.6.4 of [HTTP] allows backslash- | ||||
escaping most characters in quoted strings, whereas Structured | ||||
Field Strings only escape "\" and DQUOTE. The vast majority of | ||||
fields seen in typical traffic do not exhibit these behaviors. | ||||
Error handling: Parsing algorithms specified (or just widely | Error handling: Parsing algorithms specified (or just widely | |||
implemented) for current HTTP headers may differ from those in | implemented) for current HTTP headers may differ from those in | |||
Structured Fields in details such as error handling. For example, | Structured Fields in details such as error handling. For example, | |||
HTTP specifies that repeated directives in the Cache-Control | HTTP specifies that repeated directives in the Cache-Control | |||
header field have a different precedence than that assigned by a | header field have a different precedence than that assigned by a | |||
Dictionary structured field (which Cache-Control is mapped to). | Dictionary structured field (which Cache-Control is mapped to). | |||
Parameter and Dictionary keys: HTTP parameter names are case- | ||||
insensitive (per Section 5.6.6 of [HTTP]), but Structured Fields | ||||
require them to be all-lowercase. Although the vast majority of | ||||
parameters seen in typical traffic are all-lowercase, | ||||
compatibility can be improved by force-lowercasing parameters when | ||||
parsing. Likewise, many Dictionary-based fields (e.g., Cache- | ||||
Control, Expect-CT, Pragma, Prefer, Preference-Applied, Surrogate- | ||||
Control) have case-insensitive keys, and compatibility can be | ||||
improved by force-lowercasing them when parsing. | ||||
Parameter delimitation: The parameters rule in HTTP (see | ||||
Section 5.6.6 of [HTTP]) allows whitespace before the ";" | ||||
delimiter, but Structured Fields does not. Compatibility can be | ||||
improved by allowing such whitespace when parsing. | ||||
String quoting: Section 5.6.4 of [HTTP] allows backslash-escaping | ||||
most characters in quoted strings, whereas Structured Field | ||||
Strings only escape "\" and DQUOTE. Compatibility can be improved | ||||
by unescaping other characters before parsing. | ||||
Token limitations: In Structured Fields, tokens are required to | Token limitations: In Structured Fields, tokens are required to | |||
begin with an alphabetic character or "*", whereas HTTP tokens | begin with an alphabetic character or "*", whereas HTTP tokens | |||
allow a wider range of characters. This prevents use of mapped | allow a wider range of characters. This prevents use of mapped | |||
values that begin with one of these characters. For example, | values that begin with one of these characters. For example, | |||
media types, field names, methods, range-units, character and | media types, field names, methods, range-units, character and | |||
transfer codings that begin with a number or special character | transfer codings that begin with a number or special character | |||
other than "*" might be valid HTTP protocol elements, but will not | other than "*" might be valid HTTP protocol elements, but will not | |||
be able to be represented as Structured Field Tokens. | be able to be represented as Structured Field Tokens. | |||
Integer limitations: Structured Fields Integers can have at most 15 | Integer limitations: Structured Fields Integers can have at most 15 | |||
skipping to change at page 9, line 5 ¶ | skipping to change at page 8, line 46 ¶ | |||
Structured Field, which is a List of the structure described above. | Structured Field, which is a List of the structure described above. | |||
When a field value contains "*", it is represented as a Token. | When a field value contains "*", it is represented as a Token. | |||
Likewise, If-Match's field value can be mapped into the SF-If-Match | Likewise, If-Match's field value can be mapped into the SF-If-Match | |||
Structured Field in the same manner. | Structured Field in the same manner. | |||
For example: | For example: | |||
SF-If-None-Match: "abcdef"; w, "ghijkl", * | SF-If-None-Match: "abcdef"; w, "ghijkl", * | |||
3.4. Links | 3.4. Cookies | |||
The field value of the Link header field [RFC8288] can be mapped into | ||||
the SF-Link List Structured Field by considering the URI-Reference as | ||||
a String, and link-param as Parameters. | ||||
For example, this: | ||||
Link: </terms>; rel="copyright"; anchor="#foo" | ||||
can be mapped to: | ||||
SF-Link: "/terms"; rel="copyright"; anchor="#foo" | ||||
3.5. Cookies | ||||
The field values of the Cookie and Set-Cookie fields [COOKIES] can be | The field values of the Cookie and Set-Cookie fields [COOKIES] can be | |||
mapped into the SF-Cookie Structured Field (a List) and SF-Set-Cookie | mapped into the SF-Cookie Structured Field (a List) and SF-Set-Cookie | |||
Structured Field (a List), respectively. | Structured Field (a List), respectively. | |||
In each case, a cookie is represented as an Inner List containing two | In each case, a cookie is represented as an Inner List containing two | |||
Items; the cookie name and value. The cookie name is always a | Items; the cookie name and value. The cookie name is always a | |||
String; the cookie value is a String, unless it can be successfully | String; the cookie value is a String, unless it can be successfully | |||
parsed as the textual representation of another, bare Item structured | parsed as the textual representation of another, bare Item structured | |||
type (e.g., Byte Sequence, Decimal, Integer, Token, or Boolean). | type (e.g., Byte Sequence, Decimal, Integer, Token, or Boolean). | |||
skipping to change at page 10, line 22 ¶ | skipping to change at page 9, line 51 ¶ | |||
SF-Set-Cookie: ("lang" "en-US"); expires=@1623233894; | SF-Set-Cookie: ("lang" "en-US"); expires=@1623233894; | |||
samesite=Strict; secure | samesite=Strict; secure | |||
SF-Cookie: ("SID" "31d4d96e407aad42"), ("lang" "en-US") | SF-Cookie: ("SID" "31d4d96e407aad42"), ("lang" "en-US") | |||
4. IANA Considerations | 4. IANA Considerations | |||
Please add the following note to the "Hypertext Transfer Protocol | Please add 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 | A prefix of "*" in the Structured Type column indicates that it is | |||
RFC8941), if any, and may be "Dictionary", "List" or "Item". A | a retrofit type (i.e., not natively Structured); see RFC nnnn. | |||
prefix of "*" indicates that it is a retrofit type (i.e., not | ||||
natively Structured); see [this specification]. | ||||
Note that field names beginning with characters other than ALPHA | ||||
or "*" will not be able to be represented as a Structured Fields | ||||
Token, and therefore may be incompatible with being mapped into | ||||
fields that refer to it; see [this specification]. | ||||
Then, add a new column, "Structured Type", with the values from | Then, add a new column, "Structured Type", with the values from | |||
Section 2 assigned to the nominated registrations, prefixing each | Section 2 assigned to the nominated registrations, prefixing each | |||
with "*" to indicate that it is a retrofit type. | with "*" to indicate that it is a retrofit type. | |||
Then, add the field names in Table 5, with the corresponding | Then, add the field names in Table 5, with the corresponding | |||
Structured Type as indicated, a status of "permanent" and referring | Structured Type as indicated, a status of "permanent" and referring | |||
to this document. | to this document. | |||
+------------------------+-----------------+ | +------------------------+-----------------+ | |||
skipping to change at page 11, line 17 ¶ | skipping to change at page 10, line 25 ¶ | |||
+------------------------+-----------------+ | +------------------------+-----------------+ | |||
| SF-Content-Location | Item | | | SF-Content-Location | Item | | |||
| SF-Cookie | List | | | SF-Cookie | List | | |||
| SF-Date | Item | | | SF-Date | Item | | |||
| SF-ETag | Item | | | SF-ETag | Item | | |||
| SF-Expires | Item | | | SF-Expires | Item | | |||
| SF-If-Match | List | | | SF-If-Match | List | | |||
| SF-If-Modified-Since | Item | | | SF-If-Modified-Since | Item | | |||
| SF-If-None-Match | List | | | SF-If-None-Match | List | | |||
| SF-If-Unmodified-Since | Item | | | SF-If-Unmodified-Since | Item | | |||
| SF-Link | List | | ||||
| SF-Last-Modified | Item | | | SF-Last-Modified | Item | | |||
| SF-Location | Item | | | SF-Location | Item | | |||
| SF-Referer | Item | | | SF-Referer | Item | | |||
| SF-Set-Cookie | List | | | SF-Set-Cookie | List | | |||
+------------------------+-----------------+ | +------------------------+-----------------+ | |||
Table 5: New Fields | Table 5: New Fields | |||
Then, add the indicated Structured Type for each existing registry | ||||
entry listed in Table 6. | ||||
+------------------------------------------+-----------------+ | ||||
| Field Name | Structured Type | | ||||
+------------------------------------------+-----------------+ | ||||
| Accept-CH | List | | ||||
| Cache-Status | List | | ||||
| CDN-Cache-Control | Dictionary | | ||||
| Cross-Origin-Embedder-Policy | Item | | ||||
| Cross-Origin-Embedder-Policy-Report-Only | Item | | ||||
| Cross-Origin-Opener-Policy | Item | | ||||
| Cross-Origin-Opener-Policy-Report-Only | Item | | ||||
| Origin-Agent-Cluster | Item | | ||||
| Priority | Dictionary | | ||||
| Proxy-Status | List | | ||||
+------------------------------------------+-----------------+ | ||||
Table 6: Existing Fields | ||||
Finally, add a new column to the "Cookie Attribute Registry" | Finally, add a new column to the "Cookie Attribute Registry" | |||
established by [COOKIES] with the title "Structured Type", using | established by [COOKIES] with the title "Structured Type", using | |||
information from Table 4. | information from Table 4. | |||
5. Security Considerations | 5. Security Considerations | |||
Section 2 identifies existing HTTP fields that can be parsed and | Section 2 identifies existing HTTP fields that can be parsed and | |||
serialised with the algorithms defined in [STRUCTURED-FIELDS]. | serialised with the algorithms defined in [STRUCTURED-FIELDS]. | |||
Variances from existing parser behavior might be exploitable, | Variances from existing parser behavior might be exploitable, | |||
particularly if they allow an attacker to target one implementation | particularly if they allow an attacker to target one implementation | |||
skipping to change at page 12, line 44 ¶ | skipping to change at page 11, line 27 ¶ | |||
[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/info/rfc2119>. | <https://www.rfc-editor.org/info/rfc2119>. | |||
[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/info/rfc8174>. | May 2017, <https://www.rfc-editor.org/info/rfc8174>. | |||
[RFC8288] Nottingham, M., "Web Linking", RFC 8288, | ||||
DOI 10.17487/RFC8288, October 2017, | ||||
<https://www.rfc-editor.org/info/rfc8288>. | ||||
[STRUCTURED-FIELDS] | [STRUCTURED-FIELDS] | |||
Nottingham, M. and P. Kamp, "Structured Field Values for | Nottingham, M. and P. Kamp, "Structured Field Values for | |||
HTTP", draft-ietf-httpbis-sfbis-00 (work in progress), | HTTP", draft-ietf-httpbis-sfbis-01 (work in progress), | |||
November 2022. | December 2022. | |||
Author's Address | Author's Address | |||
Mark Nottingham | Mark Nottingham | |||
Prahran | Prahran | |||
Australia | Australia | |||
Email: mnot@mnot.net | Email: mnot@mnot.net | |||
URI: https://www.mnot.net/ | URI: https://www.mnot.net/ | |||
End of changes. 16 change blocks. | ||||
88 lines changed or deleted | 33 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |