]> Zscaler

India santosh.pallagatti@gmail.com

Zscaler

pranjal.sharma@zscaler.com

Web and Internet Transport HTTP HTTP/2 HTTP/3 intermediary connection sharing Intermediaries often carry requests from many unrelated clients over one HTTP/2 or HTTP/3 connection to an origin server. The origin has no way to know this, to say whether it accepts it, or to act on the traffic of one client without disturbing every other client on the connection. This document defines a pair of settings that let an intermediary and an origin agree on whether a connection is shared, a request header field that marks which client a request belongs to, and a frame that lets the origin drain, block, or limit one client on a shared connection. It also states what an intermediary needs to do so that GOAWAY and connection failures reach only the affected client streams. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the HTTP Working Group mailing list (), which is archived at . Source for this draft and an issue tracker can be found at .

Introduction Intermediaries such as forward proxies, CDNs and API gateways commonly carry requests from many unrelated clients over a small number of HTTP/2 or HTTP/3 connections to each origin. Sharing connections this way saves handshakes, connections and latency, and both the intermediary and the origin benefit from it. HTTP/2 and HTTP/3, however, treat a connection as belonging to one client. When a connection is shared, the origin cannot tell the clients on it apart, cannot say whether it accepts sharing, and has no way to act on one client without affecting all of them. describes where this arises and why it matters. This document defines a pair of settings with which an intermediary and an origin agree on whether a connection is shared (), a request header field identifying which requests belong to the same client (), and a frame with which the origin can act on one client (). sets out what an intermediary has to do so that events on a shared connection reach only the clients they affect.

Scope This document applies to HTTP/2 and HTTP/3 connections from an intermediary to an origin. The version a client uses to reach the intermediary does not matter; any combination of HTTP/2 and HTTP/3 on the two sides works the same way. HTTP/1.1 is out of scope, since it cannot carry concurrent requests on one connection. Nothing defined here appears on the client side of the intermediary. Clients need no changes and are not aware of the mechanism.

Motivation and Use Cases

Why Intermediaries Share Connections Intermediaries share upstream connections because doing so is considerably cheaper for both sides than the alternative. Each new connection costs a TLS or QUIC handshake, with public-key operations at both ends and at least one round trip before the first request can be sent. A new connection also starts with a small congestion window. An intermediary that opened one connection per client would multiply these costs by the number of clients using each origin, which for a popular origin can be tens of thousands at a time. Intermediaries also send traffic from a limited set of source addresses. Origins and the load balancers in front of them commonly limit connections per source address, and the intermediary itself can run out of source ports towards a given destination. One connection per client reaches these limits quickly. Origins benefit as well. Fewer, busier connections mean fewer handshakes to perform and less memory held for idle connections. HTTP/2 and HTTP/3 make sharing practical, because a single connection can carry many requests at the same time. With HTTP/1.1, a reused connection could only serve one request after another. As a result, carrying the requests of many clients over one connection has become normal in large intermediaries. This document does not try to discourage it; it aims to make it safe.

Deployment Scenarios

TLS-Inspecting Forward Proxies Many organizations send their users' web traffic through a forward proxy, often operated as a cloud service, that applies security policy such as malware scanning, URL filtering and data-loss prevention. To inspect HTTPS traffic, the proxy terminates the user's TLS connection, using a certificate that the organization's devices are configured to trust. It then makes its own connection to the origin the user asked for. Such a proxy usually serves many organizations at once and sends their traffic out through a shared pool of addresses. When thousands of users from different organizations use the same popular application, the proxy carries their requests over a few connections to that application's origin, each connection interleaving requests from many users who have no relationship with one another. Consider a client that starts sending requests the origin considers abusive: for example, credential-stuffing login attempts, scraping beyond the application's terms, or a misconfigured tool retrying in a tight loop. Each request is well formed and goes to a permitted application, so it passes the proxy's security policy. Only the origin, which knows its own accounts, quotas and application logic, can tell that the traffic is a problem. The origin sees an unusually busy connection from one of the proxy's addresses. Its choices today are to throttle that connection, send GOAWAY, close it, or block the proxy's address. Each of these also affects thousands of other users, mostly from organizations unrelated to the client responsible, who see failed requests, challenge pages or blocks. The proxy knows which client is responsible but has no way to learn what the origin objected to; the origin knows what is wrong but cannot see the client. With this document, the origin asks the proxy to block or limit that one client for a period. The proxy applies this to that client only and can report the event to the client's organization, and the origin never learns who the client is. This scenario is where the problems below are most acute. The proxy is mandated by the organization rather than optional, TLS is terminated in any case, the number of clients per connection is large, and the clients sharing a connection belong to unrelated organizations.

CDNs and Reverse Proxies CDNs and reverse proxies carry requests from many visitors over shared connections to an origin, and some operators document this behavior publicly. The origin is often operated by a different party from the CDN, and has the same lack of visibility into the clients behind each connection.

