Why WebSocket Uses Subprotocols and How CORS Really Works

Why WebSocket Uses Subprotocols

WebSocket’s basic protocol does not define a clear data format— it can transmit text, blob, binary, etc., which makes security and development performance less friendly. Subprotocols were introduced to solve this; both client and server must agree on the same subprotocols for the handshake to succeed.

During the handshake, the server sends its supported subprotocols; if the client’s requested subprotocol matches one on the server, the connection is established, otherwise an error occurs and the connection is closed.

WebSocket Protocol Overview

WebSocket was proposed by the HyBi Working Group and is defined mainly by a single table. Compared with TCP, it is very simple.

Figure 17-1. WebSocket frame: 2–14 bytes + payload

The frame consists of:

FIN bit – indicates whether this is the final frame of a message.

Opcode (4 bits) – specifies the frame type, e.g., text (1) or binary (2).

Mask bit – shows whether the payload is masked (client → server).

Extended length – encodes the payload length.

Masking key – used to mask the payload.

Payload – the actual data being transmitted.

Can WebSocket Cross Domains?

Yes, WebSocket can be used across origins, but for security it is common to protect domains with CORS headers such as: Access-Control-Allow-Origin: http://example.com Only the specified origin will be allowed to make cross‑origin requests.

How Does CORS Work

CORS (Cross‑Origin Resource Sharing) is a W3C specification that enables browsers to make cross‑origin AJAX requests. Older browsers like IE8 use XDomainRequest. A popular helper function by Nicholas Zakas is often used to create CORS requests.

When withCredentials is set to true, cookies are sent with the request. The server must also allow credentials: Access-Control-Allow-Credentials: true Note that cookies still obey the same‑origin policy; they cannot be accessed via document.cookie on the client side.

CORS Preflight Requests

Preflight requests are sent for “complex” requests (e.g., methods other than GET/POST or custom headers). The browser first sends an OPTIONS request containing Access-Control-Request-Method and Access-Control-Request-Headers to verify that the server permits the actual request.

If the server accepts, it responds with headers such as:

Access-Control-Allow-Methods – supported HTTP methods.

Access-Control-Max-Age – how long the preflight result can be cached.

Access-Control-Allow-Headers – allowed custom headers.

During the Max‑Age period, subsequent similar requests skip the preflight, reducing latency.

Development Roadmap

Fetch Supplement

For additional details on the Fetch API, refer to front‑end resources on fetch communication.