WebSockets

11 roadmaps 45 questionsupdated 2026-09-29

One TCP connection that either end may write to at any moment, obtained by upgrading an ordinary HTTP request and then held open. Interviewers reach for it whenever a brief says the word live.

▸ follow the backend developer roadmap jump to the questions →

on this pageshow

guide

overview

~1 min

The hub splits the way a connection lives. The HTTP upgrade handshake and the extended CONNECT bootstrap are how a socket opens over HTTP/1.1 and over HTTP/2 or HTTP/3. Frame format and masking is the wire format; bidirectional messaging is what the application sees on top of it, and subprotocols and extensions is how both ends agree on what messages mean. Ping/pong and close covers liveness and shutdown. Connection authentication and origin, TLS and proxies hold the security and deployment questions, and short and long polling is the baseline a socket is measured against.

Junior rounds ask for the handshake, the frame types and the difference from polling. Senior and principal rounds move to production: a proxy that swallows the upgrade, a token in the logs, a consumer that cannot keep up, a fleet where an open connection is the wrong call. Learn the handshake and framing first, then messaging and close; authentication and proxies make sense once the life of a connection is clear.

A WebSocket is one long-lived TCP connection, opened by upgrading an HTTP request, over which either side may send a message whenever it likes. Interviewers bring it up whenever a design brief says live or push, to find out whether you know what the protocol leaves to you. A strong answer treats the socket as a thin pipe: it carries messages, while delivery confirmation, matching replies to requests, backpressure, reconnection and authorization after the open are the application's job. The hub splits the way a connection lives. The [HTTP upgrade handshake](/topics/proto-websockets-handshake) and the [extended CONNECT bootstrap](/topics/proto-websockets-http2-http3) are how a socket opens over HTTP/1.1 and over HTTP/2 or HTTP/3. [Frame format and masking](/topics/proto-websockets-framing) is the wire format; [bidirectional messaging](/topics/proto-websockets-messaging) is what the application sees on top of it, and [subprotocols and extensions](/topics/proto-websockets-subprotocols) is how both ends agree on what messages mean. [Ping/pong and close](/topics/proto-websockets-keepalive) covers liveness and shutdown. [Connection authentication](/topics/proto-websockets-auth) and [origin, TLS and proxies](/topics/proto-websockets-scaling) hold the security and deployment questions, and [short and long polling](/topics/proto-websockets-vs-polling) is the baseline a socket is measured against. Junior rounds ask for the handshake, the frame types and the difference from polling. Senior and principal rounds move to production: a proxy that swallows the upgrade, a token in the logs, a consumer that cannot keep up, a fleet where an open connection is the wrong call. Learn the handshake and framing first, then messaging and close; authentication and proxies make sense once the life of a connection is clear.

primer

It starts as HTTP, then stops being HTTP

The opening exchange is an ordinary HTTP request asking to switch protocols. Once the server agrees, the same TCP connection carries WebSocket frames and HTTP has no further say. That reuse is why sockets pass through existing ports and load balancers, and why every HTTP-era concern — cookies, Origin, proxies, access logs — applies to that single request and to nothing that follows it.

Messages, not calls

Either end may send at any time, and nothing pairs a message with a reply. The protocol gives you text and binary messages and stops there: no identifiers, no acknowledgements, nothing that confirms arrival. Anything shaped like a call — did the command land, which reply belongs to it — is a convention the two ends invent, which is why interviewers push toward a published subprotocol over a home-grown envelope.

Frames are the unit on the wire

A message travels as one or more frames, each with its own small header. Fragmentation lets a sender stream a message whose size it does not yet know, and lets control frames (ping, pong, close) slip in between pieces. Frames from client to server are masked, a defence aimed at intermediaries rather than eavesdroppers; confidentiality comes from TLS alone.

Nothing tells the sender to slow down

The protocol has no window or credit of its own. When a receiver falls behind, TCP pushes back and the pressure shows up as data piling up inside the sending process. Bounded queues, dropping or coalescing stale updates and caps on inbound message size are designs you choose, not settings you switch on.

A quiet socket proves nothing

A connection whose peer has vanished looks exactly like a healthy idle one until a write fails. Liveness needs a periodic probe with a deadline; a clean ending needs both sides to exchange close frames.

Authorization happens once, at the door