API Gateways and Service Meshes Within a deployment, gateways and service-mesh proxies forward requests from many callers to backend services over shared connections. Here both ends are usually run by one operator, but the protocol-level problems are the same, and a standard mechanism avoids each deployment inventing its own. Intermediaries that relay traffic using CONNECT or other tunneling methods, where TLS runs end to end between the client and the origin, do not see individual requests and are not in scope.

Problems

Collateral Damage from One Client An origin's defenses against abuse act on a connection or a source address. When that connection or address is shared, a defense aimed at one client lands on all of them. This is not hypothetical. When the HTTP/2 "Rapid Reset" attack was disclosed in 2023, a common mitigation was to close any connection on which a client reset too many streams. On a shared connection, one client triggering that mitigation closes the connection for every client on it.

Unfair Use of a Shared Connection One client with many concurrent requests can consume most of a connection's stream concurrency and flow-control window, delaying every other client on it. The origin can see this happening but cannot limit one client without limiting the connection.

Connection-Bound State Some origins associate state with a connection, such as authentication performed by connection-oriented schemes, session affinity or per-connection rate limits. Such an origin needs each connection to carry one client, but it has no way to tell an intermediary so.

Failures Affect Many Clients When a shared connection receives GOAWAY or fails, requests from many clients fail together. Operators of HTTP/2-to-origin proxies have reported increased client-visible errors for exactly this reason . Correct handling requires the intermediary to work out, for each affected client, which requests the origin processed. HTTP/2 and HTTP/3 express that differently, and no specification describes how to do it.

Why Existing Mechanisms Are Not Enough Using a separate connection for each client avoids the problems but gives up the benefits described in , and does not scale for a large intermediary. GOAWAY (, ) acts on the whole connection. It stops new requests on the connection but cannot single out the requests of one client, so using it against one client drains every client on the connection. It also achieves little: the intermediary moves the affected requests to another connection, the offending client's requests included, and the problem moves with them. GOAWAY does not tell the intermediary which client caused it. Resetting individual streams, for example with ENHANCE_YOUR_CALM or H3_EXCESSIVE_LOAD, stops a single request but does not stop the client from sending more, and to the intermediary it looks no different from any other reset. Fields such as Forwarded tell the origin who the client is. That reveals the client's identity to the origin, which many deployments cannot accept, and still gives the origin no means of acting on one client short of the whole connection. Responding to each unwanted request with 429 (Too Many Requests) does not stop the requests from arriving. The origin still receives and processes each one, and has no way to ask the intermediary to stop sending them. RateLimit header fields inform a client of a quota but do not distinguish clients behind an intermediary. Privacy Pass rate limiting requires every client to take part. Blocking or throttling the intermediary's address is the collateral damage described in . The underlying difficulty is that neither side can solve this alone. The intermediary knows the clients but not the origin's policy or what the origin considers abusive. The origin knows its policy but cannot see the clients. Solving it needs a signal between the two, which is why it needs a standard.

Requirements The mechanism in this document is designed to meet the following requirements:

R1:

An origin can allow, limit or refuse the sharing of a connection ().

R2:

An origin can act on the requests of one client without affecting other clients on the same connection ().

R3:

The origin does not learn the identity of any client, and cannot use the client-group identifier to follow a client across connections (, ).

R4:

The mechanism works for every combination of HTTP/2 and HTTP/3 between client and intermediary and between intermediary and origin ().

R5:

Endpoints that do not implement this document are unaffected.

Conventions and Definitions 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. This document uses the terms "intermediary", "origin server" (or "origin"), "connection" and "request" from . In frame diagrams, a field marked (i) is a variable-length integer as defined in , and "..." indicates that the length of the field varies. Structured Field types are defined in . The following terms are also used:

Shared connection:

An HTTP/2 or HTTP/3 connection from an intermediary to an origin that may carry requests for more than one client group at the same time.

Client group:

The requests that an intermediary attributes to one of its clients. What a client group corresponds to (a client connection, an authenticated user, or something else) is up to the intermediary, but it has to stay the same for as long as that client uses a shared connection.

Client-group identifier:

The integer the intermediary uses for a client group on one shared connection, carried in the Client-Group header field.

Origin key:

The set of properties that decides which upstream connections a request may use. Two requests can share a connection only if their origin keys are equal (). For example, two requests for https://api.example.com that use the same TLS settings have the same origin key, while a request for the same host that has to present a particular user's client certificate has a different one, and so needs a different connection.

Acceptance boundary:

A stream identifier, carried in GOAWAY or GROUP_CONTROL, that separates streams the origin might have processed from streams it has not processed ().

Overview shows three clients reaching one origin through an intermediary. Clients A and C use HTTP/2 and client B uses HTTP/3. Their requests are carried on two shared connections, T1 (HTTP/2) and T2 (HTTP/3).

Client Requests Carried on Shared Connections | |==T1==>| | | Client B |==h3========>| stream map, | h2 | Origin | +----------+ +=====>| connection pool |==T2==>| | | | (by origin key) | h3 +--------+ +----------+ | +--------------------+ | Client C |==h2==+ +----------+ ]]>

