Merge branch 'main' into digest-auth48

draft-ietf-httpbis-compression-dictionary.md

@@ -39,6 +39,8 @@ author:
 normative:
   FOLDING: RFC8792
   HTTP: RFC9110
+  HTTP-CACHING: RFC9111
+  RFC5861: # Stale-While-Revalidate
 
 informative:
   Origin: RFC6454
@@ -67,7 +69,20 @@ This document describes the HTTP headers used for negotiating dictionary usage
 and registers media types for content encoding Brotli and Zstandard using a
 negotiated dictionary.
 
-This document uses the line folding strategies described in [FOLDING].
+## Notational Conventions
+
+{::boilerplate bcp14-tagged}
+
+This document uses the following terminology from {{Section 3 of STRUCTURED-FIELDS}} to
+specify syntax and parsing: Dictionary, String, Inner List, Token, and Byte Sequence.
+
+The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",
+"RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in
+{{RFC2119}}.
+
+This document uses the line folding strategies described in {{FOLDING}}.
+
+This document also uses terminology from {{HTTP}} and {{HTTP-CACHING}}.
 
 # Dictionary Negotiation
 
@@ -78,13 +93,13 @@ be used as a dictionary for future requests for URLs that match the rules
 specified in the Use-As-Dictionary response header.
 
 The Use-As-Dictionary response header is a Structured Field
-{{STRUCTURED-FIELDS}} sf-dictionary with values for "match", "match-dest",
-"ttl", "id", and "type".
+{{STRUCTURED-FIELDS}} Dictionary with values for "match", "match-dest", "id",
+and "type".
 
 ### match
 