The browser API gives a page no way to add headers to the upgrade, so credentials ride in a cookie, the URL, a pre-minted ticket or the subprotocol list — each with its own leak or forgery risk. Whatever you pick is checked when the socket opens, and a socket that lives for hours outlives that check unless you design for it.

### It starts as HTTP, then stops being HTTP The opening exchange is an ordinary HTTP request asking to switch protocols. Once the server agrees, the same TCP connection carries WebSocket frames and HTTP has no further say. That reuse is why sockets pass through existing ports and load balancers, and why every HTTP-era concern — cookies, `Origin`, proxies, access logs — applies to that single request and to nothing that follows it. ### Messages, not calls Either end may send at any time, and nothing pairs a message with a reply. The protocol gives you text and binary messages and stops there: no identifiers, no acknowledgements, nothing that confirms arrival. Anything shaped like a call — did the command land, which reply belongs to it — is a convention the two ends invent, which is why interviewers push toward a published subprotocol over a home-grown envelope. ### Frames are the unit on the wire A message travels as one or more frames, each with its own small header. Fragmentation lets a sender stream a message whose size it does not yet know, and lets control frames (ping, pong, close) slip in between pieces. Frames from client to server are masked, a defence aimed at intermediaries rather than eavesdroppers; confidentiality comes from TLS alone. ### Nothing tells the sender to slow down The protocol has no window or credit of its own. When a receiver falls behind, TCP pushes back and the pressure shows up as data piling up inside the sending process. Bounded queues, dropping or coalescing stale updates and caps on inbound message size are designs you choose, not settings you switch on. ### A quiet socket proves nothing A connection whose peer has vanished looks exactly like a healthy idle one until a write fails. Liveness needs a periodic probe with a deadline; a clean ending needs both sides to exchange close frames. ### Authorization happens once, at the door The browser API gives a page no way to add headers to the upgrade, so credentials ride in a cookie, the URL, a pre-minted ticket or the subprotocol list — each with its own leak or forgery risk. Whatever you pick is checked when the socket opens, and a socket that lives for hours outlives that check unless you design for it.

101 Switching Protocols: The HTTP/1.1 status a server returns to accept the upgrade; from the end of that response onward, the connection carries WebSocket frames.
Sec-WebSocket-Accept: The server's handshake field derived from the client's random key. It shows the responder understood the WebSocket handshake; it authenticates nobody.
Frame: The unit on the wire: a short header with FIN bit, opcode, mask flag and payload length, followed by the payload.
Masking: XOR-ing each client-to-server payload with a random per-frame key, so crafted bytes cannot pass for other protocols in proxy caches. Not encryption.
Control frame: A ping, pong or close frame: small, never fragmented, and allowed to arrive between the fragments of a data message.
Close status code: A numeric reason carried in a close frame, such as normal closure or message too big. Some codes exist only for local APIs.
Half-open connection: A connection one side still believes is open after the other side or a middlebox has discarded it; only a write or probe exposes it.
Subprotocol: An application protocol negotiated in the handshake, such as STOMP or MQTT, that defines what messages mean on this socket.
permessage-deflate: The standard extension that compresses message payloads, negotiated with parameters that trade compression ratio against per-connection memory.
wss: The WebSocket scheme run over TLS, on port 443 by default. Protection ends wherever TLS is terminated.
Origin header: The request field a browser sets to the page's origin on the upgrade. Servers check it to block cross-site sockets; non-browser clients can forge it.
Extended CONNECT: The HTTP/2 and HTTP/3 method for opening a WebSocket on one stream, enabled by a server setting, with a success status instead of 101.

Once open, the layers stack like this:

TCP, or one stream of an HTTP/2 or HTTP/3 connection, carries the bytes and supplies the only backpressure.
TLS, for wss, encrypts up to the point where it is terminated.
Frames carry payload, fragmentation and the control traffic: ping, pong and close.
Extensions such as permessage-deflate transform payloads, as agreed at open.
The subprotocol gives messages meaning: commands, subscriptions, acknowledgements, errors.
The application owns the rest: correlating replies, reconnecting, catching up on missed events, re-checking authorization.

In a browser, the page holds only the thin end of all this — a URL, the names it offers and a few events:

javascript

