Prompt and scope
An HTTPS origin wants to enable HTTP/3 gradually. The server can offer an equivalent service at another endpoint, but some networks block UDP and clients may retain stale alternative-service data. Explain Alt-Svc and design certificate checks, caching, fallback, invalidation, and observability.
Alt-Svc advertises an equivalent service for the same origin; it is not a redirect and does not change the user-visible URL. This tests protocol migration, not an assumption that every client immediately uses HTTP/3.
What interviewer is testing
- Whether you distinguish Alt-Svc, HTTP redirects, and DNS service binding.
- Whether you explain origin authority and TLS certificate validation for the alternative endpoint.
- Whether you handle Alt-Svc lifetime,
clearinvalidation, unreachable UDP, and fallback. - Whether you measure rollout, handshake success, protocol version, and security events.
Clarifying questions
- Who controls the alternative endpoint, and which hostnames does its certificate cover?
- Do clients, CDNs, proxies, and firewalls support HTTP/3 and UDP/443?
- Is a cross-port or cross-host advertisement needed, and where is the origin boundary?
- How will a bad advertisement be revoked and removed from client caches?
- Are success metrics handshake rate, time to first byte, tail latency, or errors?
A 30-second answer
“Alt-Svc lets an origin advertise an equivalent alternative endpoint that a client may try on later connections; it is not a 3xx redirect and does not change the URL. For HTTP/3, I would validate the alternative endpoint's TLS certificate and origin authority, start with a short ma during a canary, fall back to HTTP/2 or HTTP/1.1 when UDP fails, and keep a clear revocation path. I would segment handshake and tail latency by client, network, and protocol before extending the cache lifetime.”
Step-by-step design
1. Explain Alt-Svc's role
RFC 7838 defines the Alt-Svc response header so a client can discover an alternative service for the same origin. The client can keep using the original URL while changing the transport endpoint when capable; application origin and authorization semantics must not be bypassed.
2. Validate authority and TLS
An alternative hostname or port is not trusted merely because it appears in a response header. The client validates the service under the origin and certificate rules described by RFC 7838. The certificate must cover the connected name, and operators must prevent cross-tenant traffic mixing. Cross-origin advertisements require a higher-risk review.
3. Advertise gradually
Send Alt-Svc first to a small client or regional cohort, using a short ma (maximum age) while measuring success. An HTTP/3 endpoint can use the h3 identifier; an old client can ignore the header and continue with the existing protocol. One advertisement is not a promise that the client will upgrade.
HTTP/2 200 OK
Alt-Svc: h3=":443"; ma=300
Cache-Control: private, no-store4. Handle UDP failure and fallback
Enterprise firewalls, mobile networks, or NAT may block UDP. After a failed or timed-out connection attempt, the client should return to HTTP/2 or HTTP/1.1. The application request must not be repeated merely because an alternative transport was attempted. Log protocol attempts and fallback reasons so network blocking is not misdiagnosed as an application failure.
5. Revoke and invalidate caches
If a certificate, route, or security problem appears, send Alt-Svc: clear and stop advertising the old service. Expiration of ma also makes clients reassess. Keep the lifetime short during the canary and extend it only after stability; clearing a CDN alone does not remove client-side alternative-service state.
6. Coordinate HTTPS DNS records
RFC 9460 SVCB/HTTPS records can publish service-binding parameters too. Both mechanisms can help discover HTTP/3, but they have different propagation, caching, and operational ownership. Define precedence, rollback, and monitoring for conflicts so DNS does not move to a new endpoint while HTTP responses still advertise an old one.
Model high-quality answer
“I would treat Alt-Svc as alternative-service discovery for the same origin, not a redirect. First validate the endpoint's TLS certificate, authority, and tenant isolation, then send h3 with a short ma to a small cohort. On UDP or HTTP/3 handshake failure, fall back to HTTP/2/1.1 without repeating a write. For a configuration or security issue, send Alt-Svc: clear and stop the old advertisement. Measure handshake, fallback, and tail latency by network, client, and protocol; if HTTPS DNS records are also used, define conflict precedence and one rollback procedure.”
Common mistakes
- Treat Alt-Svc as 301/308 → URL and cache semantics change → describe it as service discovery.
- Skip certificate validation → traffic may reach an untrusted service → apply origin and TLS checks.
- Use a long ma during a canary → a bad configuration persists → start short and extend later.
- Fail requests when UDP is blocked → network conditions cause avoidable outages → fall back to HTTP/2 or HTTP/1.1.
- Clear only the CDN → clients keep stale alternatives → send clear and let client lifetime expire.
Follow-up questions and responses
Does Alt-Svc change the URL in the browser address bar?
No. It describes an alternative service for the same origin while the application keeps the original URL. That is a key difference from an HTTP redirect.
Why not retry a write directly after HTTP/3 fails?
A transport attempt failing does not prove the application operation never arrived. Use an idempotency key or explicit request semantics, and fall back within the same operation context instead of blindly creating the resource again.
What does ma=300 mean?
It sets a maximum cache age of 300 seconds for the alternative-service information. It is not a required HTTP/3 connection duration and does not guarantee that a client will use or try the alternative during that period.