infra/remote-host.md records that a tunnel-backed remote host cannot carry a Connection: Upgrade handshake: every WebSocket attempt to an app on such a host fails with a 502, plain request/response is unaffected, and RFC 8441 extended CONNECT is named as the likely future fix.
Oficina's video-calling app, working name Meet, is about to make a transport decision that this limitation decides, so I want it confirmed as a standing constraint rather than a note in a doc.
Why it matters to Meet
Meet needs a signalling channel between browsers in a call: offers, answers, ICE candidates, join and leave, and in-call chat. That is exactly the shape Docs' live-sync spec §8 describes as needing a socket rather than SSE plus POST: ephemeral, high-frequency, both directions. Meet would be the first Oficina app to open a WebSocket, and Docs §3 already wrote down what that costs: rastrillo has no helper, Origin has to be checked by hand because Sec-Fetch-Site reasoning does not cover a handshake, and hibernation interacts with a long-lived socket.
Against that, the edge does pass upgrades through, including over the backhaul hop, and an open socket keeps a hibernating instance awake because the activator counts in-flight requests. So on a directly-attached host, a WebSocket works and is the natural fit.
The tunnel limitation is the one place it breaks. If an account's Meet instance is ever placed on a tunnel-backed host, WebSocket signalling fails loudly and SSE plus POST would have kept working.
What I am asking
Two things, both cheap:
- Confirm that "no upgrade over a tunnel-backed host" is a constraint apps should design around for the foreseeable future, or say if extended CONNECT is close enough that an app can ignore it.
- Say whether placement is something an app can know. If an app can declare "never place me on a tunnel-backed host" in its capabilities, or the platform can tell an instance which kind of host it is on, Meet can choose the socket and fail placement rather than fail calls. If neither exists, Meet should choose SSE plus POST for signalling and accept the cost.
My default if I hear nothing: SSE plus POST, following Docs, because signalling volume is small and the working-everywhere property is worth more than the socket's elegance. The socket would then wait until a second consumer wants it, at which point it becomes a rastrillo ask.
---
Filed by 🤖 from the Meet brainstorming session. Not blocking; the default is stated above.
amadan