draft-ietf-httpbis-retrofit-00.txt		draft-ietf-httpbis-retrofit-01.txt
	Network Working Group M. Nottingham		Network Working Group M. Nottingham
	Internet-Draft 26 February 2022		Internet-Draft 23 April 2022
	Intended status: Standards Track		Intended status: Standards Track
	Expires: 30 August 2022		Expires: 25 October 2022
	Retrofit Structured Fields for HTTP		Retrofit Structured Fields for HTTP
	draft-ietf-httpbis-retrofit-00		draft-ietf-httpbis-retrofit-01
	Abstract		Abstract
	This specification defines how a selection of existing HTTP fields		This specification defines how a selection of existing HTTP fields
	can be handled as Structured Fields.		can be handled as Structured Fields.
	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.
	skipping to change at page 1, line 46 ¶		skipping to change at page 1, line 46 ¶
	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 30 August 2022.		This Internet-Draft will expire on 25 October 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 (https://trustee.ietf.org/		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	license-info) in effect on the date of publication of this document.		license-info) in effect on the date of publication of this document.
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	and restrictions with respect to this document. Code Components		and restrictions with respect to this document. Code Components
	extracted from this document must include Revised BSD License text as		extracted from this document must include Revised BSD License text as
	described in Section 4.e of the Trust Legal Provisions and are		described in Section 4.e of the Trust Legal Provisions and are
	provided without warranty as described in the Revised BSD License.		provided without warranty as described in the Revised 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 . . . . . . . . . . . . . . . . . . . . . . 3		2. Compatible Fields . . . . . . . . . . . . . . . . . . . . . . 3
	3. Mapped Fields . . . . . . . . . . . . . . . . . . . . . . . . 6		3. Mapped Fields . . . . . . . . . . . . . . . . . . . . . . . . 7
	3.1. URLs . . . . . . . . . . . . . . . . . . . . . . . . . . 7		3.1. URLs . . . . . . . . . . . . . . . . . . . . . . . . . . 8
	3.2. Dates . . . . . . . . . . . . . . . . . . . . . . . . . . 7		3.2. Dates . . . . . . . . . . . . . . . . . . . . . . . . . . 8
	3.3. ETags . . . . . . . . . . . . . . . . . . . . . . . . . . 8		3.3. ETags . . . . . . . . . . . . . . . . . . . . . . . . . . 9
	3.4. Links . . . . . . . . . . . . . . . . . . . . . . . . . . 8		3.4. Links . . . . . . . . . . . . . . . . . . . . . . . . . . 9
	3.5. Cookies . . . . . . . . . . . . . . . . . . . . . . . . . 8		3.5. Cookies . . . . . . . . . . . . . . . . . . . . . . . . . 10
	4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9		4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 10		5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
	6. Normative References . . . . . . . . . . . . . . . . . . . . 10		6. Normative References . . . . . . . . . . . . . . . . . . . . 12
	Appendix A. Data Supporting Field Compatibility . . . . . . . . 11		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14
	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 serialisation algorithms for		data model with associated parsing and serialization algorithms for
	use by new HTTP field values. Header fields that are defined as		use by new HTTP field values. Header fields that are defined as
	Structured Fields can realise a number of benefits, including:		Structured Fields can realise a number of benefits, including:
	* Improved interoperability and security: precisely defined parsing		* 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.
	* Reuse of common implementations: many parsers for other fields are		* 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
	skipping to change at page 3, line 15 ¶		skipping to change at page 3, line 15 ¶
	* Enhanced API support: a regular data model makes it easier to		* Enhanced API support: a regular data model makes it easier to
	expose field values as a native data structure in implementations		expose field values as a native data structure in implementations
	* Alternative serialisations: While [STRUCTURED-FIELDS] defines a		* Alternative serialisations: While [STRUCTURED-FIELDS] defines a
	textual serialisation of that data model, other, more efficient		textual serialisation of that data model, other, more efficient
	serialisations of the underlying data model are also possible.		serialisations of the underlying data model are also possible.
	However, a field needs to be defined as a Structured Field for these		However, a field needs to be defined as a Structured Field for these
	benefits to be realised. Many existing fields are not, making up the		benefits to be realised. Many existing fields are not, making up the
	bulk of header and trailer fields seen in HTTP traffic on the		bulk of header and trailer fields seen in HTTP traffic on the
	Internet.		internet.
	This specification defines how a selection of existing HTTP fields		This specification defines how a selection of existing HTTP fields
	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.
	While implementations can parse and serialise Compatible Fields as		While implementations can parse and serialise compatible fields as
	Structured Fields subject to the caveats in Section 2, a sender		Structured Fields subject to the caveats in Section 2, a sender
	cannot generate mapped fields from Section 3 and expect them to be		cannot generate mapped fields from Section 3 and expect them to be
	understood and acted upon by the recipient without prior negotiation.		understood and acted upon by the recipient without prior negotiation.
	This specification does not define such a mechanism.		This specification does not define such a mechanism.
	1.1. Notational Conventions		1.1. 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.
	2. Compatible Fields		2. Compatible Fields
	HTTP fields with the following names can usually have their values		The HTTP fields listed in Table 1 can usually have their values
	handled as Structured Fields according to the listed parsing and		handled as Structured Fields according to the listed parsing and
	serialisation algorithms in [STRUCTURED-FIELDS], subject to the		serialisation algorithms in [STRUCTURED-FIELDS], subject to the
	listed caveats.		listed caveats.
	The listed types are chosen for compatibility with the defined syntax		The listed types are chosen for compatibility with the defined syntax
	of the field as well as with actual Internet traffic (see		of the field as well as with actual internet traffic. However, not
	Appendix A). However, not all instances of these fields will		all instances of these fields will successfully parse. This might be
	successfully parse. This might be because the field value is clearly		because the field value is clearly invalid, or it might be because it
	invalid, or it might be because it is valid but not parseable as a		is valid but not parseable as a Structured Field.
	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 value from them in an ad hoc fashion.
	* Accept - List		+==================================+=================+
			| Field Name | Structured Type |
	* Accept-Encoding - List		+==================================+=================+
			| Accept | List |
	* Accept-Language - List		+----------------------------------+-----------------+
			| Accept-Encoding | List |
	* Accept-Patch - List		+----------------------------------+-----------------+
			| Accept-Language | List |
	* Accept-Ranges - List		+----------------------------------+-----------------+
			| Accept-Patch | List |
	* Access-Control-Allow-Credentials - Item		+----------------------------------+-----------------+
			| Accept-Post | List |
	* Access-Control-Allow-Headers - List		+----------------------------------+-----------------+
			| Accept-Ranges | List |
	* Access-Control-Allow-Methods - List		+----------------------------------+-----------------+
			| Access-Control-Allow-Credentials | Item |
	* Access-Control-Allow-Origin - Item		+----------------------------------+-----------------+
			| Access-Control-Allow-Headers | List |
	* Access-Control-Expose-Headers - List		+----------------------------------+-----------------+
			| Access-Control-Allow-Methods | List |
	* Access-Control-Max-Age - Item		+----------------------------------+-----------------+
			| Access-Control-Allow-Origin | Item |
	* Access-Control-Request-Headers - List		+----------------------------------+-----------------+
			| Access-Control-Expose-Headers | List |
	* Access-Control-Request-Method - Item		+----------------------------------+-----------------+
			| Access-Control-Max-Age | Item |
	* Age - Item		+----------------------------------+-----------------+
			| Access-Control-Request-Headers | List |
	* Allow - List		+----------------------------------+-----------------+
			| Access-Control-Request-Method | Item |
	* ALPN - List		+----------------------------------+-----------------+
			| Age | Item |
	* Alt-Svc - Dictionary		+----------------------------------+-----------------+
			| Allow | List |
	* Alt-Used - Item		+----------------------------------+-----------------+
	* Cache-Control - Dictionary		| ALPN | List |
			+----------------------------------+-----------------+
	* Connection - List		| Alt-Svc | Dictionary |
			+----------------------------------+-----------------+
	* Content-Encoding - List		| Alt-Used | Item |
			+----------------------------------+-----------------+
	* Content-Language - List		| Cache-Control | Dictionary |
			+----------------------------------+-----------------+
	* Content-Length - List		| CDN-Loop | List |
			+----------------------------------+-----------------+
	* Content-Type - Item		| Clear-Site-Data | List |
			+----------------------------------+-----------------+
	* Cross-Origin-Resource-Policy - Item		| Connection | List |
			+----------------------------------+-----------------+
	* Expect - Item		| Content-Encoding | List |
			+----------------------------------+-----------------+
	* Expect-CT - Dictionary		| Content-Language | List |
			+----------------------------------+-----------------+
	* Host - Item		| Content-Length | List |
			+----------------------------------+-----------------+
	* Keep-Alive - Dictionary		| Content-Type | Item |
			+----------------------------------+-----------------+
	* Origin - Item		| Cross-Origin-Resource-Policy | Item |
			+----------------------------------+-----------------+
	* Pragma - Dictionary		| Expect | Dictionary |
			+----------------------------------+-----------------+
	* Prefer - Dictionary		| Expect-CT | Dictionary |
			+----------------------------------+-----------------+
	* Preference-Applied - Dictionary		| Forwarded | Dictionary |
			+----------------------------------+-----------------+
	* Retry-After - Item		| Host | Item |
			+----------------------------------+-----------------+
	* Surrogate-Control - Dictionary		| Keep-Alive | Dictionary |
			+----------------------------------+-----------------+
	* TE - List		| Max-Forwards | Item |
			+----------------------------------+-----------------+
			| Origin | Item |
			+----------------------------------+-----------------+
			| Pragma | Dictionary |
			+----------------------------------+-----------------+
			| Prefer | Dictionary |
			+----------------------------------+-----------------+
			| Preference-Applied | Dictionary |
			+----------------------------------+-----------------+
			| Retry-After | Item |
			+----------------------------------+-----------------+
			| Sec-WebSocket-Extensions | List |
			+----------------------------------+-----------------+
			| Sec-WebSocket-Protocol | List |
			+----------------------------------+-----------------+
			| Sec-WebSocket-Version | Item |
			+----------------------------------+-----------------+
			| Server-Timing | List |
			+----------------------------------+-----------------+
			| Surrogate-Control | Dictionary |
			+----------------------------------+-----------------+
			| TE | List |
			+----------------------------------+-----------------+
			| Timing-Allow-Origin | List |
			+----------------------------------+-----------------+
			| Trailer | List |
			+----------------------------------+-----------------+
			| Transfer-Encoding | List |
			+----------------------------------+-----------------+
			| Vary | List |
			+----------------------------------+-----------------+
			| X-Content-Type-Options | Item |
			+----------------------------------+-----------------+
			| X-Frame-Options | Item |
			+----------------------------------+-----------------+
			| X-XSS-Protection | List |
			+----------------------------------+-----------------+
	* Timing-Allow-Origin: List		Table 1
	* Trailer - List		Note the following caveats regarding compatibility:
	* Transfer-Encoding - List		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
			encountered. 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.
	* Vary - List		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.
	* X-Content-Type-Options - Item		String quoting: Section 5.6.4 of [HTTP] allows backslash-escaping
			most characters in quoted strings, whereas Structured Field
			Strings only escapes "" and DQUOTE. Compatibility can be improved
			by unescaping other characters before processing as Strings.
	* X-Frame-Options - Item		Token limitations: In Structured Fields, tokens are required to
	* X-XSS-Protection - List		begin with an alphabetic character or "*", whereas HTTP tokens
			allow a wider range of characters. This prevents use of mapped
			values that begin with one of these characters. For example,
			media types, field names, methods, range-units, character and
			transfer codings that begin with a number or special character
			other than "*" might be valid HTTP protocol elements, but will not
			be able to be parsed as Structured Field Tokens.
	Note the following caveats:		Integer limitations: Structured Fields Integers can have at most 15
			digits; larger values will not be able to be represented in them.
	Parameter names: HTTP parameter names are case-insensitive (as per		IPv6 Literals: Fields whose values can contain IPv6 literal
	Section 5.6.6 of [HTTP]), but Structured Fields require them to be		addresses (such as CDN-Loop, Host, and Origin) are not compatible
	all-lowercase. Although the vast majority of parameters seen in		when those values are parsed as Structured Fields Tokens, because
	typical traffic are all-lowercase, compatibility can be improved		the brackets used to delimit them are not allowed in Tokens.
	by force-lowercasing parameters when encountered.
	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, this		syntax. Since the final version of HTTP/3 uses the h3 token, this
	shouldn't be a long-term issue, although future tokens may again		shouldn't be a long-term issue, although future tokens may again
	violate this assumption.		violate this assumption.
	Cache-Control, Expect-CT, Pragma, Prefer, Preference-Applied,
	Surrogate-Control: These Dictionary-based fields consider the key to
	be case-insensitive, but Structured Fields requires keys to be
	all-lowercase. Although the vast majority of values seen in
	typical traffic are all-lowercase, compatibility can be improved
	by force-lowercasing these Dictionary keys when encountered.
	Content-Length: Content-Length is defined as a List because it is		Content-Length: Content-Length is defined as a List because it is
	not uncommon for implementations to mistakenly send multiple		not uncommon for implementations to mistakenly send multiple
	values. See Section 8.6 of [HTTP] for handling requirements.		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 is
	supported; a Retry-After value containing a http-date will need to		supported; a Retry-After value containing a http-date will need to
	be either converted into delta-seconds or represented as a raw		be either converted into delta-seconds or represented as a raw
	value.		value.
	3. Mapped Fields		3. Mapped Fields
	skipping to change at page 7, line 20 ¶		skipping to change at page 8, line 17 ¶
	As in Section 2, these fields are unable to represent values that are		As in Section 2, these fields are unable to represent values that are
	not parseable, and so an application using this specification will		not parseable, and so an application using this specification will
	need to how to support such values. Typically, handling them using		need to how to support such values. Typically, handling them using
	the original field name is sufficient.		the original field name is sufficient.
	Each field name listed below indicates a replacement field name and a		Each field name listed below indicates a replacement field name and a
	means of mapping its original value into a Structured Field.		means of mapping its original value into a Structured Field.
	3.1. URLs		3.1. URLs
	The following field names (paired with their replacement field names)		The field names in Table 2 (paired with their mapped field names)
	have values that can be represented as Structured Fields by		have values that can be represented as Structured Fields by
	considering the original field's value as a string.		considering the original field's value as a string.
	* Content-Location - SF-Content-Location		+==================+=====================+
			| Field Name | Mapped Field Name |
	* Location - SF-Location		+==================+=====================+
			| Content-Location | SF-Content-Location |
			+------------------+---------------------+
			| Location | SF-Location |
			+------------------+---------------------+
			| Referer | SF-Referer |
			+------------------+---------------------+
	* Referer - SF-Referer		Table 2
	For example, a Location field could be represented as:		For example, a Location field could be represented as:
	SF-Location: "https://example.com/foo"		SF-Location: "https://example.com/foo"
	3.2. Dates		3.2. Dates
	The following field names (paired with their replacement field names)		The field names in Table 3 (paired with their mapped field names)
	have values that can be represented as Structured Fields by parsing		have values that can be represented as 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, minus leap seconds).		(00:00:00 UTC on 1 January 1970, minus leap seconds).
	* Date - SF-Date		+=====================+===================+
			| Field Name | Mapped Field Name |
	* Expires - SF-Expires		+=====================+===================+
			| Date | SF-Date |
	* If-Modified-Since - SF-IMS		+---------------------+-------------------+
			| Expires | SF-Expires |
			+---------------------+-------------------+
			| If-Modified-Since | SF-IMS |
			+---------------------+-------------------+
			| If-Unmodified-Since | SF-IUS |
			+---------------------+-------------------+
			| Last-Modified | SF-LM |
			+---------------------+-------------------+
	* If-Unmodified-Since - SF-IUS		Table 3
	* Last-Modified - SF-LM
	For example, an Expires field could be represented as:		For example, an Expires field could be represented as:
	SF-Expires: 1571965240		SF-Expires: 1571965240
	3.3. ETags		3.3. ETags
	The field value of the ETag header field can be represented as a		The field value of the ETag header field can be represented as a
	String Structured Field by representing the entity-tag as a string,		String Structured Field by representing the entity-tag as a string,
	and 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
	skipping to change at page 8, line 51 ¶		skipping to change at page 10, line 19 ¶
	Cookie Structured Field (a Dictionary), respectively.		Cookie Structured Field (a Dictionary), respectively.
	In each case, cookie names are serialized as tokens, whereas their		In each case, cookie names are serialized as tokens, whereas their
	values are serialised as Strings, unless they can be represented		values are serialised as Strings, unless they can be represented
	accurately and unambiguously using the textual representation of		accurately and unambiguously using the textual representation of
	another structured types (e.g., an Integer or Decimal).		another structured types (e.g., an Integer or Decimal).
	Set-Cookie parameters map to parameters on the appropriate SF-Set-		Set-Cookie parameters map to parameters on the appropriate SF-Set-
	Cookie member, with the parameter name being forced to lowercase.		Cookie member, with the parameter name being forced to lowercase.
	Set-Cookie parameter values are Strings unless a specific type is		Set-Cookie parameter values are Strings unless a specific type is
	defined. This specification defines the following parameter types:		defined. This specification defines the parameter types in Table 4.
	* Max-Age: Integer
	* Secure: Boolean
	* HttpOnly: Boolean		+================+=================+
			| Parameter Name | Structured Type |
			+================+=================+
			| Max-Age | Integer |
			+----------------+-----------------+
			| Secure | Boolean |
			+----------------+-----------------+
			| HttpOnly | Boolean |
			+----------------+-----------------+
			| SameSite | Token |
			+----------------+-----------------+
	* SameSite: Token		Table 4
	Note that cookies in both fields are separated by commas, not		Note that cookies in both fields are separated by commas, not
	semicolons, and multiple cookies can appear in each field.		semicolons, and multiple cookies can appear in each field.
	For example:		For example:
	SF-Set-Cookie: lang=en-US; expires="Wed, 09 Jun 2021 10:18:14 GMT";		SF-Set-Cookie: lang=en-US; expires="Wed, 09 Jun 2021 10:18:14 GMT";
	samesite=Strict		samesite=Strict
	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 HTTP Field Name Registry:		Please add the following note to the "Hypertext Transfer Protocol
			(HTTP) Field Name Registry":
	The "Structured Type" column indicates the type of the field as		The "Structured Type" column indicates the type of the field (per
	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].
			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 following field names into the HTTP Field Name		Then, add the field names in Table 5, with the corresponding
	Registry, with the corresponding Structured Type as indicated, a		Structured Type as indicated, a status of "permanent" and referring
	status of "permanent" and referring to this document:		to this document.
	* SF-Content-Location - String
	* SF-Location - String
	* SF-Referer - String
	* SF-Date - Integer
	* SF-Expires - Integer
	* SF-IMS - Integer
	* SF-IUS - Integer
	* SF-LM - Integer
	* SF-ETag - Item		+=====================+=================+
			| Field Name | Structured Type |
			+=====================+=================+
			| SF-Content-Location | String |
			+---------------------+-----------------+
			| SF-Location | String |
			+---------------------+-----------------+
			| SF-Referer | String |
			+---------------------+-----------------+
			| SF-Date | Item |
			+---------------------+-----------------+
			| SF-Expires | Item |
			+---------------------+-----------------+
			| SF-IMS | Item |
			+---------------------+-----------------+
			| SF-IUS | Item |
			+---------------------+-----------------+
			| SF-LM | Item |
			+---------------------+-----------------+
			| SF-ETag | Item |
			+---------------------+-----------------+
			| SF-INM | List |
			+---------------------+-----------------+
			| SF-Link | List |
			+---------------------+-----------------+
			| SF-Set-Cookie | Dictionary |
			+---------------------+-----------------+
			| SF-Cookie | List |
			+---------------------+-----------------+
	* SF-INM - List		Table 5
	* SF-Link - List		Finally, add the indicated structured type for each existing registry
			entry below:
	* SF-Set-Cookie - Dictionary		+==========================================+=================+
			| Field Name | Structured Type |
			+==========================================+=================+
			| Accept-CH | List |
			+------------------------------------------+-----------------+
			| Cache-Status | List |
			+------------------------------------------+-----------------+
			| CDN-Cache-Control | Dictionary |
			+------------------------------------------+-----------------+
			| Cross-Origin-Opener-Policy | Item |
			+------------------------------------------+-----------------+
			| Cross-Origin-Opener-Policy-Report-Only | Item |
			+------------------------------------------+-----------------+
			| Cross-Origin-Embedder-Policy | Item |
			+------------------------------------------+-----------------+
			| Cross-Origin-Embedder-Policy-Report-Only | Item |
			+------------------------------------------+-----------------+
			| Origin-Agent-Cluster | Item |
			+------------------------------------------+-----------------+
			| Priority | Dictionary |
			+------------------------------------------+-----------------+
			| Proxy-Status | List |
			+------------------------------------------+-----------------+
	* SF-Cookie - List		Table 6
	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 other implementations might be exploitable,		Variances from other implementations 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
	skipping to change at page 11, line 18 ¶		skipping to change at page 13, line 33 ¶
	[RFC8288] Nottingham, M., "Web Linking", RFC 8288,		[RFC8288] Nottingham, M., "Web Linking", RFC 8288,
	DOI 10.17487/RFC8288, October 2017,		DOI 10.17487/RFC8288, October 2017,
	<https://www.rfc-editor.org/rfc/rfc8288>.		<https://www.rfc-editor.org/rfc/rfc8288>.
	[STRUCTURED-FIELDS]		[STRUCTURED-FIELDS]
	Nottingham, M. and P-H. Kamp, "Structured Field Values for		Nottingham, M. and P-H. Kamp, "Structured Field Values for
	HTTP", RFC 8941, DOI 10.17487/RFC8941, February 2021,		HTTP", RFC 8941, DOI 10.17487/RFC8941, February 2021,
	<https://www.rfc-editor.org/rfc/rfc8941>.		<https://www.rfc-editor.org/rfc/rfc8941>.
	Appendix A. Data Supporting Field Compatibility
	To help guide decisions about compatible fields, the HTTP response
	headers captured by the HTTP Archive https://httparchive.org
	(https://httparchive.org) in September 2021 (representing more than
	528,000,000 HTTP exchanges) were parsed as Structured Fields using
	the types listed in Section 2, with the indicated number of
	successful header instances, failures, and the resulting failure
	rate:
	accept 9,099 / 34 = 0.372%*
	accept-encoding 116,708 / 58 = 0.050%*
	accept-language 127,710 / 95 = 0.074%*
	accept-patch 281 / 0 = 0.000%
	accept-ranges 289,341,375 / 7,776 = 0.003%
	access-control-allow-credentials 36,159,371 / 2,671 = 0.007%
	access-control-allow-headers 25,980,519 / 23,181 = 0.089%
	access-control-allow-methods 32,071,437 / 17,424 = 0.054%
	access-control-allow-origin 165,719,859 / 130,247 = 0.079%
	access-control-expose-headers 20,787,683 / 1,973 = 0.009%
	access-control-max-age 9,549,494 / 9,846 = 0.103%
	access-control-request-headers 165,882 / 503 = 0.302%*
	access-control-request-method 346,135 / 30,680 = 8.142%*
	age 107,395,872 / 36,649 = 0.034%
	allow 579,822 / 281 = 0.048%
	alt-svc 56,773,977 / 4,914,119 = 7.966%
	cache-control 395,402,834 / 1,146,080 = 0.289%
	connection 112,017,641 / 3,491 = 0.003%
	content-encoding 225,568,224 / 237 = 0.000%
	content-language 3,339,291 / 1,744 = 0.052%
	content-length 422,415,406 / 126 = 0.000%
	content-type 503,950,894 / 507,133 = 0.101%
	cross-origin-resource-policy 102,483,430 / 799 = 0.001%
	expect 0 / 53 = 100.000%*
	expect-ct 54,129,244 / 80,333 = 0.148%
	host 57,134 / 1,486 = 2.535%*
	keep-alive 50,606,877 / 1,509 = 0.003%
	origin 32,438 / 1,396 = 4.126%*
	pragma 66,321,848 / 97,328 = 0.147%
	preference-applied 189 / 0 = 0.000%
	referrer-policy 14,274,787 / 8,091 = 0.057%
	retry-after 523,533 / 7,585 = 1.428%
	surrogate-control 282,846 / 976 = 0.344%
	te 1 / 0 = 0.000%
	timing-allow-origin 91,979,983 / 8 = 0.000%
	trailer 1,171 / 0 = 0.000%
	transfer-encoding 15,098,518 / 0 = 0.000%
	vary 246,483,644 / 69,607 = 0.028%
	x-content-type-options 166,063,072 / 237,255 = 0.143%
	x-frame-options 56,863,322 / 1,014,464 = 1.753%
	x-xss-protection 132,739,109 / 347,133 = 0.261%
	Note that this data set only includes response headers, although some
	request headers are present, indicated with an asterisk (because, the
	Web). Also, Dictionary and Parameter keys have not been force-
	lowercased, with the result that any values containing uppercase keys
	are considered to fail.
	The top thirty header fields in that data set that were not
	considered compatible are (* indicates that the field is mapped in
	Section 3):
	* *date: 524,810,577
	* server: 470,777,294
	* *last-modified: 383,437,099
	* *expires: 292,109,781
	* *etag: 255,788,799
	* strict-transport-security: 111,993,787
	* x-cache: 70,713,258
	* via: 55,983,914
	* cf-ray: 54,556,881
	* p3p: 54,479,183
	* report-to: 54,056,804
	* cf-cache-status: 53,536,789
	* nel: 44,815,769
	* x-powered-by: 37,281,354
	* content-security-policy-report-only: 33,104,387
	* *location: 30,533,957
	* x-amz-cf-pop: 28,549,182
	* x-amz-cf-id: 28,444,359
	* content-security-policy: 25,404,401
	* x-served-by: 23,277,252
	* x-cache-hits: 21,842,899
	* *link: 20,761,372
	* x-timer: 18,780,130
	* content-disposition: 18,516,671
	* x-request-id: 16,048,668
	* referrer-policy: 15,596,734
	* x-cdn: 10,153,756
	* x-amz-version-id: 9,786,024
	* x-amz-request-id: 9,680,689
	* x-dc: 9,557,728
	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. 41 change blocks.
	283 lines changed or deleted		271 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/