draft-ietf-httpbis-retrofit-06.txt | draft-ietf-httpbis-retrofit-latest.txt | |||
---|---|---|---|---|
HTTP Working Group M. Nottingham | HTTP Working Group M. Nottingham | |||
Internet-Draft March 31, 2023 | Internet-Draft August 22, 2024 | |||
Intended status: Standards Track | Intended status: Standards Track | |||
Expires: October 2, 2023 | Expires: February 23, 2025 | |||
Retrofit Structured Fields for HTTP | Retrofit Structured Fields for HTTP | |||
draft-ietf-httpbis-retrofit-06 | 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 | |||
having syntax that is compatible with Structured Fields, so that they | whose values are compatible with Structured Fields syntax, so that | |||
can be handled as such (subject to certain caveats). | they 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 Structured Fields. | |||
Fields. It does not specify how to negotiate their use. | It does not specify how to convey them in HTTP messages. | |||
About This Document | About This Document | |||
This note is to be removed before publishing as an RFC. | This note is to be removed before publishing as an RFC. | |||
Status information for this document may be found at | Status information for this document may be found at | |||
<https://datatracker.ietf.org/doc/draft-ietf-httpbis-retrofit/>. | <https://datatracker.ietf.org/doc/draft-ietf-httpbis-retrofit/>. | |||
Discussion of this document takes place on the HTTP Working Group | Discussion of this document takes place on the HTTP Working Group | |||
mailing list (<mailto:ietf-http-wg@w3.org>), which is archived at | mailing list (<mailto:ietf-http-wg@w3.org>), which is archived at | |||
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 October 2, 2023. | This Internet-Draft will expire on February 23, 2025. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2023 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 | 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. Using Retrofit Structured Fields . . . . . . . . . . . . 3 | |||
2. Compatible Fields . . . . . . . . . . . . . . . . . . . . . . 3 | 1.2. Notational Conventions . . . . . . . . . . . . . . . . . 4 | |||
3. Mapped Fields . . . . . . . . . . . . . . . . . . . . . . . . 6 | 2. Compatible Fields . . . . . . . . . . . . . . . . . . . . . . 4 | |||
2.1. Caveats . . . . . . . . . . . . . . . . . . . . . . . . . 6 | ||||
3. Mapped Fields . . . . . . . . . . . . . . . . . . . . . . . . 7 | ||||
3.1. URLs . . . . . . . . . . . . . . . . . . . . . . . . . . 7 | 3.1. URLs . . . . . . . . . . . . . . . . . . . . . . . . . . 7 | |||
3.2. Dates . . . . . . . . . . . . . . . . . . . . . . . . . . 7 | 3.2. Dates . . . . . . . . . . . . . . . . . . . . . . . . . . 8 | |||
3.3. ETags . . . . . . . . . . . . . . . . . . . . . . . . . . 8 | 3.3. ETags . . . . . . . . . . . . . . . . . . . . . . . . . . 8 | |||
3.4. Cookies . . . . . . . . . . . . . . . . . . . . . . . . . 8 | 3.4. Cookies . . . . . . . . . . . . . . . . . . . . . . . . . 9 | |||
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 | 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 | |||
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 | 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 | |||
6. Normative References . . . . . . . . . . . . . . . . . . . . 11 | 6. Normative References . . . . . . . . . . . . . . . . . . . . 11 | |||
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 | Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 | |||
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 bring advantages that include: | |||
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 | |||
fields defined with just ABNF and/or prose. | fields defined with just ABNF and/or prose. | |||
o Reuse of common implementations: many parsers for other fields are | o Reuse of common implementations: many parsers for other fields are | |||
specific to a single field or a small family of fields. | specific to a single field or a small family of fields. | |||
o Canonical form: because a deterministic serialisation algorithm is | o Canonical form: because a deterministic serialisation algorithm is | |||
defined for each type, Structure Fields have a canonical | defined for each type, Structure Fields have a canonical | |||
skipping to change at page 3, line 32 ¶ | skipping to change at page 3, line 32 ¶ | |||
can be handled as Structured Fields, so that these benefits can be | can be handled as Structured Fields, so that these benefits can be | |||
realised -- thereby making them Retrofit Structured Fields. | realised -- thereby making them Retrofit Structured Fields. | |||
It does so using two techniques. Section 2 lists compatible fields | It does so using two techniques. Section 2 lists compatible fields | |||
-- those that can be handled as if they were Structured Fields due to | -- those that can be handled as if they were Structured Fields due to | |||
the similarity of their defined syntax to that in Structured Fields. | the similarity of their defined syntax to that in Structured Fields. | |||
Section 3 lists mapped fields -- those whose syntax needs to be | Section 3 lists mapped fields -- those whose syntax needs to be | |||
transformed into an underlying data model which is then mapped into | transformed into an underlying data model which is then mapped into | |||
that defined by Structured Fields. | that defined by Structured Fields. | |||
Note that while implementations can parse and serialise compatible | 1.1. Using Retrofit Structured Fields | |||
fields as Structured Fields subject to the caveats in Section 2, a | ||||
sender cannot generate mapped fields from Section 3 and expect them | ||||
to be understood and acted upon by the recipient without prior | ||||
negotiation. This specification does not define such a mechanism. | ||||
1.1. Notational Conventions | Retrofitting data structures onto existing and widely-deployed HTTP | |||
fields requires careful handling to assure interoperability and | ||||
security. This section highlights considerations for applications | ||||
that use Retrofit Structured Fields. | ||||
While the majority of field values seen in HTTP traffic should be | ||||
able to be parsed or mapped successfully, some will not. An | ||||
application using Retrofit Structured Fields will need to define how | ||||
unsuccessful values will be handled. | ||||
For example, an API that exposes field values using Structured Fields | ||||
data types might make the field value available as a string in cases | ||||
where the field did not successfully parse or map. | ||||
The mapped field values described in Section 3 are not compatible | ||||
with the original syntax of their fields, and so cannot be used | ||||
unless parties processing them have explicitly indicated their | ||||
support for that form of the field value. An application using | ||||
Retrofit Structured Fields will need to define how to negotiate | ||||
support for them. | ||||
For example, an alternative serialization of fields that takes | ||||
advantage of Structured Fields would need to establish an explicit | ||||
negotiation mechanism to assure that both peers would handle that | ||||
serialization appropriately before using it. | ||||
See also the security considerations in Section 5. | ||||
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 | "OPTIONAL" in this document are to be interpreted as described in | |||
BCP 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. | |||
2. Compatible Fields | 2. Compatible Fields | |||
The HTTP fields listed in Table 1 can usually have their values | The HTTP fields listed in Table 1 have values that can be handled as | |||
handled as Structured Fields according to the listed parsing and | Structured Field Values according to the parsing and serialisation | |||
serialisation algorithms in [STRUCTURED-FIELDS], subject to the | algorithms in [STRUCTURED-FIELDS] corresponding to the listed top- | |||
listed caveats. | level type, subject to the caveats in Section 2.1. | |||
The listed types are chosen for compatibility with the defined syntax | The top-level types are chosen for compatibility with the defined | |||
of the field as well as with actual internet traffic. However, not | syntax of the field as well as with actual internet traffic. | |||
all instances of these fields will successfully parse. This might be | However, not all instances of these fields will successfully parse as | |||
because the field value is clearly invalid, or it might be because it | a Structured Field Value. This might be because the field value is | |||
is valid but not parseable as a Structured Field. | clearly invalid, or it might be because it is valid but not parseable | |||
as a Structured Field. | ||||
An application using this specification will need to consider how to | An application using this specification will need to consider how to | |||
handle such field values. Depending on its requirements, it might be | handle such field values. Depending on its requirements, it might be | |||
advisable to reject such values, treat them as opaque strings, or | advisable to reject such values, treat them as opaque strings, or | |||
attempt to recover a structured value from them in an ad hoc fashion. | attempt to recover a Structured Field Value from them in an ad hoc | |||
fashion. | ||||
+----------------------------------+-----------------+ | +----------------------------------+-----------------+ | |||
| Field Name | Structured Type | | | Field Name | Structured Type | | |||
+----------------------------------+-----------------+ | +----------------------------------+-----------------+ | |||
| Accept | List | | | Accept | List | | |||
| Accept-Encoding | List | | | Accept-Encoding | List | | |||
| Accept-Language | List | | | Accept-Language | List | | |||
| Accept-Patch | List | | | Accept-Patch | List | | |||
| Accept-Post | List | | | Accept-Post | List | | |||
| Accept-Ranges | List | | | Accept-Ranges | List | | |||
skipping to change at page 5, line 24 ¶ | skipping to change at page 6, line 4 ¶ | |||
| TE | List | | | TE | List | | |||
| Timing-Allow-Origin | List | | | Timing-Allow-Origin | List | | |||
| Trailer | List | | | Trailer | List | | |||
| Transfer-Encoding | List | | | Transfer-Encoding | List | | |||
| Upgrade-Insecure-Requests | Item | | | Upgrade-Insecure-Requests | Item | | |||
| 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 | |||
2.1. Caveats | ||||
Note the following caveats regarding compatibility: | Note the following caveats regarding compatibility: | |||
Parsing differences: Some values may fail to parse as Structured | Parsing differences: Some values may fail to parse as Structured | |||
Fields, even though they are valid according to their originally | Fields, even though they are valid according to their originally | |||
specified syntax. For example, HTTP parameter names are case- | specified syntax. For example, HTTP parameter names are case- | |||
insensitive (per Section 5.6.6 of [HTTP]), but Structured Fields | insensitive (per Section 5.6.6 of [HTTP]), but Structured Fields | |||
require them to be all-lowercase. Likewise, many Dictionary-based | require them to be all-lowercase. Likewise, many Dictionary-based | |||
fields (e.g., Cache-Control, Expect-CT, Pragma, Prefer, | fields (e.g., Cache-Control, Expect-CT, Pragma, Prefer, | |||
Preference-Applied, Surrogate-Control) have case-insensitive keys. | Preference-Applied, Surrogate-Control) have case-insensitive keys. | |||
Similarly, the parameters rule in HTTP (see Section 5.6.6 of | Similarly, the parameters rule in HTTP (see Section 5.6.6 of | |||
skipping to change at page 6, line 42 ¶ | skipping to change at page 7, line 24 ¶ | |||
requirements. | requirements. | |||
Retry-After: Only the delta-seconds form of Retry-After can be | Retry-After: Only the delta-seconds form of Retry-After can be | |||
represented; a Retry-After value containing a http-date will need | represented; a Retry-After value containing a http-date will need | |||
to be converted into delta-seconds to be conveyed as a Structured | to be converted into delta-seconds to be conveyed as a Structured | |||
Field Value. | Field Value. | |||
3. Mapped Fields | 3. Mapped Fields | |||
Some HTTP field values have syntax that cannot be successfully parsed | Some HTTP field values have syntax that cannot be successfully parsed | |||
as Structured Fields. Instead, it is necessary to map them into a | as Structured Field values. Instead, it is necessary to map them | |||
separate Structured Field with an alternative name. | into a Structured Field value. | |||
For example, the Date HTTP header field carries a date: | For example, the Date HTTP header field carries a date: | |||
Date: Sun, 06 Nov 1994 08:49:37 GMT | Date: Sun, 06 Nov 1994 08:49:37 GMT | |||
Its value would be mapped to: | Its value would be mapped to: | |||
SF-Date: @784111777 | @784111777 | |||
As in Section 2, these fields are unable to carry values that are not | ||||
valid Structured Fields, and so an application using this | ||||
specification will need to how to support such values. Typically, | ||||
handling them using the original field name is sufficient. | ||||
Each field name listed below indicates a replacement field name and a | Unlike those listed in Section 2, these representations are not | |||
means of mapping its original value into a Structured Field. | compatible with the original fields' syntax, and MUST NOT be used | |||
unless they are explicitly and unambiguously supported. For example, | ||||
this means that sending them to a next-hop recipient in HTTP requires | ||||
prior negotiation. This specification does not define how to do so. | ||||
3.1. URLs | 3.1. URLs | |||
The field names in Table 2 (paired with their mapped field names) | The field names in Table 2 have values that can be mapped into | |||
have values that can be mapped into Structured Fields by treating the | Structured Field values by treating the original field's value as a | |||
original field's value as a String. | String. | |||
+------------------+---------------------+ | +------------------+ | |||
| Field Name | Mapped Field Name | | | Field Name | | |||
+------------------+---------------------+ | +------------------+ | |||
| Content-Location | SF-Content-Location | | | Content-Location | | |||
| Location | SF-Location | | | Location | | |||
| Referer | SF-Referer | | | Referer | | |||
+------------------+---------------------+ | +------------------+ | |||
Table 2: URL Fields | Table 2: URL Fields | |||
For example, this Location field | For example, this Location field: | |||
Location: https://example.com/foo | Location: https://example.com/foo | |||
could be mapped as: | would have a mapped value of: | |||
SF-Location: "https://example.com/foo" | "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 have values that can be mapped into | |||
have values that can be mapped into Structured Fields by parsing | Structured Field values by parsing their payload according to | |||
their payload according to Section 5.6.7 of [HTTP] and representing | Section 5.6.7 of [HTTP] and representing the result as a Date. | |||
the result as a Date. | ||||
+---------------------+------------------------+ | +---------------------+ | |||
| Field Name | Mapped Field Name | | | Field Name | | |||
+---------------------+------------------------+ | +---------------------+ | |||
| Date | SF-Date | | | Date | | |||
| Expires | SF-Expires | | | Expires | | |||
| If-Modified-Since | SF-If-Modified-Since | | | If-Modified-Since | | |||
| If-Unmodified-Since | SF-If-Unmodified-Since | | | If-Unmodified-Since | | |||
| Last-Modified | SF-Last-Modified | | | Last-Modified | | |||
+---------------------+------------------------+ | +---------------------+ | |||
Table 3: Date Fields | Table 3: Date Fields | |||
For example, an Expires field could be mapped as: | For example, an Expires field's value could be mapped as: | |||
SF-Expires: @1659578233 | @1659578233 | |||
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 a | |||
ETag Structured Field by representing the entity-tag as a String, and | Structured Field value by representing the entity-tag as a String, | |||
the weakness flag as a Boolean "w" parameter on it, where true | and 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, this: | For example, this ETag header field: | |||
ETag: W/"abcdef" | ETag: W/"abcdef" | |||
SF-ETag: "abcdef"; w | would have a mapped value of: | |||
If-None-Match's field value can be mapped into the SF-If-None-Match | "abcdef"; w | |||
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 | If-None-Match's field value can be mapped into a Structured Field | |||
Structured Field in the same manner. | value which is a List of the structure described above. When a field | |||
value contains "*", it is represented as a Token. | ||||
For example: | Likewise, If-Match's field value can be mapped into a Structured | |||
Field value in the same manner. | ||||
SF-If-None-Match: "abcdef"; w, "ghijkl", * | For example, this If-None-Match field: | |||
If-None-Match: W/"abcdef", "ghijkl", * | ||||
would have a mapped value of: | ||||
"abcdef"; w, "ghijkl", * | ||||
3.4. Cookies | 3.4. 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 Structured Fields Lists. | |||
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). | |||
Cookie attributes map to Parameters on the Inner List, with the | Cookie attributes map to Parameters on the Inner List, with the | |||
parameter name being forced to lowercase. Cookie attribute values | parameter name being forced to lowercase. Cookie attribute values | |||
are Strings unless a specific type is defined for them. This | are Strings unless a specific type is defined for them. This | |||
skipping to change at page 9, line 34 ¶ | skipping to change at page 10, line 22 ¶ | |||
| Path | String | | | Path | String | | |||
| Secure | Boolean | | | Secure | Boolean | | |||
| SameSite | Token | | | SameSite | Token | | |||
+----------------+-----------------+ | +----------------+-----------------+ | |||
Table 4: Set-Cookie Parameter Types | Table 4: Set-Cookie Parameter Types | |||
The Expires attribute is mapped to a Date representation of parsed- | The Expires attribute is mapped to a Date representation of parsed- | |||
cookie-date (see Section 5.1.1 of [COOKIES]). | cookie-date (see Section 5.1.1 of [COOKIES]). | |||
For example, these unstructured fields: | For example, this Set-Cookie field: | |||
Set-Cookie: lang=en-US; Expires=Wed, 09 Jun 2021 10:18:14 GMT; | Set-Cookie: Lang=en-US; Expires=Wed, 09 Jun 2021 10:18:14 GMT; | |||
samesite=Strict; secure | samesite=Strict; secure | |||
Cookie: SID=31d4d96e407aad42; lang=en-US | ||||
can be mapped into: | would have a mapped value of: | |||
SF-Set-Cookie: ("lang" "en-US"); expires=@1623233894; | ("Lang" "en-US"); expires=@1623233894; | |||
samesite=Strict; secure | samesite=Strict; secure | |||
SF-Cookie: ("SID" "31d4d96e407aad42"), ("lang" "en-US") | ||||
And this Cookie field: | ||||
Cookie: SID=31d4d96e407aad42; lang=en-US | ||||
would have a mapped value of: | ||||
("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": | |||
A prefix of "*" in the Structured Type column indicates that it is | A prefix of "*" in the Structured Type column indicates that it is | |||
a retrofit type (i.e., not natively Structured); see RFC nnnn. | a retrofit type (i.e., not natively Structured); see RFC nnnn. | |||
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 | ||||
Structured Type as indicated, a status of "permanent" and referring | ||||
to this document. | ||||
+------------------------+-----------------+ | ||||
| Field Name | Structured Type | | ||||
+------------------------+-----------------+ | ||||
| SF-Content-Location | Item | | ||||
| SF-Cookie | List | | ||||
| SF-Date | Item | | ||||
| SF-ETag | Item | | ||||
| SF-Expires | Item | | ||||
| SF-If-Match | List | | ||||
| SF-If-Modified-Since | Item | | ||||
| SF-If-None-Match | List | | ||||
| SF-If-Unmodified-Since | Item | | ||||
| SF-Last-Modified | Item | | ||||
| SF-Location | Item | | ||||
| SF-Referer | Item | | ||||
| SF-Set-Cookie | List | | ||||
+------------------------+-----------------+ | ||||
Table 5: New 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 | |||
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. | |||
Section 3 defines alternative representations of existing fields. | Section 3 defines alternative representations of existing fields. | |||
Because downstream consumers might interpret the message differently | Because downstream consumers might interpret the message differently | |||
based upon whether they recognise the alternative representation, | based upon whether they recognise the alternative representation, | |||
implementations are prohibited from generating such fields unless | implementations are prohibited from generating such values unless | |||
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] Bingler, S., West, M., and J. Wilander, "Cookies: HTTP | [COOKIES] Bingler, S., West, M., and J. Wilander, "Cookies: HTTP | |||
State Management Mechanism", draft-ietf-httpbis- | State Management Mechanism", draft-ietf-httpbis- | |||
rfc6265bis-11 (work in progress), November 2022. | rfc6265bis-15 (work in progress), July 2024. | |||
[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/info/rfc9110>. | <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>. | |||
[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-01 (work in progress), | HTTP", draft-ietf-httpbis-sfbis-06 (work in progress), | |||
December 2022. | April 2024. | |||
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. 49 change blocks. | ||||
121 lines changed or deleted | 135 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/ |