draft-ietf-httpbis-retrofit-02.txt | draft-ietf-httpbis-retrofit-latest.txt | |||
---|---|---|---|---|
Network Working Group M. Nottingham | Network Working Group M. Nottingham | |||
Internet-Draft May 11, 2021 | Internet-Draft May 13, 2022 | |||
Intended status: Standards Track | Intended status: Standards Track | |||
Expires: November 12, 2021 | Expires: November 14, 2022 | |||
Retrofit Structured Fields for HTTP | Retrofit Structured Fields for HTTP | |||
draft-ietf-httpbis-retrofit-02 | 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 November 12, 2021. | This Internet-Draft will expire on November 14, 2022. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2021 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 | |||
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 | |||
skipping to change at page 5, line 33 ¶ | skipping to change at page 5, line 33 ¶ | |||
Table 1: Compatible Fields | Table 1: Compatible Fields | |||
Note the following caveats regarding compatibility: | Note the following caveats regarding compatibility: | |||
Parameter and Dictionary keys: HTTP parameter names are case- | Parameter and Dictionary keys: 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. Although the vast majority of | require them to be all-lowercase. Although the vast majority of | |||
parameters seen in typical traffic are all-lowercase, | parameters seen in typical traffic are all-lowercase, | |||
compatibility can be improved by force-lowercasing parameters when | compatibility can be improved by force-lowercasing parameters when | |||
encountered. Likewise, many Dictionary-based fields (e.g., Cache- | parsing. Likewise, many Dictionary-based fields (e.g., Cache- | |||
Control, Expect-CT, Pragma, Prefer, Preference-Applied, Surrogate- | Control, Expect-CT, Pragma, Prefer, Preference-Applied, Surrogate- | |||
Control) have case-insensitive keys, and compatibility can be | Control) have case-insensitive keys, and compatibility can be | |||
improved by force-lowercasing them. | improved by force-lowercasing them when parsing. | |||
Parameter delimitation: The parameters rule in HTTP (see | Parameter delimitation: The parameters rule in HTTP (see | |||
Section 5.6.6 of [HTTP]) allows whitespace before the ";" | Section 5.6.6 of [HTTP]) allows whitespace before the ";" | |||
delimiter, but Structured Fields does not. Compatibility can be | delimiter, but Structured Fields does not. Compatibility can be | |||
improved by allowing such whitespace. | improved by allowing such whitespace when parsing. | |||
String quoting: Section 5.6.4 of [HTTP] allows backslash-escaping | String quoting: Section 5.6.4 of [HTTP] allows backslash-escaping | |||
most characters in quoted strings, whereas Structured Field | most characters in quoted strings, whereas Structured Field | |||
Strings only escape "\" and DQUOTE. Compatibility can be improved | Strings only escape "\" and DQUOTE. Compatibility can be improved | |||
by unescaping other characters before processing as Strings. | 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 parsed 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 can contain IPv6 literal | IPv6 Literals: Fields whose values contain IPv6 literal addresses | |||
addresses (such as CDN-Loop, Host, and Origin) are not compatible | (such as CDN-Loop, Host, and Origin) are not able to be | |||
when those values are parsed as Structured Fields Tokens, because | represented as Structured Fields Tokens, because the brackets used | |||
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 | |||
considered errors in Structured Fields. For compatible fields, an | considered errors in Structured Fields. For compatible fields, an | |||
empty field indicates that the field should be silently ignored. | empty field indicates that the field should be silently ignored. | |||
Alt-Svc: Some ALPN tokens (e.g., "h3-Q43") do not conform to key's | Alt-Svc: Some ALPN tokens (e.g., "h3-Q43") do not conform to key's | |||
syntax. Since the final version of HTTP/3 uses the "h3" token, | syntax, and therefore cannot be represented as a Token. Since the | |||
this shouldn't be a long-term issue, although future tokens may | final version of HTTP/3 uses the "h3" token, this shouldn't be a | |||
again violate this assumption. | long-term issue, although future tokens may again violate this | |||
assumption. | ||||
Content-Length: Content-Length is defined as a List because it is | Content-Length: Note that Content-Length is defined as a List | |||
not uncommon for implementations to mistakenly send multiple | because it is not uncommon for implementations to mistakenly send | |||
values. See Section 8.6 of [HTTP] for handling requirements. | multiple values. See Section 8.6 of [HTTP] for handling | |||
requirements. | ||||
Retry-After: Only the delta-seconds form of Retry-After is | Retry-After: Only the delta-seconds form of Retry-After can be | |||
supported; a Retry-After value containing a http-date will need to | represented; a Retry-After value containing a http-date will need | |||
be either converted into delta-seconds or represented as a raw | to be either converted into delta-seconds to be conveyed as a | |||
value. | Structured 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 Fields. Instead, it is necessary to map them into a | |||
separate Structured Field with an alternative name. | separate Structured Field with an alternative name. | |||
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 | |||
End of changes. 13 change blocks. | ||||
23 lines changed or deleted | 25 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/ |