An intermediary that may share a connection sends SETTINGS_SHARED_CONNECTION when it opens it, and puts a Client-Group field on every request it sends there. An origin that implements this document answers with SETTINGS_SHARED_CONNECTION_POLICY, giving the number of client groups it will accept on that connection. If the origin needs to deal with one client, it sends GROUP_CONTROL naming that client's group, and the intermediary applies it to that client only. Endpoints that do not implement this document ignore the unknown settings, field and frame type, as HTTP/2 and HTTP/3 already require, and nothing changes for them.

Negotiation Two settings are defined. Each is registered for HTTP/2 () and HTTP/3 () with the same name and meaning.

SETTINGS_SHARED_CONNECTION The intermediary sends SETTINGS_SHARED_CONNECTION (TBD1 in HTTP/2, TBD2 in HTTP/3) with a value of 1 to say that the connection may carry requests for more than one client group. The default is 0. Any value other than 0 or 1 MUST be treated as a connection error of type PROTOCOL_ERROR in HTTP/2 or H3_SETTINGS_ERROR in HTTP/3. Only the client end of a connection sends this setting. A client that receives it from a server MUST ignore it. An intermediary that sends SETTINGS_SHARED_CONNECTION with a value of 1 MUST support the Client-Group field () and the GROUP_CONTROL frame ().

SETTINGS_SHARED_CONNECTION_POLICY An origin that implements this document sends SETTINGS_SHARED_CONNECTION_POLICY (TBD3 in HTTP/2, TBD4 in HTTP/3). The value is the largest number of client groups the origin accepts on the connection, with two special cases: 0 means there is no limit, and 1 means the connection is not to be shared at all. There is no default. If the setting is absent, the origin does not implement this document. Only the server end sends it; a server MUST ignore it if a client sends it. An origin SHOULD send this setting only when it has received SETTINGS_SHARED_CONNECTION with a value of 1. Because an HTTP/2 server can send its first SETTINGS frame before it sees the client's, an origin MAY instead send it on every connection. An intermediary that did not send SETTINGS_SHARED_CONNECTION ignores it.

Procedures An intermediary that may share a connection MUST include SETTINGS_SHARED_CONNECTION with a value of 1 in the first SETTINGS frame it sends, and MUST include a Client-Group field in every request it sends on the connection from the first request onwards. Both HTTP/2 and HTTP/3 let a client send requests before the server's SETTINGS arrive, and with TLS early data or QUIC 0-RTT a request can go out in the very first flight. To keep that, the intermediary does not wait for the origin's SETTINGS before sending requests. It does, however, limit itself to one client group until they arrive: until it has received the origin's first SETTINGS frame, the intermediary MUST NOT send requests for more than one client group on the connection. A single client group is not sharing, so no policy can be broken, and it is also what an origin that sends a policy of 1 allows. If the origin's first SETTINGS frame does not contain SETTINGS_SHARED_CONNECTION_POLICY, the origin does not implement this document. The intermediary MUST stop sending the Client-Group field on that connection. Whether it shares the connection anyway is a local matter, as it is today. If the origin sends a policy value N greater than zero, the intermediary MUST NOT have requests for more than N client groups in progress on the connection at any time. Neither setting changes after the first SETTINGS frame. In HTTP/2, a SETTINGS frame that changes either value MUST be treated as a connection error of type PROTOCOL_ERROR. An origin that wants a different policy sends GOAWAY and uses the new policy on later connections. HTTP/3 does not allow settings to change, so this keeps the two versions aligned.

The Client-Group Header Field Client-Group is a request header field carrying the client-group identifier. It is an Item Structured Field whose value is an Integer between 0 and 4294967295 inclusive. No parameters are defined, and unknown parameters MUST be ignored.

Request Carrying a Client-Group Field

The field is sent once per request, in the request's header section. It is not sent in trailers. Each request travels on its own stream, so a client with several requests in progress has the same Client-Group value on each of those streams, and requests from different clients are on different streams with different values. Identifiers MUST be chosen at random from the full range. They MUST NOT come from a counter or be derived from anything that identifies the client, such as its credentials or network address. A counter would tell the origin how many clients the intermediary has and the order in which they arrived. An identifier MUST be unique among the client groups that have requests in progress on the connection, and MUST be the same for every request of a given client group on that connection. The same client group SHOULD get an unrelated identifier on each connection, so that the origin cannot use it to follow a client from one connection to another. An identifier MAY be reused for another client group once the previous group has no requests in progress and the intermediary has released it. An identifier has meaning only on the connection where it was sent. The intermediary MUST remove any Client-Group field from requests it receives from clients. Otherwise a client could pick, or impersonate, a group. Client-Group only appears in requests. Responses are matched to requests by stream, as usual. An origin MUST NOT send Client-Group in a response, and an intermediary MUST remove it from any response before forwarding. Client-Group carries no confidential information and can be compressed like any other field.