// an ordinary authenticated request mints a short-lived, single-use ticket
const { ticket } = await (await fetch("/ws-ticket", { method: "POST" })).json();
// the upgrade takes only a URL and subprotocol names: no header slot
const ws = new WebSocket(`wss://example.com/live?ticket=${ticket}`, ["v12.stomp"]);
ws.onopen = () => console.log(ws.protocol);   // the one name the server echoed
ws.onclose = (e) => console.log(e.code);      // 1006 when no close frame arrived
function send(frame) {
  if (ws.bufferedAmount > 1_000_000) return;  // the page's only backpressure signal
  ws.send(frame);
}

Three sections meet in those lines: the credential cannot travel as a header, the server picks at most one subprotocol, and the page learns the receiver is slow only by watching its own send buffer grow.

Trace one connection from open to close. The client sends an HTTP request asking to upgrade, offering subprotocols and extensions and carrying whatever credential it can: usually a cookie, or a ticket in the URL. Every proxy on the path has to pass that upgrade through, and the server checks `Origin`, the credential and its own connection limits before agreeing. Over HTTP/2 or HTTP/3 the same negotiation rides an extended CONNECT on one stream of a connection that already exists, and a success status stands in for the 101. Once open, the layers stack like this: - **TCP, or one stream of an HTTP/2 or HTTP/3 connection,** carries the bytes and supplies the only backpressure. - **TLS**, for `wss`, encrypts up to the point where it is terminated. - **Frames** carry payload, fragmentation and the control traffic: ping, pong and close. - **Extensions** such as permessage-deflate transform payloads, as agreed at open. - **The subprotocol** gives messages meaning: commands, subscriptions, acknowledgements, errors. - **The application** owns the rest: correlating replies, reconnecting, catching up on missed events, re-checking authorization. In a browser, the page holds only the thin end of all this — a URL, the names it offers and a few events: ```javascript // an ordinary authenticated request mints a short-lived, single-use ticket const { ticket } = await (await fetch("/ws-ticket", { method: "POST" })).json(); // the upgrade takes only a URL and subprotocol names: no header slot const ws = new WebSocket(`wss://example.com/live?ticket=${ticket}`, ["v12.stomp"]); ws.onopen = () => console.log(ws.protocol); // the one name the server echoed ws.onclose = (e) => console.log(e.code); // 1006 when no close frame arrived function send(frame) { if (ws.bufferedAmount > 1_000_000) return; // the page's only backpressure signal ws.send(frame); } ``` Three sections meet in those lines: the credential cannot travel as a header, the server picks at most one subprotocol, and the page learns the receiver is slow only by watching its own send buffer grow.

HTTP Upgrade Handshake →
Where every connection begins: how an HTTP request becomes a socket, and why HTTP has no say once it succeeds.
Frame Format and Masking →
The wire format every later section assumes: frame header, message fragmentation and why client frames are masked.
Bidirectional Messaging →
What the application actually gets: text and binary messages, reassembly, and no built-in flow control or reply matching.
Ping/Pong and Close →
How to tell a live socket from a dead one and how to end a connection cleanly.
Connection Authentication →
Credentials on a socket, where tokens leak, and what to do when authorization expires mid-connection.
Origin, TLS, and Proxies →
Origin checks, TLS and reverse proxies: the reasons a socket that works locally fails once deployed.

Calling masking a security feature for the data: the key travels in the frame, anyone on the path can undo it, and only wss keeps payloads private.
Assuming a sent message was received and processed: the protocol confirms nothing, so command traffic needs acknowledgements and a correlation id defined by the application or its subprotocol.
Treating an allowlisted Origin as authentication: it stops other sites' pages in a victim's browser, while any scripted client sends whatever value it likes.
Putting a long-lived access token in the wss: query string, where it lands in logs and history — see Token in the Query String.
Reading a quiet connection as a healthy one: without pings on a timer and a pong deadline, a half-open socket stays connected until a write finally fails.
Debugging the application when clients get 200 instead of 101 behind a new reverse proxy; the proxy usually dropped the hop-by-hop upgrade fields.
Reaching for a socket whenever a brief says real time: for rare updates, one-way push or devices that sleep, polling can be cheaper and simpler.

This guide assumes the protocol as RFC 6455 defined it in 2011, version 13 — the value clients send in Sec-WebSocket-Version today. The framing and the HTTP/1.1 handshake have not changed since; what changed is around them, and interviewers ask about each piece:

