Merge branch 'main' into bemasc-abrupt-tls

Author: bemasc

draft-ietf-httpbis-incremental.md

@@ -26,6 +26,7 @@ author:
 normative:
 
 informative:
+  EXTRA-STATUS: RFC6585
   PROXY-STATUS: RFC9209
   SSE:
     target: https://html.spec.whatwg.org/multipage/server-sent-events.html
@@ -58,12 +59,12 @@ the server continually sends notifications as they become available.
 
 In the case of Chunked Oblivious HTTP Messages
 {{?CHUNKED-OHTTP=I-D.ietf-ohai-chunked-ohttp}}, the client opens an HTTP request
-and incrementally sends application messages, while the server can start responding
+and incrementally sends application data, while the server can start responding
 even before the HTTP request is fully complete. In this way, the HTTP
 request-response pair could create what is, in effect, a bi-directional
 communication channel.
 
-Applications that rely on incremental delivery of messages are fragile when HTTP intermediaries are involved.
+Applications that rely on incremental delivery of data are fragile when HTTP intermediaries are involved.
 This is because HTTP intermediaries are not only permitted but are frequently
 deployed to buffer complete HTTP messages before forwarding them downstream
 ({{Section 7.6 of HTTP}}).
@@ -114,6 +115,11 @@ arrive. As the Incremental header field indicates only how the message content i
 to be forwarded, intermediaries can still buffer the entire header and trailer
 sections of the message before forwarding them downstream.
 
+The request to use incremental forwarding also applies to HTTP implementations.
+Though most HTTP APIs provide the ability to incrementally transfer message content,
+those that do not for any reason, SHOULD use the presence of the Incremental
+header field to reduce or disable buffering.
+
 The Incremental HTTP header field applies to each HTTP message. Therefore, if
 both the HTTP request and response need to be forwarded incrementally, the
 Incremental HTTP header field MUST be set for both the HTTP request and the
@@ -148,8 +154,9 @@ is reached. This approach helps balance the processing of different types of
 requests and maintains service availability across all requests.
 
 When rejecting incremental requests due to reaching the concurrency limit,
-intermediaries SHOULD respond with a 503 Service Unavailable error, accompanied
-by a connection_limit_reached Proxy-Status response header field
+intermediaries SHOULD respond with a 429 Too Many Requests error
+({{Section 4 of EXTRA-STATUS}}),
+accompanied by a connection_limit_reached Proxy-Status response header field
 ({{Section 2.3.12 of PROXY-STATUS}}).
 
 For performance and efficiency reasons, a small amount of buffering might be

draft-ietf-httpbis-layered-cookies.md

@@ -520,9 +520,6 @@ represented as the number of seconds until the cookie expires. The user agent is
 not required to retain the cookie for the specified duration. In fact, user
 agents often evict cookies due to memory pressure or privacy concerns.
 
-NOTE: Some existing user agents do not support the Max-Age attribute. User
-agents that do not support the Max-Age attribute ignore the attribute.
-
 If a cookie has both the Max-Age and the Expires attribute, the Max-Age
 attribute has precedence and controls the expiration date of the cookie. If a
 cookie has neither the Max-Age nor the Expires attribute, the user agent
@@ -679,10 +676,10 @@ This helps developers and server operators to know that the cookie was set using
 a `Set-Cookie` header, and is limited in scope to HTTP requests.
 
 
-#### The "__HostHttp-" prefix
+#### The "__Host-Http-" prefix
 
 If a cookie's name begins with a case-sensitive match for the string
-`__HostHttp-`, then the cookie will have been set with a `Secure` attribute, an
+`__Host-Http-`, then the cookie will have been set with a `Secure` attribute, an
 `HttpOnly` attribute, a `Path` attribute with a value of `/`, and no `Domain` attribute.
 
 This helps developers and server operators to know that the cookie was set using
@@ -1305,7 +1302,7 @@ boolean _httpOnlyAllowed_, boolean _allowNonHostOnlyCookieForPublicSuffix_, and
 
 1. If _cookie_'s name, byte-lowercased, starts with `__http-` and _cookie_ is not Http-prefix compatible, then return null.
 
-1. If _cookie_'s name, byte-lowercased, starts with `__hosthttp-` and _cookie_ is not both Host-prefix compatible and Http-prefix compatible, then return null.
+1. If _cookie_'s name, byte-lowercased, starts with `__host-http-` and _cookie_ is not both Host-prefix compatible and Http-prefix compatible, then return null.
 
 1. If _cookie_'s name is the empty byte sequence and one of the following is true:
 
@@ -1315,7 +1312,7 @@ boolean _httpOnlyAllowed_, boolean _allowNonHostOnlyCookieForPublicSuffix_, and
 
     * _cookie_'s value, byte-lowercased, starts with `__http-`, or
 
-    * _cookie_'s value, byte-lowercased, starts with `__hosthttp-`,
+    * _cookie_'s value, byte-lowercased, starts with `__host-http-`,
 
    then return null.
 

draft-ietf-httpbis-no-vary-search.md

@@ -131,7 +131,7 @@ And if the resource instead wants to take an allowlist-based approach, where onl
 No-Vary-Search: params, except=("productId")
 ~~~~
 
-{{header-definition}} defines the header, using the {{STRUCTURED-FIELDS}} framework. {{data-model}} and {{parsing}} illustrate the data model for how the header can be represented in specifications, and the process for parsing the raw output from the structured field parser into that data model. {{comparing}} gives the key algorithm for comparing if two URLs are equivalent under the influence of the header; notably, it leans on the decomposition of the query component into keys and values given by the [application/x-www-form-urlencoded](https://url.spec.whatwg.org/#concept-urlencoded) format specified in {{WHATWG-URL}}. Finally, {{caching}} explains how to modify {{HTTP-CACHING}} to take into account this new equivalence.
+{{header-definition}} defines the header, using the {{STRUCTURED-FIELDS}} framework. {{data-model}} and {{parsing}} illustrate the data model for how the header can be represented in specifications, and the process for parsing the raw output from the structured field parser into that data model. {{comparing}} gives the key algorithm for comparing if two URLs are equivalent under the influence of the header; notably, it leans on the decomposition of the query component into keys and values given by the [application/x-www-form-urlencoded](https://url.spec.whatwg.org/#concept-urlencoded) format specified in {{WHATWG-URL}}. (As such, this header is not useful for URLs whose query component does not follow that format.) Finally, {{caching}} explains how to modify {{HTTP-CACHING}} to take into account this new equivalence.
 
 # Conventions and Definitions
 
@@ -485,4 +485,12 @@ Comments
 # Acknowledgments
 {:numbered="false"}
 
-TODO acknowledge.
+This document benefited from valuable reviews and suggestions by:
+
+* Adam Rice
+* Julian Reschke
+* Kevin McNee
+* Liviu Tinta
+* Mark Nottingham
+* Martin Thomson
+* Valentin Gosu