The GROUP_CONTROL Frame An origin sends GROUP_CONTROL to tell the intermediary to act on one client group. A response header field would not work here: the origin may need to act when it has no response to send for that group, and the intermediary needs an acceptance boundary to know which of the group's requests were processed. An origin MUST NOT send GROUP_CONTROL unless it has received SETTINGS_SHARED_CONNECTION with a value of 1 and has sent SETTINGS_SHARED_CONNECTION_POLICY.

HTTP/2 Frame In HTTP/2, GROUP_CONTROL is an extension frame () of type TBD5. It is sent on stream 0, which HTTP/2 uses for frames that concern the connection rather than a single request; like GOAWAY, GROUP_CONTROL can affect several streams at once. The frame defines no flags. It uses the common HTTP/2 frame header (), followed by the payload shown in .

HTTP/2 GROUP_CONTROL Frame Payload

Client-Group:

The client-group identifier () the frame applies to.

Value:

A parameter whose meaning depends on the action ().

Action:

The action to apply ().

R:

A reserved bit. It MUST be set to zero when sending and MUST be ignored when receiving.

Boundary:

The acceptance boundary for the named group (). It works like the Last-Stream-ID field of an HTTP/2 GOAWAY frame, but only for streams of that group.

A GROUP_CONTROL frame on a stream other than 0 MUST be treated as a connection error of type PROTOCOL_ERROR. The payload has a fixed size of 13 octets; a GROUP_CONTROL frame of any other length MUST be treated as a connection error of type FRAME_SIZE_ERROR.

HTTP/3 Frame In HTTP/3, GROUP_CONTROL is a frame of type TBD6 and is only sent on the control stream, which plays the role that stream 0 plays in HTTP/2. It uses the common HTTP/3 frame layout (), with Type and Length followed by the payload shown in .

HTTP/3 GROUP_CONTROL Frame Payload

The fields are in the same order and, apart from Boundary, have the same size and meaning as in HTTP/2 (). Boundary carries a QUIC stream identifier, which can be up to 62 bits long. As with the Stream ID field of the HTTP/3 GOAWAY frame, it is encoded as a variable-length integer (), so the number of bytes it takes on the wire depends on its value. It works like the Stream ID field of a GOAWAY frame sent by an HTTP/3 server, but only for streams of the named group (). Receiving GROUP_CONTROL on any stream other than the control stream MUST be treated as a connection error of type H3_FRAME_UNEXPECTED. A frame that cannot be parsed, or that has data left over after the last field, MUST be treated as a connection error of type H3_FRAME_ERROR.

Actions The Action field holds one of the values in . GROUP_CONTROL Actions

Code	Action	Value	Effect
0x00	GOAWAY	0 or 1	Stop sending this group on this connection
0x01	BLOCK	seconds (1-86400)	Stop sending this client to this origin key for a time
0x02	LIMIT	streams (1 or more)	Cap this client's concurrent requests to this origin key
0x03	CLEAR	ignored	Lift a BLOCK or end a LIMIT

GOAWAY applies to the connection the frame arrived on. BLOCK and LIMIT apply to the client behind the group on every connection the intermediary has with the same origin key (); otherwise a blocked client could simply be moved to another connection. The intermediary MUST ignore a GROUP_CONTROL frame with an Action it does not recognize, and one that names a client-group identifier not in use on the connection. New actions can be added through the registry in .

GOAWAY GOAWAY moves one client off the connection. On receiving it, the intermediary stops sending requests for that group on the connection and sends the client's later requests on another suitable connection. If Value is 1, that other connection must carry no other client group: the origin is asking for the client to be given a connection of its own, for example because it keeps per-connection state for that client. More precisely, the intermediary MUST NOT send any further request for the named group on the connection. Requests of the group already in progress are handled according to the acceptance boundary (). Later requests from the client SHOULD be sent on another suitable connection. If Value is 1, the intermediary MUST from then on send that client's requests for this origin key only on a connection that carries no other client group. A Value other than 0 or 1 MUST be treated as 0. Other client groups on the connection are not affected. An origin MAY send GOAWAY for the same group more than once, but the Boundary MUST NOT increase between frames.

BLOCK On receiving BLOCK, the intermediary MUST NOT send requests from that client to any connection with the same origin key for Value seconds. In the meantime it SHOULD answer those requests itself with a 429 (Too Many Requests) response carrying a Retry-After field (). BLOCK does not affect requests already in progress; describes how the origin stops those. A Value of 0 or above 86400 is invalid, and the intermediary MUST ignore a BLOCK frame carrying one. A new BLOCK for the same client replaces the previous one.

LIMIT On receiving LIMIT, the intermediary MUST NOT have more than Value requests from that client in progress across all connections with the same origin key. It can queue excess requests for a bounded time or refuse them, but MUST NOT buffer them without limit. A Value of 0 is invalid and the frame MUST be ignored. A LIMIT has no expiry: it lasts until CLEAR is received or the client no longer has requests to this origin key through the intermediary. A new LIMIT replaces the previous one.