RFC 7692 (2015) standardised permessage-deflate and its context-takeover and window parameters.
RFC 8441 (2018) defined how to open a socket over HTTP/2 with extended CONNECT, gated by a server setting.
RFC 9220 (2022) carried the same bootstrap to HTTP/3.

Pre-standard drafts used a different handshake and sent unmasked frames; they matter now only as the reason masking and the accept digest exist. When a question concerns opening a socket, say which HTTP version you mean: the key and accept exchange and the 101 status belong to HTTP/1.1 alone, and an answer that assumes them on HTTP/2 is wrong.

This guide assumes the protocol as RFC 6455 defined it in 2011, version 13 — the value clients send in `Sec-WebSocket-Version` today. The framing and the HTTP/1.1 handshake have not changed since; what changed is around them, and interviewers ask about each piece: - **RFC 7692** (2015) standardised permessage-deflate and its context-takeover and window parameters. - **RFC 8441** (2018) defined how to open a socket over HTTP/2 with extended CONNECT, gated by a server setting. - **RFC 9220** (2022) carried the same bootstrap to HTTP/3. Pre-standard drafts used a different handshake and sent unmasked frames; they matter now only as the reason masking and the accept digest exist. When a question concerns opening a socket, say which HTTP version you mean: the key and accept exchange and the 101 status belong to HTTP/1.1 alone, and an answer that assumes them on HTTP/2 is wrong.

Interviewers expect you to place WebSockets among the other ways to get data to a client without being asked. Short and long polling use plain HTTP and fit rare or bursty updates, especially where clients sleep or connections are metered. Server-sent events stream from server to client over an ordinary HTTP response, with reconnection built into the browser API; they fit one-way feeds, and a socket earns its place when the client also sends often. WebTransport, built on HTTP/3, offers multiple streams and unreliable datagrams, and is the newer option where head-of-line blocking matters. gRPC streaming serves service-to-service streams more often than browsers.

On top of the socket sit the protocols that give messages meaning: STOMP, usually in front of a message broker; MQTT for devices; and graphql-ws for GraphQL subscriptions. Libraries such as Socket.IO add their own protocol with rooms, acknowledgements and fallbacks, so their clients do not talk to a plain WebSocket server. Fanning messages out across a fleet of socket servers is a system-design question; this hub stops at one server's sockets.

Interviewers expect you to place WebSockets among the other ways to get data to a client without being asked. **Short and long polling** use plain HTTP and fit rare or bursty updates, especially where clients sleep or connections are metered. **Server-sent events** stream from server to client over an ordinary HTTP response, with reconnection built into the browser API; they fit one-way feeds, and a socket earns its place when the client also sends often. **WebTransport**, built on HTTP/3, offers multiple streams and unreliable datagrams, and is the newer option where head-of-line blocking matters. gRPC streaming serves service-to-service streams more often than browsers. On top of the socket sit the protocols that give messages meaning: STOMP, usually in front of a message broker; MQTT for devices; and graphql-ws for GraphQL subscriptions. Libraries such as Socket.IO add their own protocol with rooms, acknowledgements and fallbacks, so their clients do not talk to a plain WebSocket server. Fanning messages out across a fleet of socket servers is a system-design question; this hub stops at one server's sockets.

explore

report an issue with this guide →

questions

page 1 of 2

In the WebSocket protocol, why can a browser page not set an HTTP Authorization request header on the upgrade?

juniormust knowfreq 62%

answer

the page never builds the request
URL and subprotocol list only
ordinary GET, then the 101
cookies ride automatically, tokens do not
a non-browser client has no such limit

basics

~20 s

The upgrade is an ordinary HTTP GET issued by the browser itself, and the page's socket API accepts only a URL and a list of subprotocol names. There is no place to add a request field, so no Authorization.

solid answer

~40 s

A WebSocket connection starts as an HTTP/1.1 GET carrying Upgrade: websocket, Connection: Upgrade, Sec-WebSocket-Key and Sec-WebSocket-Version: 13, answered by 101 Switching Protocols. Nothing in RFC 6455 forbids an Authorization field on that request — the restriction is in the browser: the client API a page gets accepts a URL and an optional subprotocol list and nothing else, so the page never builds the request and cannot add fields to it. What still travels automatically is a cookie scoped to the target origin. That leaves four practical routes for a credential: the cookie, a token in the URL query string, a token smuggled as a second subprotocol value, or a short-lived ticket redeemed on the upgrade. A non-browser client writes the request itself and is under none of this.