-The "match" value of the Use-As-Dictionary header is a sf-string value
-that provides the URLPattern to use for request matching
+The "match" value of the Use-As-Dictionary header is a String value that
+provides the URLPattern to use for request matching
 (https://urlpattern.spec.whatwg.org/).
 
 The URLPattern used for matching does not support using Regular expressions.
@@ -101,45 +116,28 @@ and baseURL=URL (https://urlpattern.spec.whatwg.org/).
 1. Return True.
 
 The "match" value is required and MUST be included in the
-Use-As-Dictionary sf-dictionary for the dictionary to be considered valid.
+Use-As-Dictionary Dictionary for the dictionary to be considered valid.
 
 ### match-dest
 
-The "match-dest" value of the Use-As-Dictionary header is a sf-string value
-that provides a request destination
-(https://fetch.spec.whatwg.org/#concept-request-destination).
-
-An empty string for "match-dest" MUST match all destinations.
-
-For clients that do not support request destinations or if the value of
-"match-dest" is a value that is not supported by the client then the client
-MUST treat it as an empty string and match all destinations.
-
-The "match-dest" value is optional and defaults to the empty string.
-
-### ttl
+The "match-dest" value of the Use-As-Dictionary header is an Inner List of
+String values that provides a list of request destinations for the dictionary
+to match (https://fetch.spec.whatwg.org/#concept-request-destination).
 
-The "ttl" value of the Use-As-Dictionary header is a sf-integer value that
-provides the time in seconds that the dictionary is valid for (time to live).
+An empty list for "match-dest" MUST match all destinations.
 
-The "ttl" is independent of the cache lifetime of the resource being used for
-the dictionary. If the underlying resource is evicted from cache then it is
-also removed but this allows for setting an explicit time to live for use as a
-dictionary independent of the underlying resource in cache. Expired resources
-can still be useful as dictionaries while they are in cache and can be used for
-fetching updates of the expired resource. It can also be useful to artificially
-limit the life of a dictionary in cases where the dictionary is updated
-frequently which can help limit the number of possible incoming dictionary
-variations.
+For clients that do not support request destinations, the client MUST treat it
+as an empty list and match all destinations.
 
-The "ttl" value is optional and defaults to 1209600 (14 days).
+The "match-dest" value is optional and defaults to an empty list.
 
 ### id
 
-The "id" value of the Use-As-Dictionary header is a sf-string value that
-specifies a server identifier for the dictionary. If an "id" value is present
-then it MUST be sent to the server in a "Dictionary-ID" request header when
-the dictionary is advertised as being available.
+The "id" value of the Use-As-Dictionary header is a String value that specifies
+a server identifier for the dictionary. If an "id" value is present and has a
+string length longer than zero then it MUST be sent to the server in a
+"Dictionary-ID" request header when the dictionary is advertised as being
+available.
 
 The server identifier MUST be treated as an opaque string by the client.
 
@@ -149,11 +147,11 @@ contents of the dictionary. The dictionary hash MUST be validated before use.
 The "id" value string length (after any decoding) supports up to 1024
 characters.
 
-The "id" value is optional.
+The "id" value is optional and defaults to the empty string.
 
 ### type
 
-The "type" value of the Use-As-Dictionary header is a sf-string value that
+The "type" value of the Use-As-Dictionary header is a Token value that
 describes the file format of the supplied dictionary.
 
 "raw" is the only defined dictionary format which represents an unformatted
@@ -162,7 +160,7 @@ blob of bytes suitable for any compression scheme to use.
 If a client receives a dictionary with a type that it does not understand, it
 MUST NOT use the dictionary.
 
-The "type" value is optional and defaults to "raw".
+The "type" value is optional and defaults to raw.
 
 ### Examples
 
@@ -174,12 +172,11 @@ A response that contained a response header:
 NOTE: '\' line wrapping per RFC 8792
 
 Use-As-Dictionary: \
-  match="/product/*", match-dest="document", ttl=604800
+  match="/product/*", match-dest=("document")
 ~~~
 
 Would specify matching any document request for a URL with a path prefix of
-/product/ on the same {{Origin}} as the original request, and expiring as a
-dictionary in 7 days independent of the cache lifetime of the resource.
+/product/ on the same {{Origin}} as the original request.
 
 #### Versioned Directories
 
@@ -200,8 +197,8 @@ to the request to indicate to the server that it has a dictionary available to
 use for compression.
 
 The "Available-Dictionary" request header is a Structured Field
-{{STRUCTURED-FIELDS}} sf-binary {{SHA-256}} hash of the contents of a single
-available dictionary.
+{{STRUCTURED-FIELDS}} Byte Sequence containing the {{SHA-256}} hash of the
+contents of a single available dictionary.
 
 The client MUST only send a single "Available-Dictionary" request header
 with a single hash value for the best available match that it has available.
@@ -214,12 +211,8 @@ Available-Dictionary: :pZGm1Av0IEBKARczz7exkNYsZb8LzaMrV7J32a2fFG4=:
 
 ### Dictionary freshness requirement
 
-To be considered as a match, the dictionary must not yet be expired as a
-dictionary. When iterating through dictionaries looking for a match, the
-expiration time of the dictionary is calculated by taking the last time the
-dictionary was fetched and adding the "ttl" seconds from the
-"Use-As-Dictionary" response. If the current time is beyond the expiration time
-of the dictionary, it MUST be ignored.
+To be considered as a match, the dictionary resource MUST be either fresh
+[HTTP-CACHING] or allowed to be served stale (see eg [RFC5861]).
 
 ### Dictionary URL matching
 
@@ -237,8 +230,8 @@ algorithm will return TRUE for a successful match and FALSE for no-match:
     * Let DEST be the value of "match-dest" for the given dictionary.
     * Let REQUEST_DEST be the value of the destination for the current
     request.
-    * If DEST is not an empty string and If DEST and REQUEST_DEST are not the
-    same value, return FALSE
+    * If DEST is not an empty list and if REQUEST_DEST is not in the DEST list
+    of destinations, return FALSE
 1. Let BASEURL be the URL of the dictionary request.
 1. Let URL represent the URL of the outbound request being checked.
 1. If the {Origin} of BASEURL and the {Origin} of URL are not the same, return
@@ -269,8 +262,8 @@ appropriate dictionary and the dictionary was stored with a server-provided
 "id" in a "Dictionary-ID" request header.
 
 The "Dictionary-ID" request header is a Structured Field {{STRUCTURED-FIELDS}}
-sf-string of up to 1024 characters (after any decoding) and MUST be identical
-to the server-provided "id".
+String of up to 1024 characters (after any decoding) and MUST be identical to
+the server-provided "id".
 
 For example:
 
@@ -286,8 +279,8 @@ the server MUST send the hash of the dictionary that was used in the
 "Content-Dictionary" response header.
 
 The "Content-Dictionary" response header is a Structured Field
-{{STRUCTURED-FIELDS}} sf-dictionary {{SHA-256}} hash of the contents of the
-dictionary that was used to encode the response.
+{{STRUCTURED-FIELDS}} Byte Sequence containing the {{SHA-256}} hash of the
+contents of the dictionary that was used to encode the response.
 
 If the HTTP response contains a "Content-Dictionary" response header with the
 hash of a dictionary that the client does not have available then the client

draft-ietf-httpbis-connect-tcp.md

@@ -66,7 +66,7 @@ This specification describes an alternative mechanism for proxying TCP in HTTP.
 
 A template-driven TCP transport proxy for HTTP is identified by a URI Template {{!RFC6570}} containing variables named "target_host" and "tcp_port".  The client substitutes the destination host and port number into these variables to produce the request URI.
 
-The "target_host" variable MUST be a domain name, an IP address literal, or a list of IP addresses.  The "tcp_port" variable MUST be a single integer.  If "target_host" is a list (as in {{Section 2.4.2 of !RFC6570}}), the server SHOULD perform the same connection procedure as if these addresses had been returned in response to A and AAAA queries for a domain name.
+The "target_host" variable MUST be a domain name, an IP address literal, or a list of IP addresses.  The "tcp_port" variable MUST be a single integer.  If "target_host" is a list (as in {{Section 3.2.1 of !RFC6570}}), the server SHOULD perform the same connection procedure as if these IP addresses had been returned in response to A and AAAA queries for a domain name.
 
 ## In HTTP/1.1
 
@@ -78,7 +78,7 @@ In HTTP/1.1, the client uses the proxy by issuing a request as follows:
 * The request SHALL include an "Upgrade" header field with the value "connect-tcp".
 * The request's target SHALL correspond to the URI derived from expansion of the proxy's URI Template.
 
-If the request is well-formed and permissible, the proxy MUST attempt the TCP connection before returning its response header.  If the TCP connection is successful, the response SHALL be as follows:
+If the request is well-formed and permissible, the proxy MUST attempt the TCP connection before sending any response status code other than "100 (Continue)" (see {{conveying-metadata}}).  If the TCP connection is successful, the response SHALL be as follows:
 
 * The HTTP status code SHALL be "101 (Switching Protocols)".
 * The response SHALL include a "Connection" header field with the value "Upgrade".
@@ -115,6 +115,8 @@ In HTTP/2 and HTTP/3, the client uses the proxy by issuing an "extended CONNECT"
 
 From this point on, the request and response SHALL conform to all the usual requirements for classic CONNECT proxies in this HTTP version (see {{Section 8.5 of !RFC9113}} and {{Section 4.4 of !RFC9114}}).
 
+A templated TCP proxying request that does not conform to all of these requirements represents a client error (see {{!RFC9110, Section 15.5}}) and may be malformed (see {{Section 8.1.1 of !RFC9113}} and {{Section 4.1.2 of !RFC9114}}).
+
 ~~~
 HEADERS
 :method = CONNECT
@@ -159,7 +161,7 @@ Servers that host a proxy under this specification MAY offer support for TLS ear
 
 ## Conveying metadata
 
-This specification supports the "Expect: 100-continue" request header ({{?RFC9110, Section 10.1.1}}) in any HTTP version.  The "100 (Continue)" status code confirms receipt of a request at the proxy without waiting for the proxy-destination TCP handshake to succeed or fail.  This might be particularly helpful when the destination host is not responding, as TCP handshakes can hang for several minutes before failing.  Implementation of "100 (Continue)" support is OPTIONAL for clients and REQUIRED for proxies.
+This specification supports the "Expect: 100-continue" request header ({{?RFC9110, Section 10.1.1}}) in any HTTP version.  The "100 (Continue)" status code confirms receipt of a request at the proxy without waiting for the proxy-destination TCP handshake to succeed or fail.  This might be particularly helpful when the destination host is not responding, as TCP handshakes can hang for several minutes before failing.  Clients MAY send "Expect: 100-continue", and proxies MUST respect it by returning "100 (Continue)" if the request is not immediately rejected.
 
 Proxies implementing this specification SHOULD include a "Proxy-Status" response header {{!RFC9209}} in any success or failure response (i.e., status codes 101, 2XX, 4XX, or 5XX) to support advanced client behaviors and diagnostics.  In HTTP/2 or HTTP/3, proxies MAY additionally send a "Proxy-Status" trailer in the event of an unclean shutdown.
 

draft-ietf-httpbis-sfbis.md

@@ -35,6 +35,17 @@ author:
 normative:
   HTTP: RFC9110
 
+  UTF8:
+    title: UTF-8, a transformation format of ISO 10646
+    author:
+    - ins: F. Yergeau
+      name: F. Yergeau
+    date: 2003-11
+    seriesinfo:
+      STD: 63
+      RFC: 3629
+    target: http://www.rfc-editor.org/info/std63
+
 informative:
   IEEE754:
     target: https://ieeexplore.ieee.org/document/8766229
@@ -48,16 +59,6 @@ informative:
       DOI:  10.1109/IEEESTD.2019.8766229
       ISBN: 978-1-5044-5924-2
 
-  UTF8:
-    title: UTF-8, a transformation format of ISO 10646
-    author:
-    - ins: F. Yergeau
-      name: F. Yergeau
-    date: 2003-11
-    seriesinfo:
-      STD: 63
-      RFC: 3629
-    target: http://www.rfc-editor.org/info/std63
   RFC9113:
     display: HTTP/2
   HPACK: RFC7541
@@ -229,7 +230,7 @@ For example, field instance might contain a syntactically valid Date ({{date}}),
 
 # Structured Data Types {#types}
 
-This section defines the abstract types for Structured Fields, and summarizes how those types are serialized into textual HTTP fields.
+This section provides an overview of the abstract types that Structured Fields use, and gives a brief description and examples of how each of those types are serialized into textual HTTP fields. {{text}} specifies the details of how they are parsed from and serialized into textual HTTP fields.
 
 In summary:
 
@@ -498,7 +499,7 @@ Parsers MUST support Dates whose values include all days in years 1 to 9999 (i.e
 
 ### Display Strings {#displaystring}
 
-Display Strings are similar to Strings, in that they consist of zero or more characters, but they allow Unicode content, unlike Strings.
+Display Strings are similar to Strings, in that they consist of zero or more characters, but they allow Unicode scalar values (i.e., all Unicode code points except for surrogates), unlike Strings.
 
 Display Strings are intended for use in cases where a value is displayed to end users, and therefore may need to carry non-ASCII content. It is NOT RECOMMENDED that they be used in situations where a String ({{string}}) or Token ({{token}}) would be adequate, because Unicode has processing considerations (e.g., normalization) and security considerations (e.g., homograph attacks) that make it more difficult to handle correctly.
 
@@ -516,7 +517,7 @@ See {{security}} for additional security considerations when handling Display St
 
 # Working with Structured Fields in HTTP {#text}
 
-This section defines how to serialize and parse Structured Fields in textual HTTP field values and other encodings compatible with them (e.g., in HTTP/2 {{RFC9113}} before compression with HPACK {{HPACK}}).
+This section defines how to serialize and parse the abstract types defined by {{types}} into textual HTTP field values and other encodings compatible with them (e.g., in HTTP/2 {{RFC9113}} before compression with HPACK {{HPACK}}).
 
 ## Serializing Structured Fields {#text-serialize}
 
@@ -720,7 +721,7 @@ Given a Date as input_date, return an ASCII string suitable for use in an HTTP f
 Given a sequence of Unicode codepoints as input_sequence, return an ASCII string suitable for use in an HTTP field value.
 
 0. If input_sequence is not a sequence of Unicode codepoints, fail serialization.
-1. Let byte_array be the result of applying UTF-8 encoding ({{Section 3 of UTF8}}) to input_sequence.
+1. Let byte_array be the result of applying UTF-8 encoding ({{Section 3 of UTF8}}) to input_sequence. If encoding fails, fail serialization.
 2. Let encoded_string be a string containing "%" followed by DQUOTE.
 3. For each byte in byte_array:
    1. If byte is %x25 ("%"), %x22 (DQUOTE), or in the ranges %x00-1f or %x7f-ff:
@@ -731,6 +732,8 @@ Given a sequence of Unicode codepoints as input_sequence, return an ASCII string
 4. Append DQUOTE to encoded_string.
 5. Return encoded_string.
 
+Note that {{UTF8}} prohibits the encoding of codepoints between U+D800 and U+DFFF (surrogates); if they occur in input_sequence, serialization will fail.
+
 
 ## Parsing Structured Fields {#text-parse}
 
@@ -1028,7 +1031,7 @@ Please add the following note to the "Hypertext Transfer Protocol (HTTP) Field N
 >
 > 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.
+> field values that refer to it.
 
 Then, add a new column, "Structured Type".
 
@@ -1056,7 +1059,7 @@ The size of most types defined by Structured Fields is not limited; as a result,
 It is possible for parties with the ability to inject new HTTP fields to change the meaning
 of a Structured Field. In some circumstances, this will cause parsing to fail, but it is not possible to reliably fail in all such circumstances.
 
-The Display String type can convey any possible Unicode code point without sanitization; for example, they might contain unassigned code points, control points (including NUL), or noncharacters. Therefore, applications consuming Display Strings need to consider strategies such as filtering or escaping untrusted content before displaying it. See also {{UNICODE-SECURITY}} and {{?I-D.draft-bray-unichars}}.
+The Display String type can convey any possible Unicode code point without sanitization; for example, they might contain unassigned code points, control points (including NUL), or noncharacters. Therefore, applications consuming Display Strings need to consider strategies such as filtering or escaping untrusted content before displaying it. See also {{UNICODE-SECURITY}}.
 
 --- back