CLEAR CLEAR lets the origin undo its own restrictions. It lifts a BLOCK before it expires, for example when the abuse has stopped, and it is the only way for the origin to end a LIMIT. On receiving CLEAR, the intermediary removes any BLOCK or LIMIT in force for the client and origin key. CLEAR does not undo a GOAWAY.

Acceptance Boundary For the GOAWAY action, the Boundary field tells the intermediary which of the group's requests the origin might have processed. It covers only streams of the named group and follows the GOAWAY rule of the HTTP version of the connection. Note that the two versions express the boundary in opposite ways: HTTP/2 gives the last stream that might have been processed, and HTTP/3 gives the first stream that will not be. Acceptance Boundary

	HTTP/2	HTTP/3
Might have been processed	ID <= Boundary	ID < Boundary
Not processed	ID > Boundary	ID >= Boundary

The intermediary MUST apply the rule for the version of the connection the frame was received on. For actions other than GOAWAY the origin SHOULD set Boundary to 0, and the intermediary MUST ignore it. A request that the boundary shows was not processed can be retried whatever its method (, ). The intermediary MAY retry it on another suitable connection. If it does not, it MUST reset the client stream with REFUSED_STREAM (HTTP/2) or H3_REQUEST_REJECTED (HTTP/3), so that the client knows it can retry. Requests that might have been processed are allowed to complete.

Stopping Requests in Progress GROUP_CONTROL does not reset streams. An origin that wants to stop some or all of a group's requests in progress, for instance together with a BLOCK, resets those streams itself, with RST_STREAM in HTTP/2 or a QUIC RESET_STREAM frame in HTTP/3, as it would on any connection. It knows which streams belong to the group from their Client-Group fields. The error code says what the client can safely do: REFUSED_STREAM or H3_REQUEST_REJECTED for a request the origin did not process, and CANCEL or H3_REQUEST_CANCELLED for one it might have processed. The origin can send GROUP_CONTROL and the resets together. Requests the intermediary sent before it received a BLOCK may still reach the origin afterwards; the origin refuses them in the same way. The intermediary relays each reset to the matching client stream, using the client connection's error code ().

Error Handling An origin that receives GROUP_CONTROL MUST treat it as a connection error of type PROTOCOL_ERROR (HTTP/2) or H3_FRAME_UNEXPECTED (HTTP/3). An intermediary that receives GROUP_CONTROL on a connection where it did not send SETTINGS_SHARED_CONNECTION with a value of 1 MUST treat it as a connection error of the same type. (An intermediary that does not implement this document simply ignores the unknown frame type.)

Relationship to GOAWAY and Stream Resets GROUP_CONTROL does not replace anything. An origin that wants to retire a whole connection still sends an ordinary GOAWAY, and a single stream is still reset with RST_STREAM or RESET_STREAM. Every implementation already understands those, and a second way of doing either would only invite conflicting signals. GROUP_CONTROL covers the case in between: one client on a connection that carries several.

Intermediary Requirements This section applies to an intermediary that sends SETTINGS_SHARED_CONNECTION with a value of 1. Its purpose is to make sure that an event on a shared connection reaches the clients it affects, and only those.

Origin Key An intermediary MUST NOT send two requests on the same shared connection unless they have the same:

• scheme, host and port;
• TLS server name;
• certificate validation policy for the origin, including trust anchors and pinning;
• client certificate presented to the origin, if any;
• application protocol (h2 or h3); and
• required protocol extensions, such as Extended CONNECT (, ) or HTTP Datagrams .

It MAY add more attributes, for example a tenant identifier, an inspection policy or a regional constraint. When it serves tenants that do not trust each other, it SHOULD include the tenant, which limits what one tenant can learn from shared compression state. Requests that rely on state bound to the connection, such as connection-oriented authentication or a client certificate belonging to one user, MUST NOT be sent on a connection shared with another client group.

Request Handling Sharing a connection does not merge requests. Each request keeps its own header section and travels on its own stream, and a field received from one client MUST NOT be added to a request of another client group. As for any intermediary, connection-specific fields such as Connection, Keep-Alive, Proxy-Connection, Transfer-Encoding and Upgrade are removed before forwarding (, , ), and fields addressed to the intermediary itself, such as Proxy-Authorization, are consumed rather than forwarded. Fields that carry a client's credentials, such as Cookie and Authorization, are forwarded only on that client's requests and are subject to the compression rules in . Requests a client sent in TLS early data or QUIC 0-RTT MUST NOT be put on a shared connection unless the intermediary has decided that replay is safe; the Early-Data field and the 425 status code apply. Server push SHOULD be turned off on shared connections.

Stream Map For each request on a shared connection, the intermediary MUST keep track of the client connection and stream, the shared connection and upstream stream, the client-group identifier, and how far the request has got: whether the request header section has been sent, whether the request content is complete and can be sent again, and whether a response header section has been received and forwarded. Stream identifiers are assigned separately on each connection and are never copied across.