A WebSocket connection starts as an HTTP/1.1 `GET` carrying `Upgrade: websocket`, `Connection: Upgrade`, `Sec-WebSocket-Key` and `Sec-WebSocket-Version: 13`, answered by `101 Switching Protocols`. Nothing in RFC 6455 forbids an `Authorization` field on that request — the restriction is in the browser: the client API a page gets accepts a URL and an optional subprotocol list and nothing else, so the page never builds the request and cannot add fields to it. What still travels automatically is a cookie scoped to the target origin. That leaves four practical routes for a credential: the cookie, a token in the URL query string, a token smuggled as a second subprotocol value, or a short-lived ticket redeemed on the upgrade. A non-browser client writes the request itself and is under none of this.

code

http · 13 lines

http

GET /cabinet/socket HTTP/1.1
Host: console.example.org
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13
Origin: https://console.example.org
Cookie: cabinet_session=8f2c1d...

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

go deeper

for a junior

Recall that a WebSocket starts life as an HTTP GET with Upgrade and Connection fields, and that a page can only influence the URL and the subprotocol list. That is enough to explain why the header is missing.

for a middle

Explain that the restriction is a client API limitation rather than a protocol rule, and walk the four routes a credential can take instead, naming what each costs on the wire.

for a senior

Demonstrate that the answer depends on the client kind, and that the check happens once at the handshake — so the identity a connection carries all shift is whatever the upgrade established.

for a principal

Frame it as a fleet decision: whether one endpoint serves both page and service clients with two credential routes, or two endpoints each accept one, and what that costs in review surface.

The upgrade is an ordinary HTTP request

A WebSocket connection does not begin as a socket. It begins as an HTTP/1.1 GET that asks the server to change protocols. That request carries Upgrade: websocket, Connection: Upgrade, a client-generated Sec-WebSocket-Key and Sec-WebSocket-Version: 13; the server answers 101 Switching Protocols with a Sec-WebSocket-Accept digest, and from that moment the same TCP connection carries frames instead of HTTP messages.

Because it is an ordinary HTTP request, it can carry ordinary HTTP request fields. RFC 6455 places no restriction on an Authorization field on the upgrade. The limitation that every team runs into is on the client side, and it applies to exactly one kind of client.

What a page's client API actually accepts

The socket API a browser gives a page takes two things:

the URL — scheme, authority, path and query string, all under your control;
an optional list of subprotocol names, which the browser puts in Sec-WebSocket-Protocol.

That is the entire input surface. The page does not construct the request, so it cannot add, remove or edit a single field on it. Cookies are attached by the browser according to the cookie's own attributes, not by your code. So the practical question is never "which header do I use" — it is "which of the two inputs I control can carry a credential, and what does that cost."

The routes a credential can actually take

Route	Who can use it	What it costs
Session cookie	a browser page	sent automatically, including on an upgrade started by a page you do not control, so cross-site protection becomes load-bearing; the cookie's own attributes decide whether it travels at all
Token in the query string	any client	lands in the server's access log, every intermediary's access log, browser history, and any copy of that URL — the most common credential leak on this protocol
Token as a second `Sec-WebSocket-Protocol` value	any client	abuses a negotiation field; the server must select exactly one value to echo and it must not be the token
Short-lived single-use ticket in the query string	any client	one extra authenticated request before the upgrade; the shape that survives review
Credential in the first frame after the socket opens	any client	the server has already accepted an unauthenticated connection and must time it out if no credential arrives

None of these is free, and a candidate who names the trade-off rather than a favourite is the one answering the question.

A non-browser client is under no such limitation

A server-to-server client, a command-line client or a native application writes the upgrade request itself. It sets Authorization exactly as it would on any other HTTP request, and the whole problem disappears. This is why the honest answer to "how do you authenticate a WebSocket" begins with a question back: which client? A console running in a browser and a background service opening the same endpoint have different answers, and an interviewer listening for that distinction hears it immediately.

It also means a server that accepts only Authorization is not wrong — it is simply unusable from a page, which may be exactly the intent for an internal endpoint.

What the check is worth

