Summary

  • Alt-Svc allows an origin to advertise another protocol, host and port through which its resources may be available while the origin URI remains unchanged.
  • A fresh advertisement is not evidence that a particular client reached the alternative, authenticated it for the origin, negotiated the expected protocol or sent a successful request over it.
  • Client choice is optional, network context matters, and failed alternatives can cause fallback whose security properties need to be observed rather than assumed.
  • An alternative-path receipt should join advertisement age, origin identity, authentication, ALPN result, client selection, request outcome and fallback at one observation point.

Imagine a service returning Alt-Svc: h3=":443"; ma=86400. A rollout dashboard sees the header at the origin and marks the estate as migrated to HTTP/3. On one access network, however, the alternative connection cannot be established. Clients quietly continue over their existing origin connection, requests still succeed, and the aggregate availability graph stays green. The advertisement was real, but the claimed path change never occurred for that population.

This is a hypothetical operational trace, not a reported provider incident. The mechanism is behaving normally. The measurement error is to treat route eligibility as route execution.

Alternative routing preserves the origin

RFC 7838 defines HTTP Alternative Services so an origin’s resources can be authoritatively available at another network location, possibly with a different protocol configuration. The alternative is described by an application protocol, host and port. It is routing information for the origin, not a redirect that changes the resource URI.

That distinction carries the security context with it. Software above the HTTP access mechanism continues to see the original scheme, host and port. When TLS authenticates the connection, the alternative must present credentials valid for the origin host name, not merely for the alternative host. The request’s origin identity is therefore stable even when its network destination changes.

An advertisement alone does not demonstrate this authentication. It says the origin has nominated an alternative. Proof that a client could safely use it begins with the connection the client actually made and the identity it actually verified.

Eligibility, negotiation and use are separate events

Alternative services are optional for clients. A client can choose among fresh alternatives using its own criteria, with security properties in view, and can continue on an existing connection while an alternative connection is established. A server’s preference order is consequently not a record of the client’s decision.

The protocol identifier also creates a testable boundary. RFC 7301 defines Application-Layer Protocol Negotiation inside TLS. RFC 7838 says that if the alternative connection does not negotiate the expected protocol, the alternative must be considered failed. A reachable socket or completed TLS handshake is not enough when the advertised application protocol was not selected.

For HTTP/3, RFC 9114 maps HTTP semantics over QUIC and uses the h3 ALPN token. Seeing h3 in an Alt-Svc field is not the same event as establishing QUIC, negotiating HTTP/3 and completing a request. Operators need separate counters for each transition.

When a client does use an alternative, Alt-Used can disclose that fact to the server. Its absence, however, must be interpreted in context: telemetry at an origin, CDN, client and synthetic probe observes different slices of the decision. A credible claim names the observation point.

Freshness is not health

Alt-Svc information has its own freshness lifetime. The ma parameter controls how long it can be used to establish new connections; this lifetime is distinct from ordinary HTTP response caching. A new Alt-Svc value replaces cached alternatives for the origin, and clear invalidates them.

Freshness means the advertisement remains eligible under its caching rules. It does not mean the endpoint is currently reachable, that a route exists from every client network, that QUIC is permitted through each policy boundary, or that the alternative still offers the expected latency and capacity. Those are present-path properties.

Network change adds another boundary. Clients normally clear alternatives without persist=1 when they detect a change in network configuration. Even a persistent advertisement is only a hint that the route may remain useful after such a change. It cannot certify the new network’s reachability or policy.

Fallback can preserve service while hiding failure

RFC 7838 permits fallback to the origin or another alternative when the selected service fails or is unresponsive. That behavior protects availability, but it can make migration measurement deceptively calm. A successful request says nothing about the intended alternative unless the path is also identified.

Fallback can also lose enhanced security properties and become a downgrade surface. The correct policy depends on the application and the comparative properties of the existing connection. The evidence should record the decision: which alternative failed, how it failed, which path replaced it, whether the fallback was allowed, and what security or performance property changed.

Availability, alternative adoption and fallback safety are therefore three different metrics. A single green success rate cannot stand in for all of them.

Close the change with an alternative-path receipt

Start a receipt when an advertisement is observed. Record the origin, the exact Alt-Svc value, response source, receipt time, calculated age, ma, persist, network context and client cohort. Preserve whether the advertisement arrived directly from the origin or through a cached response and whether a later value replaced or cleared it.

For each attempted alternative, record the host and port reached, origin-name authentication result, ALPN offered and negotiated, connection outcome, client-selection reason, request status, latency, Alt-Used observation when available, and any fallback path. Keep failures and bypasses; they explain why a fresh advertisement did not become traffic.

Close a rollout claim only for the population and interval supported by this joined evidence. The advertisement proves nomination. Authentication proves origin authority for the connection. ALPN proves protocol selection. Request evidence proves use and outcome. A path is proven only when those events are bound together at a named observation point.

Sources