Connection States A shared connection is in one of three states. It is ACTIVE once the handshake is done, and new requests can be placed on it; until the origin's SETTINGS arrive, those requests come from at most one client group (). It becomes DRAINING when a GOAWAY is received or the intermediary decides to retire it; no new requests are placed on it, and those in progress are handled as in . It is CLOSED when it has ended, at which point every request still in the stream map is completed, retried or failed as in . Moving from ACTIVE to DRAINING MUST be atomic with respect to placing requests, so that nothing is placed on a connection after the intermediary has processed a GOAWAY for it.

Connection-Wide GOAWAY When a GOAWAY arrives on a shared connection, the intermediary moves it to DRAINING and applies the boundary in to every request in progress, using the stream map to find the client stream for each. Requests that were not processed are retried or refused as described in ; the rest are allowed to finish. An intermediary MUST NOT close a client connection, or send GOAWAY on it, only because a shared connection carrying some of its streams is draining. For planned rotation, origins SHOULD use the two-step GOAWAY described in and , so that no request is caught in flight.

Connection Failure When a shared connection ends without a GOAWAY, because of a transport reset, an idle timeout or a load balancer closing it, there is no boundary to go on. For each request in the stream map the intermediary MAY send it on another suitable connection if no part of it had been sent on the failed one. It MAY retry it once if the method is idempotent (), no response header section was received, and the content can be sent again. Otherwise it MUST NOT retry: it resets the client stream with INTERNAL_ERROR (HTTP/2) or H3_INTERNAL_ERROR (HTTP/3), or, if no response has started, sends an error response with a Proxy-Status field using the "connection_terminated" error type. An intermediary MUST NOT reset a client stream with REFUSED_STREAM or H3_REQUEST_REJECTED unless it knows the origin did not process the request. Clients take those codes as permission to retry any request, including a non-idempotent one. While no suitable connection is available, the intermediary MUST put a bound on how much request content it buffers and on how long it waits, and SHOULD reconnect with exponential backoff. It SHOULD limit the number of client streams per shared connection, and MAY keep more than one shared connection per origin key, so that a single failure affects fewer clients.

Different HTTP Versions on the Two Sides A client and the shared connection carrying its requests can use different HTTP versions. For example, a client using HTTP/3 can be carried on an HTTP/2 shared connection, or the other way round. Three rules cover this. First, the settings, the Client-Group field and the GROUP_CONTROL frame exist only on the shared connection. Whatever version a client uses, its requests are tagged and controlled in the same way. Second, when something that happens on the shared connection affects a client's request, such as a stream reset or a GOAWAY, the intermediary tells the client using the error code of the client's own connection, translated as in . For example, a request refused with REFUSED_STREAM on an HTTP/2 shared connection is reported to an HTTP/3 client as H3_REQUEST_REJECTED. Third, an acceptance boundary is always read with the rule of the shared connection's version (), never the client's. Stream Error Codes

HTTP/2	HTTP/3	Meaning
REFUSED_STREAM	H3_REQUEST_REJECTED	Not processed; safe to retry
CANCEL	H3_REQUEST_CANCELLED	Cancelled; might have been processed
INTERNAL_ERROR	H3_INTERNAL_ERROR	Failure at the peer or intermediary
ENHANCE_YOUR_CALM	H3_EXCESSIVE_LOAD	Peer overloaded
CONNECT_ERROR	H3_CONNECT_ERROR	Tunnel failed

Two practical differences are worth noting. Stream limits are expressed differently: HTTP/2 uses SETTINGS_MAX_CONCURRENT_STREAMS, while HTTP/3 relies on the cumulative MAX_STREAMS credit of QUIC , and the intermediary has to enforce the sharing policy and LIMIT against whichever applies. And packet loss on an HTTP/2 shared connection holds up every stream on it, including those of HTTP/3 clients that would not otherwise be affected; intermediaries SHOULD keep such connections lightly loaded, or use HTTP/3 to the origin where it is available.

Security Considerations

Shared Compression State Putting requests from clients that do not trust each other on one connection exposes them to compression attacks (, ). On shared connections, intermediaries MUST send sensitive fields such as Cookie and Authorization as never-indexed literals, MUST NOT turn a never-indexed field received from a client into an indexed one, and SHOULD keep tenants on separate connections.

Forged Groups and Actions A client cannot choose its group, because the intermediary strips Client-Group from client requests. A client cannot send GROUP_CONTROL either, because the frame only exists on the intermediary-to-origin connection and the intermediary only accepts it from the origin.

Misbehaving Origins An origin can only use GROUP_CONTROL against requests addressed to itself. BLOCK and LIMIT are tied to an origin key and MUST NOT be applied to any other origin, and BLOCK is capped at 86400 seconds. An intermediary MAY apply its own limits to the actions it honors.

Retry Safety If REFUSED_STREAM or H3_REQUEST_REJECTED were used for a request the origin had in fact processed, clients would repeat it, non-idempotent or not. Origins therefore need to choose reset codes accurately (), and intermediaries follow the acceptance boundary and the rules in .