Whatever route you choose, the authentication happens once, on the request that opens the connection. If it succeeds the server completes the handshake; if it fails the server refuses the upgrade with an ordinary HTTP error response instead of the 101, and no socket ever exists. There is no second credential exchange defined by the protocol, and no per-frame credential: once the connection is up, everything the server knows about who is on the other end is whatever it recorded at the handshake and attached to the connection.

On a console that dispenses controlled substances, that single check is the entire identity story for a connection that may stay open all shift — which is why the same leaf goes on to ask what happens when the credential behind it expires.

What an interviewer is listening for

That the upgrade is HTTP, so HTTP mechanisms are in play at all.
That the missing header is a client API limitation, not a protocol rule.
That the answer differs by client kind.
That the cookie is not a neutral default — it is a choice with a cross-site consequence.

## The upgrade is an ordinary HTTP request A WebSocket connection does not begin as a socket. It begins as an HTTP/1.1 `GET` that asks the server to change protocols. That request carries `Upgrade: websocket`, `Connection: Upgrade`, a client-generated `Sec-WebSocket-Key` and `Sec-WebSocket-Version: 13`; the server answers `101 Switching Protocols` with a `Sec-WebSocket-Accept` digest, and from that moment the same TCP connection carries frames instead of HTTP messages. Because it is an ordinary HTTP request, it can carry ordinary HTTP request fields. **RFC 6455 places no restriction on an `Authorization` field on the upgrade.** The limitation that every team runs into is on the client side, and it applies to exactly one kind of client. ## What a page's client API actually accepts The socket API a browser gives a page takes two things: - the **URL** — scheme, authority, path and query string, all under your control; - an optional **list of subprotocol names**, which the browser puts in `Sec-WebSocket-Protocol`. That is the entire input surface. The page does not construct the request, so it cannot add, remove or edit a single field on it. Cookies are attached by the browser according to the cookie's own attributes, not by your code. So the practical question is never "which header do I use" — it is "which of the two inputs I control can carry a credential, and what does that cost." ## The routes a credential can actually take | Route | Who can use it | What it costs | |---|---|---| | Session **cookie** | a browser page | sent automatically, including on an upgrade started by a page you do not control, so cross-site protection becomes load-bearing; the cookie's own attributes decide whether it travels at all | | **Token in the query string** | any client | lands in the server's access log, every intermediary's access log, browser history, and any copy of that URL — the most common credential leak on this protocol | | **Token as a second `Sec-WebSocket-Protocol` value** | any client | abuses a negotiation field; the server must select exactly one value to echo and it must not be the token | | **Short-lived single-use ticket** in the query string | any client | one extra authenticated request before the upgrade; the shape that survives review | | **Credential in the first frame** after the socket opens | any client | the server has already accepted an unauthenticated connection and must time it out if no credential arrives | None of these is free, and a candidate who names the trade-off rather than a favourite is the one answering the question. ## A non-browser client is under no such limitation A server-to-server client, a command-line client or a native application writes the upgrade request itself. It sets `Authorization` exactly as it would on any other HTTP request, and the whole problem disappears. This is why the honest answer to "how do you authenticate a WebSocket" begins with a question back: **which client?** A console running in a browser and a background service opening the same endpoint have different answers, and an interviewer listening for that distinction hears it immediately. It also means a server that accepts only `Authorization` is not wrong — it is simply unusable from a page, which may be exactly the intent for an internal endpoint. ## What the check is worth Whatever route you choose, the authentication happens **once**, on the request that opens the connection. If it succeeds the server completes the handshake; if it fails the server refuses the upgrade with an ordinary HTTP error response instead of the `101`, and no socket ever exists. There is no second credential exchange defined by the protocol, and no per-frame credential: once the connection is up, everything the server knows about who is on the other end is whatever it recorded at the handshake and attached to the connection. On a console that dispenses controlled substances, that single check is the entire identity story for a connection that may stay open all shift — which is why the same leaf goes on to ask what happens when the credential behind it expires. ## What an interviewer is listening for 1. That the upgrade **is** HTTP, so HTTP mechanisms are in play at all. 2. That the missing header is a **client API** limitation, not a protocol rule. 3. That the answer **differs by client kind**. 4. That the cookie is not a neutral default — it is a choice with a cross-site consequence.

