draft-ietf-httpbis-retrofit-04.txt   draft-ietf-httpbis-retrofit-latest.txt 
Network Working Group M. Nottingham Network Working Group M. Nottingham
Internet-Draft June 8, 2022 Internet-Draft June 22, 2022
Intended status: Standards Track Intended status: Standards Track
Expires: December 10, 2022 Expires: December 24, 2022
Retrofit Structured Fields for HTTP Retrofit Structured Fields for HTTP
draft-ietf-httpbis-retrofit-04 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 4 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 December 10, 2022. This Internet-Draft will expire on December 24, 2022.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2022 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
skipping to change at page 2, line 31 skipping to change at page 2, line 31
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 . . . . . . . . . . . . . . . . . . . . . . 3 2. Compatible Fields . . . . . . . . . . . . . . . . . . . . . . 3
3. Mapped Fields . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Mapped Fields . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. URLs . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. URLs . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2. Dates . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.2. Dates . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.3. ETags . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.3. ETags . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.4. Links . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.4. Links . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.5. Cookies . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.5. Cookies . . . . . . . . . . . . . . . . . . . . . . . . . 9
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
6. Normative References . . . . . . . . . . . . . . . . . . . . 11 6. Normative References . . . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 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 4, line 49 skipping to change at page 4, line 49
| CDN-Loop | List | | CDN-Loop | List |
| Clear-Site-Data | List | | Clear-Site-Data | List |
| Connection | List | | Connection | List |
| Content-Encoding | List | | Content-Encoding | List |
| Content-Language | List | | Content-Language | List |
| Content-Length | List | | Content-Length | List |
| Content-Type | Item | | Content-Type | Item |
| Cross-Origin-Resource-Policy | Item | | Cross-Origin-Resource-Policy | Item |
| Expect | Dictionary | | Expect | Dictionary |
| Expect-CT | Dictionary | | Expect-CT | Dictionary |
| Forwarded | Dictionary |
| Host | Item | | Host | Item |
| Keep-Alive | Dictionary | | Keep-Alive | Dictionary |
| Max-Forwards | Item | | Max-Forwards | Item |
| Origin | Item | | Origin | Item |
| Pragma | Dictionary | | Pragma | Dictionary |
| Prefer | Dictionary | | Prefer | Dictionary |
| Preference-Applied | Dictionary | | Preference-Applied | Dictionary |
| Retry-After | Item | | Retry-After | Item |
| Sec-WebSocket-Extensions | List | | Sec-WebSocket-Extensions | List |
| Sec-WebSocket-Protocol | List | | Sec-WebSocket-Protocol | List |
skipping to change at page 6, line 7 skipping to change at page 6, line 6
Strings only escape "\" and DQUOTE. Compatibility can be improved Strings only escape "\" and DQUOTE. Compatibility can be improved
by unescaping other characters before parsing. 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 parsed 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
digits; larger values will not be able to be represented in them. digits; larger values will not be able to be represented in them.
IPv6 Literals: Fields whose values contain IPv6 literal addresses IPv6 Literals: Fields whose values contain IPv6 literal addresses
(such as CDN-Loop, Host, and Origin) are not able to be (such as CDN-Loop, Host, and Origin) are not able to be
represented as Structured Fields Tokens, because the brackets used represented as Structured Fields Tokens, because the brackets used
to delimit them are not allowed in Tokens. to delimit them are not allowed in Tokens.
Empty Field Values: Empty and whitespace-only field values are Empty Field Values: Empty and whitespace-only field values are
skipping to change at page 7, line 28 skipping to change at page 7, line 28
+------------------+---------------------+ +------------------+---------------------+
| Field Name | Mapped Field Name | | Field Name | Mapped Field Name |
+------------------+---------------------+ +------------------+---------------------+
| Content-Location | SF-Content-Location | | Content-Location | SF-Content-Location |
| Location | SF-Location | | Location | SF-Location |
| Referer | SF-Referer | | Referer | SF-Referer |
+------------------+---------------------+ +------------------+---------------------+
Table 2: URL Fields Table 2: URL Fields
For example, a Location field could be mapped as: For example, this Location field
Location: https://example.com/foo
could be mapped as:
SF-Location: "https://example.com/foo" SF-Location: "https://example.com/foo"
3.2. Dates 3.2. Dates
The field names in Table 3 (paired with their mapped field names) The field names in Table 3 (paired with their mapped field names)
have values that can be mapped into Structured Fields by parsing have values that can be mapped into Structured Fields by parsing
their payload according to Section 5.6.7 of [HTTP] and representing their payload according to Section 5.6.7 of [HTTP] and representing
the result as an Integer number of seconds delta from the Unix Epoch the result as an Integer number of seconds delta from the Unix Epoch
(00:00:00 UTC on 1 January 1970, excluding leap seconds). (00:00:00 UTC on 1 January 1970, excluding leap seconds).
+---------------------+-------------------+ +---------------------+------------------------+
| Field Name | Mapped Field Name | | Field Name | Mapped Field Name |
+---------------------+-------------------+ +---------------------+------------------------+
| Date | SF-Date | | Date | SF-Date |
| Expires | SF-Expires | | Expires | SF-Expires |
| If-Modified-Since | SF-IMS | | If-Modified-Since | SF-If-Modified-Since |
| If-Unmodified-Since | SF-IUS | | If-Unmodified-Since | SF-If-Unmodified-Since |
| Last-Modified | SF-LM | | Last-Modified | SF-Last-Modified |
+---------------------+-------------------+ +---------------------+------------------------+
Table 3: Date Fields Table 3: Date Fields
For example, an Expires field could be mapped as: For example, an Expires field could be mapped as:
SF-Expires: 1571965240 SF-Expires: 1571965240
3.3. ETags 3.3. ETags
The field value of the ETag header field can be mapped into the SF- The field value of the ETag header field can be mapped into the SF-
ETag Structured Field by representing the entity-tag as a String, and ETag Structured Field by representing the entity-tag as a String, and
the weakness flag as a Boolean "w" parameter on it, where true the weakness flag as a Boolean "w" parameter on it, where true
indicates that the entity-tag is weak; if 0 or unset, the entity-tag indicates that the entity-tag is weak; if 0 or unset, the entity-tag
is strong. is strong.
For example: For example, this:
SF-ETag: "abcdef"; w=?1 ETag: W/"abcdef"
If-None-Match's field value can be mapped into the SF-INM Structured SF-ETag: "abcdef"; w
Field, which is a List of the structure described above.
If-None-Match's field value can be mapped into the SF-If-None-Match
Structured Field, which is a List of the structure described above.
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
Structured Field in the same manner.
For example: For example:
SF-INM: "abcdef"; w=?1, "ghijkl" SF-If-None-Match: "abcdef"; w, "ghijkl", *
3.4. Links 3.4. Links
The field value of the Link header field [RFC8288] can be mapped into 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 the SF-Link List Structured Field by considering the URI-Reference as
a String, and link-param as Parameters. a String, and link-param as Parameters.
For example: For example, this:
Link: </terms>; rel="copyright"; anchor="#foo"
can be mapped to:
SF-Link: "/terms"; rel="copyright"; anchor="#foo" SF-Link: "/terms"; rel="copyright"; anchor="#foo"
3.5. Cookies 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 Dictionary), respectively. Structured Field (a List), respectively.
In each case, cookie names are Tokens. Their values are Strings, In each case, a cookie is represented as an Inner List containing two
unless the value can be successfully parsed as the textual Items; the cookie name and value. The cookie name is always a
representation of another, bare Item structured type (e.g., Byte String; the cookie value is a String, unless it can be successfully
Sequence, Decimal, Integer, Token, or Boolean). parsed as the textual representation of another, bare Item structured
type (e.g., Byte Sequence, Decimal, Integer, Token, or Boolean).
Set-Cookie parameters map to Parameters on the appropriate SF-Set- Cookie attributes map to Parameters on the Inner List, with the
Cookie member, with the parameter name being forced to lowercase. parameter name being forced to lowercase. Cookie attribute values
Set-Cookie parameter values are Strings unless a specific type is are Strings unless a specific type is defined for them. This
defined for them. This specification defines the parameter types in specification defines types for existing cookie attributes in
Table 4. Table 4.
+----------------+-----------------+ +----------------+-----------------+
| Parameter Name | Structured Type | | Parameter Name | Structured Type |
+----------------+-----------------+ +----------------+-----------------+
| Domain | String |
| HttpOnly | Boolean | | HttpOnly | Boolean |
| Expires | Integer | | Expires | Integer |
| Max-Age | Integer | | Max-Age | Integer |
| Path | String |
| Secure | Boolean | | Secure | Boolean |
| SameSite | Token | | SameSite | Token |
+----------------+-----------------+ +----------------+-----------------+
Table 4: Set-Cookie Parameter Types Table 4: Set-Cookie Parameter Types
Expires is mapped to an Integer representation of parsed-cookie-date The Expires attribute is mapped to an Integer representation of
(see Section x.x of [COOKIES]) expressed as a number of seconds delta parsed-cookie-date (see Section 5.1.1 of [COOKIES]) expressed as a
from the Unix Epoch (00:00:00 UTC on 1 January 1970, excluding leap number of seconds delta from the Unix Epoch (00:00:00 UTC on 1
seconds). January 1970, excluding leap seconds).
Note that although this mapping is very similar to the syntax of For example, these unstructured fields:
Cookie and Set-Cookie headers, cookies in both fields are separated
by commas, not semicolons, and multiple cookies can appear in each
field.
For example: Set-Cookie: lang=en-US; Expires=Wed, 09 Jun 2021 10:18:14 GMT;
samesite=Strict; secure
Cookie: SID=31d4d96e407aad42; lang=en-US
can be mapped into:
SF-Set-Cookie: lang="en-US"; expires="Wed, 09 Jun 2021 10:18:14 GMT"; SF-Set-Cookie: ("lang" "en-US"); expires=1623233894;
samesite=Strict; secure=?1 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 The "Structured Type" column indicates the type of the field (per
RFC8941), if any, and may be "Dictionary", "List" or "Item". A RFC8941), if any, and may be "Dictionary", "List" or "Item". A
prefix of "*" indicates that it is a retrofit type (i.e., not prefix of "*" indicates that it is a retrofit type (i.e., not
natively Structured); see [this specification]. natively Structured); see [this specification].
skipping to change at page 10, line 13 skipping to change at page 11, line 5
fields that refer to it; see [this specification]. 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.
+---------------------+-----------------+ +------------------------+-----------------+
| Field Name | Structured Type | | Field Name | Structured Type |
+---------------------+-----------------+ +------------------------+-----------------+
| SF-Content-Location | String | | 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-IMS | Item | | SF-If-Match | List |
| SF-INM | List | | SF-If-Modified-Since | Item |
| SF-IUS | Item | | SF-If-None-Match | List |
| SF-Link | List | | SF-If-Unmodified-Since | Item |
| SF-LM | Item | | SF-Link | List |
| SF-Location | String | | SF-Last-Modified | Item |
| SF-Referer | String | | SF-Location | Item |
| SF-Set-Cookie | Dictionary | | SF-Referer | Item |
+---------------------+-----------------+ | SF-Set-Cookie | List |
+------------------------+-----------------+
Table 5: New Fields Table 5: New Fields
Finally, add the indicated Structured Type for each existing registry Then, add the indicated Structured Type for each existing registry
entry listed in Table 6. entry listed in Table 6.
+------------------------------------------+-----------------+ +------------------------------------------+-----------------+
| 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 |
| Cross-Origin-Embedder-Policy | Item | | Cross-Origin-Embedder-Policy | Item |
| Cross-Origin-Embedder-Policy-Report-Only | Item | | Cross-Origin-Embedder-Policy-Report-Only | Item |
| Cross-Origin-Opener-Policy | Item | | Cross-Origin-Opener-Policy | Item |
| Cross-Origin-Opener-Policy-Report-Only | Item | | Cross-Origin-Opener-Policy-Report-Only | Item |
| Origin-Agent-Cluster | Item | | Origin-Agent-Cluster | Item |
| Priority | Dictionary | | Priority | Dictionary |
| Proxy-Status | List | | Proxy-Status | List |
+------------------------------------------+-----------------+ +------------------------------------------+-----------------+
Table 6: Existing Fields Table 6: Existing Fields
Finally, add a new column to the "Cookie Attribute Registry"
established by [COOKIES] with the title "Structured Type", using
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
in a chain (e.g., an intermediary). However, given the considerable in a chain (e.g., an intermediary). However, given the considerable
variance in parsers already deployed, convergence towards a single variance in parsers already deployed, convergence towards a single
parsing algorithm is likely to have a net security benefit in the parsing algorithm is likely to have a net security benefit in the
longer term. longer term.
skipping to change at page 11, line 30 skipping to change at page 12, line 30
they have negotiated support for them with their peer. This they have negotiated support for them with their peer. This
specification does not define such a mechanism, but any such specification does not define such a mechanism, but any such
definition needs to consider the implications of doing so carefully. definition needs to consider the implications of doing so carefully.
6. Normative References 6. Normative References
[COOKIES] Chen, L., Englehardt, S., West, M., and J. Wilander, [COOKIES] Chen, L., Englehardt, S., West, M., and J. Wilander,
"Cookies: HTTP State Management Mechanism", draft-ietf- "Cookies: HTTP State Management Mechanism", draft-ietf-
httpbis-rfc6265bis-10 (work in progress), April 2022. httpbis-rfc6265bis-10 (work in progress), April 2022.
[HTTP] Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP [HTTP] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Semantics", draft-ietf-httpbis-semantics-19 (work in Ed., "HTTP Semantics", STD 97, RFC 9110,
progress), September 2021. DOI 10.17487/RFC9110, June 2022,
<https://www.rfc-editor.org/info/rfc9110>.
[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>.
 End of changes. 27 change blocks. 
69 lines changed or deleted 91 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/