Denial of Service When many clients share a connection, the origin's connection-level defenses land on all of them. This document gives the origin a way to target one client instead. Intermediaries SHOULD also stop any single client group from using more than a fair share of a connection's stream concurrency and flow-control window.

Downgrade The settings and the frame are protected by TLS or QUIC, so an on-path attacker cannot remove them. An endpoint that does not implement this document behaves exactly as it would without it.

Privacy Considerations Client-group identifiers are random, local to one connection, and not derived from who the client is. The origin learns which requests on a connection come from the same client and how many groups are active, but not who the clients are, and it cannot recognize a client across connections by its identifier. That is less than Forwarded already discloses. The origin can still correlate requests of one group within a connection. An intermediary that does not want this can make each client connection its own group.

IANA Considerations RFC Editor: please replace TBD1 to TBD6 throughout this document with the values assigned by IANA, and remove this note.

HTTP/2 Settings IANA is asked to add the following to the "HTTP/2 Settings" registry :

Code	Name	Initial Value	Reference
TBD1	SHARED_CONNECTION	0	This document
TBD3	SHARED_CONNECTION_POLICY	N/A	This document

HTTP/3 Settings IANA is asked to add the following to the "HTTP/3 Settings" registry :

Value	Setting Name	Default	Status	Reference
TBD2	SETTINGS_SHARED_CONNECTION	0	permanent	This document
TBD4	SETTINGS_SHARED_CONNECTION_POLICY	N/A	permanent	This document

HTTP/2 Frame Type IANA is asked to add the following to the "HTTP/2 Frame Type" registry :

Code	Frame Type	Reference
TBD5	GROUP_CONTROL	This document

HTTP/3 Frame Type IANA is asked to add the following to the "HTTP/3 Frame Types" registry :

Value	Frame Type	Status	Reference
TBD6	GROUP_CONTROL	permanent	This document

HTTP Field Name IANA is asked to add the following to the "Hypertext Transfer Protocol (HTTP) Field Name Registry" ():

Field Name:

Client-Group

Status:

permanent

Structured Type:

Item

Reference:

This document

GROUP_CONTROL Actions IANA is asked to create a registry called "HTTP GROUP_CONTROL Actions" in the "Hypertext Transfer Protocol (HTTP) Parameters" group. The policy is Specification Required (). Each entry has a code between 0x00 and 0xff (so that it fits the HTTP/2 Action field), a name, a description of the Value field, and a reference. The initial entries are those in .

