Prefer a covering connection and drain the other
06A client can temporarily have two viable connections. A larger Origin Set may make another connection redundant.
With A’s outstanding requests satisfied, the client SHOULD close A. B remains available. Equal sets or incomparable overlapping sets do not meet this particular proper-subset rule.
Source for this drawing: RFC 8336 · Read RFC section 2.4 ↗
New to this? Start hereA quick picture + helpful background
A message needs an address.
Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.
Helpful first, if these ideas are unfamiliar
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Terms in this drawing
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
A proper subset is different from an equal or merely overlapping set.
- Assume both connections are viable and authoritative for the relevant origins. Set A is a proper subset of Set B only if every member of A is in B and B has at least one additional member.
- In this situation, clients SHOULD NOT send new requests on the connection with the smaller Origin Set.
- Outstanding requests can finish there. Clients SHOULD close that connection once all outstanding requests are satisfied; the guide does not abort them early.
- Appendix B encourages useful early advertisements and practical grouping, not a mandatory frame-before-HEADERS rule. Section 4 leaves Origin Set size unbounded; clients can monitor resource use and close a connection if it is excessive.
Appendix A is an illustrative, non-normative algorithm; requirements come from §§ 2.2–2.4. SHOULD is not MUST. No fixed resource cap or complete client scheduling policy is defined here. Offline fictional examples only. The illustrations assume certificate-check results; they do not perform those checks. MUST, SHOULD and MAY retain their RFC meanings; SHOULD exceptions require carefully weighing the implications.
Read the RFC section ↗