Summary

  • Under RFC 9110, a client may send Upgrade to invite a same-connection protocol change, but a server may ignore it. An intermediary must remove the received connection-specific field before forwarding and can issue a separate hop-specific invitation with its own Connection option.
  • Evidence of a completed transition begins with a valid 101 Switching Protocols response selecting an offered protocol, and continues through completion of the original request and a valid exchange in the new protocol.

Imagine a migration dashboard that sees Upgrade: websocket in a client request and immediately marks the session “WebSocket enabled.” Between the client and origin, however, a proxy obeys the Connection field and removes the hop-specific invitation. The origin never sees it and returns an ordinary 200 OK over HTTP/1.1. No endpoint changes protocol, yet the dashboard records a successful migration because it treats an offer as an outcome.

This is a hypothetical control failure, not a report about a named service. The error is evidentiary: a header observed at one point is being asked to prove a state transition that requires observations on both sides of a boundary.

RFC 9110 defines Upgrade as a mechanism for changing from HTTP/1.1 to another protocol on the same connection. A client may send an ordered list of protocol names to invite a server to switch, in order of preference. The server may ignore the invitation. The field therefore expresses willingness and preference, not acceptance, negotiation success, deployment coverage or application readiness.

The invitation is also connection-specific. A sender of Upgrade must include upgrade in the Connection field. That rule tells intermediaries not to forward the received option blindly. An intermediary that forwards the message first removes the fields nominated by Connection. If a proxy supports the requested protocol and elects to invite its next hop, it can generate a new hop-specific Upgrade field and must list upgrade in its own Connection field for that forwarded message. A trace at the client edge therefore cannot establish that the origin received the same offer. Conversely, an origin-side trace does not prove that the client received a later response unchanged. An HTTP/1.0 server that receives Upgrade must ignore it, so the presence of the field is even less informative when the peer’s protocol capability is uncertain.

A successful server response has a more demanding shape. A server that switches protocols must send 101 Switching Protocols and an Upgrade field identifying the selected protocol or protocols. It must not select a protocol the client did not offer. The 101 is thus a decision boundary: before it, the client has proposed; after a valid response, the parties have agreed to reinterpret the same connection under the selected protocol.

Even a 101 line is not the whole receipt. The client cannot begin using the upgraded protocol until it has completely sent the request that carried the invitation. The server must not switch unless the received request has semantics that the new protocol can honor. After the switch, the server is expected to continue responding to the original request in a form equivalent to an HTTP response under the new protocol. Operational proof therefore needs the request-completion boundary and the first well-formed exchange under the selected protocol, not merely a status code copied into a log.

The mechanism does not replace the underlying transport or create a separate connection. Only the topmost application protocol on the existing connection changes. If telemetry joins a request on one connection to a 101 or new-protocol frame on another, it has manufactured a transition that RFC 9110 does not describe. Connection identity, byte order and capture direction are indispensable.

This lens is separate from adjacent Strategic Circle work. It is not the R067 question of whether Via enumerates every intermediary, the R064 question of whether Alt-Svc proves an alternative path, the Strategic Local question of priority restoration, or the B842 question of correlating temporary IPv6 identifiers. Here the controlled event is a connection-bound application-protocol switch, and the proof standard is an ordered negotiation-and-exchange receipt.

A credible receipt joins the exact request, the ordered offers, the Connection tokens, observations before and after each intermediary, the final response status, the protocol selected in the response, completion of the request bytes, the precise switch offset, the first valid new-protocol message and any fallback or connection closure. This transition receipt is an editorial operating synthesis, not an IETF wire object. Each item has a distinct meaning. “Offer observed” must never be normalized into “switch completed.”

Sources