HTTP Headers
Sec WebSocket Version
The HTTP Sec-WebSocket-Version request and response header are used during the WebSocket opening handshake to indicate the WebSocket protocol supported by the client and the protocol versions supported by the server if it does not support the version specified in the request.
The header can only appear once in a request and specifies the WebSocket version that the web application is using.
The current version of the protocol at the time of writing is 13.
The header is automatically added to requests by user agents when a WebSocket
connection is established.
The server uses the version to determine if it can understand the protocol.
If the server doesn’t support the version, or if any header in the handshake is not understood or has an incorrect value, the server should send a response with status 400 Bad Request
and immediately close the socket.
It should also include Sec-WebSocket-Version
in the 400
response, listing the versions it supports.
The versions can be specified in individual headers or as comma-separated values in a single header.
The header should not be sent in responses if the server understands the version specified by the client.
The header type is a response header.
Request headers with a Sec-
prefix are not allowed for usage outside the handshake process.
Syntax
Request
Sec-WebSocket-Version: <version>;
Response (on error only):
Sec-WebSocket-Version: <server-supported-versions>
Directives
<version>
- The WebSocket protocol version the client wishes to use when communicating with the server.
This number should typically be the most recent version available published in the IANA WebSocket Version Number Registry.
The latest official version of the WebSocket protocol is version 13.
- <server-supported-versions>
- In case of an error, a comma-separated list of WebSocket protocol versions supported by the server.
This header is omitted from responses if the version specified in <version> is supported by the server.
Example
The version supported by the client is specified in the original WebSocket
handshake request. For the current protocol, the version is “13”. Below is an example of such a request.
GET /chat HTTP/1.1
Host: example.com:8000
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13
How to Modify Header using Requestly
Requestly is a powerful Chrome extension that allows you to modify HTTP headers, including the Sec-WebSocket-Version header. This is especially useful for testing how your application handles different WebSocket protocol versions during development or debugging. Steps to Modify the Sec-WebSocket-Version Header:
- Install and open the Requestly Chrome extension. You can find it on the Chrome Web Store.
- Create a new rule: Click on “Create Rule” and choose “Modify Headers” from the list of available rule types.
- Add a new header modification:
- Under “Action”, select “Add” or “Override”.
- In the “Header Name” field, enter Sec-WebSocket-Version.
- In the “Header Value” field, enter the WebSocket version you want to test (e.g., 13).
- Set the URL condition: Specify the URL or pattern where this header change should apply (e.g., wss://your-websocket-server.com/*).
- Save the rule.
Once set up, Requestly will inject the Sec-WebSocket-Version header with your specified value into all matching WebSocket handshake requests, helping you verify how different protocol versions are handled.
You might need to modify the Sec-WebSocket-Version header to test compatibility with various WebSocket protocol versions or troubleshoot connection issues caused by version mismatches between client and server.
Table of Contents
- No headings found.