Retrofit Structured Fields for HTTP

Introduction Structured Field Values for HTTP introduced a data model with associated parsing and serialisation algorithms for HTTP field values. Header fields that are defined as Structured Fields can realise a number of benefits, including:

Improved interoperability and security: precisely defined parsing and serialisation algorithms are typically not available for fields defined with just ABNF and/or prose.
Reuse of common implementations: many parsers for other fields are specific to a single field or a small family of fields
Canonical form: because a deterministic serialisation algorithm is defined for each type, Structure Fields have a canonical representation
Enhanced API support: a regular data model makes it easier to expose field values as a native data structure in implementations
Alternative serialisations: While defines a textual serialisation of that data model, other, more efficient serialisations of the underlying data model are also possible.

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 bulk of header and trailer fields seen in HTTP traffic on the Internet. This specification defines how a selection of existing HTTP fields can be handled as Structured Fields, so that these benefits can be realised -- thereby making them Retrofit Structured Fields. It does so using two techniques. lists compatible fields -- those that can be handled as if they were Structured Fields due to the similarity of their defined syntax to that in Structured Fields. lists mapped fields -- those whose syntax needs to be transformed into an underlying data model which is then mapped into that defined by Structured Fields. While implementations can parse and serialise Compatible Fields as Structured Fields subject to the caveats in , a sender cannot generate mapped fields from and expect them to be understood and acted upon by the recipient without prior negotiation. This specification does not define such a mechanism.

Notational Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Compatible Fields HTTP fields with the following names can usually have their values handled as Structured Fields according to the listed parsing and serialisation algorithms in , subject to the listed caveats. The listed types are chosen for compatibility with the defined syntax of the field as well as with actual Internet traffic (see ). However, not all instances of these fields will successfully parse. This might be because the field value is clearly invalid, or it might be because it is valid but not parseable as a Structured Field. As such, an application using this specification will need to consider how to handle these field values. Depending on its requirements, it might be advisable to reject such values, treat them as opaque strings, or attempt to recover a structured value from them in an ad hoc fashion.

Accept - List
Accept-Encoding - List
Accept-Language - List
Accept-Patch - List
Accept-Ranges - List
Access-Control-Allow-Credentials - Item
Access-Control-Allow-Headers - List
Access-Control-Allow-Methods - List
Access-Control-Allow-Origin - Item
Access-Control-Expose-Headers - List
Access-Control-Max-Age - Item
Access-Control-Request-Headers - List
Access-Control-Request-Method - Item
Age - Item
Allow - List
ALPN - List
Alt-Svc - Dictionary
Alt-Used - Item
Cache-Control - Dictionary
Connection - List
Content-Encoding - List
Content-Language - List
Content-Length - List
Content-Type - Item
Cross-Origin-Resource-Policy - Item
Expect - Item
Expect-CT - Dictionary
Host - Item
Keep-Alive - Dictionary
Origin - Item
Pragma - Dictionary
Prefer - Dictionary
Preference-Applied - Dictionary
Retry-After - Item
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

Note the following caveats:

Parameters:: HTTP parameter names are case-insensitive (as per ), 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.
Empty Field Values:: Empty and whitespace-only field values are considered errors in Structured Fields. For compatible fields, an 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 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 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 not uncommon for implementations to mistakenly send multiple values. See for handling requirements.
Retry-After:: Only the delta-seconds form of Retry-After is supported; a Retry-After value containing a http-date will need to be either converted into delta-seconds or represented as a raw value.

Mapped Fields HTTP fields with the following names can have their values represented in Structured Fields by mapping them into its data types and then serialising the result using an alternative field name. For example, the Date HTTP header field carries a string representing a date: Its value is more efficiently represented as an integer number of delta seconds from the Unix epoch (00:00:00 UTC on 1 January 1970, minus leap seconds). Thus, the example above would be mapped as: As in , these fields are unable to represent values that are not Structured Fields, and so an application using this specification will need to how to support such values. Typically, serialising them using the original field name is sufficient. Each field name listed below indicates a replacement field name and a means of mapping its original value into a Structured Field.

URLs The following field names (paired with their replacement field names) have values that can be represented as Structured Fields by considering the original field's value as a string.

Content-Location - SF-Content-Location
Location - SF-Location
Referer - SF-Referer

For example, a Location field could be represented as:

Dates The following field names (paired with their replacement field names) have values that can be represented as Structured Fields by parsing their payload according to , Section 7.1.1.1, and representing the result as an integer number of seconds delta from the Unix Epoch (00:00:00 UTC on 1 January 1970, minus leap seconds).

Date - SF-Date
Expires - SF-Expires
If-Modified-Since - SF-IMS
If-Unmodified-Since - SF-IUS
Last-Modified - SF-LM

For example, an Expires field could be represented as:

ETags The following field names (paired with their replacement field names) have values that can be represented as Structured Fields by representing the entity-tag as a string, 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 is strong.

ETag - SF-ETag

For example: If-None-Match is a list of the structure described above.

If-None-Match - SF-INM

For example:

Links The field-value of the Link header field can be represented as a Structured Field by representing the URI-Reference as a string, and link-param as parameters.

Link: SF-Link

For example:

Cookies The field-values of the Cookie and Set-Cookie fields can be represented in Structured Fields as a List with parameters and a Dictionary, respectively. The serialisation is almost identical, except that the Expires parameter is always a string (as it can contain a comma), multiple cookie-strings can appear in Set-Cookie, and cookie-pairs are delimited in Cookie by a comma, rather than a semicolon.

Set-Cookie: SF-Set-Cookie
Cookie: SF-Cookie

ISSUE: explicitly convert Expires to an integer? https://github.com/mnot/I-D/issues/308
ISSUE: dictionary keys cannot contain UC alpha. https://github.com/mnot/I-D/issues/312
ISSUE: explicitly allow non-string content. https://github.com/mnot/I-D/issues/313

IANA Considerations IANA is asked to register the following entries in the HTTP Field Name Registry with a status of "permanent" and referring to this document:

SF-Content-Location
SF-Location
SF-Referer
SF-Date
SF-Expires
SF-IMS
SF-IUS
SF-LM
SF-ETag
SF-INM
SF-Link
SF-Set-Cookie
SF-Cookie