Would you standardise a WebSocket fleet on extended CONNECT bootstrapping when each console holds one leased HTTP/2 link and some intermediaries refuse it?
answer
- someone else's hops decide it
- a preference, never the only path
- measure which path each site used
- two handshakes for years, budget for it
- name what retires the fallback
basics
~20 sPrefer it, but never as the only path. Extended CONNECT puts the socket on a link you already pay for, while support is decided by every hop between the console and the origin - so the fleet commits to both bootstraps and to measuring which one each site actually gets.
solid answer
~50 sThe gain is real and easy to state: the socket rides the connection the console already holds, so there is no second connection, no second security handshake, and reconnection costs a stream rather than a link. The cost is that support is not yours to decide. Every hop between the console and the origin must implement the extension, and a site whose path does not will get `501` or worse — so a fleet that ships only the bootstrap has sites that never connect. The defensible position is to prefer it, keep the `RFC 6455` HTTP/1.1 handshake as a supported fallback rather than dead code, decide per origin and cache that verdict with an expiry, and report which path each console is using. The thing you are actually committing to is maintaining two handshakes for years, and that is the tradeoff to say out loud.
go deeper
Know that the newer bootstrap is not available everywhere, so real clients keep the older handshake as a fallback rather than assuming one path.
Be able to explain what the bootstrap saves - no second connection, cheaper reconnection - and what decides whether a given site gets it.
Show the operational shape: decide per origin, cache with an expiry, exercise the fallback, and instrument which path each site used.
Own the commitment: two handshakes maintained for years, a dependency on other people's networks, a concentrated blast radius, and a written condition for retiring the fallback.
## What is genuinely on the table The question is not "is extended CONNECT better". On a device holding one expensive link, it plainly is: the socket becomes one more stream on a connection already established and already secured, rather than a second connection with its own setup cost, its own security handshake and its own place in whatever per-origin connection budget the client has. The question is what a **fleet** commits to, given that whether the bootstrap works at a given site is decided by parties you do not control. ## The three things a lead is actually deciding 1. **Whether the fallback is a supported path or dead code.** A fallback that exists in the source but is never exercised is not a fallback. If the HTTP/1.1 handshake is the answer for sites whose path refuses the bootstrap, it needs the same testing, the same telemetry and the same maintenance for as long as those sites exist. 2. **Where the decision is made and for how long it is remembered.** Probing before every socket costs a wasted round trip per attempt on links where round trips are expensive. Remembering forever means support that appears after a deployment is never used. A per-origin verdict with an expiry, refreshed rarely, is the usual shape. 3. **Whether you can see which path each site uses.** Without that, the fleet's behaviour is invisible: you cannot tell whether a change improved anything, and you cannot tell whether a site quietly regressed to the fallback after someone altered a hop. ## The costs that are easy to underestimate | Cost | Why it bites | |---|---| | Two handshakes, maintained | Every socket-related change - negotiation, auth, diagnostics - now has two code paths and two ways to be wrong | | Path-dependent support | Not a property of your software: it changes when someone else changes a hop, with no notification | | Diagnosis across versions | The same fault presents differently on each path, so runbooks and dashboards need both | | Concentration on one connection | Losing the link now loses every socket and every in-flight request at once, not just one socket | That last row is the one that turns an efficiency argument into a reliability argument. Consolidating a console's traffic onto one connection is precisely the benefit; it is also precisely why a single connection loss becomes a whole-console event. The reconnection design has to restore everything the link was carrying, and the failure budget has to be written against that, not against one socket. ## How to argue for it credibly A convincing answer commits to a position and names what would change it: - **Prefer the bootstrap where it works**, because the saving is per reconnection and reconnections on a constrained link are the expensive event. - **Keep the older handshake as a first-class path**, and say plainly that it stays until the last site that needs it is gone. - **Decide per origin, cache with an expiry**, so neither wasted probes nor permanent pessimism sets in. - **Instrument which path each console is using**, and treat an unexpected shift toward the fallback as a signal that a hop changed. - **Name the retirement condition.** "We drop the fallback when no console has used it for a full quarter" is a decision. "Eventually" is not. ## Where the argument goes wrong The weak version of this answer treats the choice as a protocol preference and stops there — extended CONNECT is newer, therefore standardise on it. That skips the part that makes it a lead's decision: you are choosing to depend on a capability that intermediaries on someone else's network must implement, which means the fleet's connectivity is partly a function of other people's upgrade schedules. The other weak version refuses the bootstrap entirely for uniformity. That is defensible on a fleet of two sites and expensive on a fleet of two thousand, because it pays for a second connection per console forever to avoid maintaining a code path you would have had to write for the legacy sites anyway. The honest position sits between them, and the sentence that shows you know it is: *the bootstrap is the default, the older handshake is supported rather than tolerated, and the fleet reports which one it got.*
- What single piece of telemetry would you add before making this change fleet-wide?Which bootstrap each console actually used, reported per site. It answers whether the change helped, shows which sites are stuck on the fallback, and turns a hop changing somewhere in the middle into a visible shift rather than a silent regression.
- When would you refuse the bootstrap and standardise on the HTTP/1.1 handshake instead?When the fleet is small enough that a second connection per console costs less than maintaining two handshakes, or when the paths are known not to support it and will not change. The deciding factor is the ratio of maintenance cost to sites that benefit, not which mechanism is newer.
- What is the retirement condition for the fallback path?A measured one: no console has used it for a stated period, with telemetry good enough to trust that statement. Without a condition written down, the fallback is maintained indefinitely by default, and every socket change keeps paying for a path nobody exercises.
saying these in an interview costs you the question
- Standardises on the bootstrap with no fallback path.
- Calls it a protocol preference rather than a dependency on other networks.
- Probes support before every socket on an expensive link.
- Caches a refusal forever, so later support is never used.
- Ignores that one connection loss now takes everything with it.
- Ships a fallback with no telemetry showing whether it is used.