If the protocol allows an Authorization field on the upgrade, when is it actually the right choice?
Whenever the client is not a browser page. A service, a native application or a command-line client builds the upgrade request itself and can set any request field on it, so it authenticates the handshake exactly as it would any other HTTP request — no ticket endpoint, no token in the URL, no cookie. Restricting an endpoint to that route is a reasonable way to say "not callable from a page".
What does the server know about the caller once the socket is open?
Only what it recorded during the handshake and bound to the connection. The protocol defines no second credential exchange and no per-frame identity, so every frame that arrives is attributed to the principal established at open. Anything finer — per-message authorization, a principal that can change — is the application's own invention layered on top.
Can the page authenticate after the socket opens instead?
Yes, by sending the credential in the first application frame, and some designs do. The cost is that the server has already accepted a connection from an unauthenticated peer: it must hold that socket in an unauthenticated state, refuse every other message until a valid credential arrives, and close it on a short timer if one never does.

saying these in an interview costs you the question

Says RFC 6455 forbids an Authorization field on the upgrade request
Thinks the WebSocket upgrade is not an HTTP request at all
Believes every client is limited the way a browser page is
Assumes wss encryption removes the need to authenticate the handshake
Treats an in-band first-message credential as costing nothing

§guide

overview

§primer

▾core ideas~2 min

It starts as HTTP, then stops being HTTP

Messages, not calls

Frames are the unit on the wire

Nothing tells the sender to slow down

A quiet socket proves nothing

Authorization happens once, at the door

▾vocabulary12 terms

▾how it fits~2 min

▾where to start6 steps

▾common pitfalls7

▾versions3

▾ecosystem~60 s

§explore

▾sections9 · 45 questions

▾roadmaps that cover this11

§questions

In the WebSocket protocol, why can a browser page not set an HTTP Authorization request header on the upgrade?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~4 min

The upgrade is an ordinary HTTP request

What a page's client API actually accepts

The routes a credential can actually take

A non-browser client is under no such limitation

What the check is worth

What an interviewer is listening for

▾common follow-ups3 questions

▾red flags5 flags

In a WebSocket data frame, what do the FIN bit and the 4-bit opcode in the first byte tell the receiver?

basics

What does a WebSocket client send in its HTTP/1.1 upgrade request, and which response means the socket is open?

basics

In the WebSocket protocol, what must an endpoint do when it receives a Ping control frame, and what does that exchange prove?

basics

In a WebSocket connection, what does the protocol guarantee about a text message that it does not guarantee about a binary one?

basics

In a WebSocket opening handshake, what does the client's `Sec-WebSocket-Protocol` field offer, and how must the server answer?

basics

How do short polling and long polling differ in what the HTTP server does with each request for updates?

basics

Why must a WebSocket client mask every frame it sends, when the masking key travels in that same frame?

basics

In a WebSocket opening handshake, how does the server compute Sec-WebSocket-Accept, and what does that value prove?

basics

Before a WebSocket can open over HTTP/2, what must the server have sent, and what request replaces the GET with `Upgrade: websocket`?

basics

In a WebSocket connection, what happens on the wire between one endpoint deciding to close and the TCP connection actually ending?

basics

Why can a page on an attacker's domain open a WebSocket to your server with the victim's cookies attached, and what stops it?

basics

Why adopt a published WebSocket subprotocol such as STOMP or MQTT instead of inventing your own JSON message envelope?

basics

When a WebSocket client puts its access token in the wss: URL query string, where does that token land and what replaces the practice?

basics

A yard system pushes position updates over a WebSocket faster than the cabin console consumes them - what in the protocol tells the sender to slow down?

basics

A reverse proxy now sits in front of your WebSocket service and clients get 200 OK with an HTML body instead of 101. What happened?

basics

An irrigation controller's long-poll feed drops some events and repeats others under load; what happens between each response and the next request?

basics

In the WebSocket protocol, what does a wss: URL give you that a ws: URL does not, and where does that protection stop?

basics

What does a WebSocket upgrade authenticated by a session cookie get for free, and what risk does that create?

basics

On a WebSocket that multiplexes many channels, why must the server authorize each subscribe message when the upgrade was already authenticated?

basics

How does a WebSocket sender split one message across several frames, and what does each frame carry?

basics

In a WebSocket frame, how is payload length encoded when the 7-bit length field holds 126 or 127?

basics

A WebSocket bootstrapped over HTTP/2 sends no `Sec-WebSocket-Key` and gets no `101`, so which handshake fields survive and what signals success?

basics

guide

primer

explore

questions

answer

go deeper