References Normative References The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes. This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230. This specification describes an optimized expression of the semantics of the Hypertext Transfer Protocol (HTTP), referred to as HTTP version 2 (HTTP/2). HTTP/2 enables a more efficient use of network resources and a reduced latency by introducing field compression and allowing multiple concurrent exchanges on the same connection. This document obsoletes RFCs 7540 and 8740. The QUIC transport protocol has several features that are desirable in a transport for HTTP, such as stream multiplexing, per-stream flow control, and low-latency connection establishment. This document describes a mapping of HTTP semantics over QUIC. This document also identifies HTTP/2 features that are subsumed by QUIC and describes how HTTP/2 extensions can be ported to HTTP/3. This document defines the core of the QUIC transport protocol. QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances. Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion control algorithm. This specification defines HPACK, a compression format for efficiently representing HTTP header fields, to be used in HTTP/2. This specification defines QPACK: a compression format for efficiently representing HTTP fields that is to be used in HTTP/3. This is a variation of HPACK compression that seeks to reduce head-of-line blocking. This document describes a set of data types and associated algorithms that are intended to make it easier and safer to define and handle HTTP header and trailer fields, known as "Structured Fields", "Structured Headers", or "Structured Trailers". It is intended for use by specifications of new HTTP fields. This document obsoletes RFC 8941. This document specifies additional HyperText Transfer Protocol (HTTP) status codes for a variety of common situations. [STANDARDS-TRACK] Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. Using TLS early data creates an exposure to the possibility of a replay attack. This document defines mechanisms that allow clients to communicate with servers about HTTP requests that are sent in early data. Techniques are described that use these mechanisms to mitigate the risk of replay. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References This document defines an HTTP extension header field that allows proxy components to disclose information lost in the proxying process, for example, the originating IP address of a request or IP address of the proxy on the user-agent-facing interface. In a path of proxying components, this makes it possible to arrange it so that each subsequent component will have access to, for example, all IP addresses used in the chain of proxied HTTP requests. This document also specifies guidelines for a proxy administrator to anonymize the origin of a request. This document specifies the ORIGIN frame for HTTP/2, to indicate what origins are available on a given connection. This document defines a mechanism for running the WebSocket Protocol (RFC 6455) over a single stream of an HTTP/2 connection. This document defines the Proxy-Status HTTP response field to convey the details of an intermediary's response handling, including generated errors. The mechanism for running the WebSocket Protocol over a single stream of an HTTP/2 connection is equally applicable to HTTP/3, but the HTTP-version-specific details need to be specified. This document describes how the mechanism is adapted for HTTP/3. This document describes HTTP Datagrams, a convention for conveying multiplexed, potentially unreliable datagrams inside an HTTP connection. In HTTP/3, HTTP Datagrams can be sent unreliably using the QUIC DATAGRAM extension. When the QUIC DATAGRAM frame is unavailable or undesirable, HTTP Datagrams can be sent using the Capsule Protocol, which is a more general convention for conveying data in HTTP connections. HTTP Datagrams and the Capsule Protocol are intended for use by HTTP extensions, not applications. The ORIGIN frame for HTTP/2 is equally applicable to HTTP/3, but it needs to be separately registered. This document describes the ORIGIN frame for HTTP/3. This document describes Oblivious HTTP, a protocol for forwarding encrypted HTTP messages. Oblivious HTTP allows a client to make multiple requests to an origin server without that server being able to link those requests to the client or to identify the requests as having come from the same client, while placing only limited trust in the nodes used to forward the messages. Nokia Citrix Systems, Inc. Orange Team Digitale, Italian Government Servers often rate-limit incoming requests, for example, rate-limit based upon the source IP address to provide equitable service to clients. However, oblivious HTTP removes the ability for the server to distinguish amongst clients so the server can only rate-limit traffic from an Oblivious Relay Resource. This harms all clients behind that Oblivious Relay Resource. This specification enables a server to convey rate-limit information to an Oblivious Relay Resource, which can use it to apply rate-limit policies on clients. Cooperating Oblivious Relay Resources can thus provide more equitable service to their distinguishable clients without impacting on all clients behind that Oblivious Relay Resource. Team Digitale, Italian Government Red Hat Microsoft This document defines the RateLimit-Policy and RateLimit HTTP header fields for servers to advertise their quota policies and the current service limits, thereby allowing clients to avoid being throttled. Google LLC Fastly Apple Inc. Google LLC Cloudflare This document specifies a variant of the Privacy Pass issuance protocol that allows for tokens to be rate-limited on a per-origin basis. This enables origins to use tokens for use cases that need to restrict access from anonymous clients. CVE Program Google LLC Cloudflare HTTP intermediaries sometimes need to terminate long-lived request streams in order to facilitate load balancing or impose data limits. However, Web browsers commonly cannot retry failed proxied requests when they cannot ascertain whether an in-progress request was acted on. To avoid user-visible failures, it is best for the intermediary to inform the client of upcoming request stream terminations in advance of the actual termination so that the client can wrap up existing operations related to that stream and start sending new work to a different stream or connection. This document specifies a new "WRAP_UP" capsule that allows a proxy to instruct a client that it should not start new requests on a tunneled connection, while still allowing it to finish existing requests.

Examples The examples below use HTTP/2 on the shared connection and follow the layout of . Frames sent by the intermediary are on the left and frames sent by the origin on the right. Clients A and B share the connection as client groups 48213 and 907.

Blocking One Client Client B is flooding the origin with POST requests, three of which are in progress on streams 39, 43 and 45. The origin has processed stream 39 but not 43 or 45. It blocks client B for 60 seconds and resets B's streams. Client A's request on stream 37 is not affected.

Blocking One Client

Client B uses HTTP/3, so the intermediary resets the client stream that carried stream 39 with H3_REQUEST_CANCELLED, telling B that the request might have been processed, and the client streams that carried 43 and 45 with H3_REQUEST_REJECTED, telling B that they were not and can be retried. For the next 60 seconds it answers B's requests to this origin itself with 429 and a Retry-After field. Client A receives its 200 response as normal.

Moving One Client Off a Connection The origin wants client B on a connection of its own. B has requests in progress on streams 39, 43 and 45, and the origin has accepted those up to stream 43.

Moving One Client Off a Connection

Streams 39 and 43 are at or below the boundary and complete on this connection. Stream 45 is above it, so the origin did not process it; the intermediary sends that request again on a new connection that carries only client B, and sends B's later requests to this origin there as well. Client A carries on using the original connection.

Related Work The closest earlier proposal the authors are aware of is , which lets a target ask an Oblivious HTTP relay to rate-limit an offending client without learning who it is, using RateLimit fields in a response. The goal is similar. The setting is not: Oblivious HTTP encapsulates each request separately and does not share a connection, the signal can only travel on a response, and there is no negotiation, tagging, boundary or drain. RateLimit fields describe quota to a client and do not distinguish clients behind an intermediary. An origin can keep sending them on responses to a client group, and the intermediary forwards them as usual. LIMIT in this document controls concurrency, not rate, so the two fit together. The WRAP_UP capsule lets an intermediary tell a client that one long-lived stream, such as a tunnel, is about to end. Its introduction makes the same point as : a gateway that maps client requests onto a pool of origin connections should not send GOAWAY to clients just because one origin connection is closing. An intermediary could use WRAP_UP toward clients whose tunnels run on a draining shared connection or on a group that received GROUP_CONTROL GOAWAY. The ORIGIN frame (, ) controls which origins share a connection, not which clients.

Acknowledgments TODO acknowledge.