The HTTP headers are used for passing additional information with an HTTP request or response between the client and the server. They are grouped as general-headers, request-headers, response-headers, entity-headers. The Sec-WebSocket-Accept header falls under the response-type headers category. It is used by the server to intimate the client that it understood. It was a WebSocket connection and it is ready to open connection. This comes handy for a reverse-proxy server as it can understand the WebSocket handshake and not to make a useless cache. The Sec-WebSocket-Accept header must not appear more than once in an HTTP response.
Note: The HTTP headers usually contain a case-insensitive name followed by a colon (:), then by its value. White-space before the value is ignored here.
Syntax:
Sec-WebSocket-Accept: <hashed key>
Directives: The HTTP Sec-WebSocket-Accept header accepts a single directive that mentioned above and described below:
- <hashed key> The server takes the value of Sec-WebSocket-Key sent in handshake request and then appends Globally Unique Identifier (GUID, [RFC4122]) “258EAFA5-E914-47DA-95CA-C5AB0DC85B11” takes SHA-1 of the new value, and is then base64 encoded. This is unlikely to be used by network endpoints that do not understand the WebSocket Protocol.
Below example will illustrate the HTTP Sec-WebSocket-Accept header:
Example: In this example, the server sends 101 response codes if the incoming connection is a WebSocket connection to the client.
101 Switching Protocols Upgrade: websocket Connection: Upgrade Sec-WebSocket-Accept: MTMyNThFQUZBNS1FOTE0LTQ3REEtOTVDQS1DNUFCMERDODVCMTE= Sec-WebSocket-Extensions: deflate-frame Sec-WebSocket-Protocol: soap
Note: This header is not stable there are few research is going on right now on this header.
Supported Browsers: The browsers are compatible with HTTP Sec-WebSocket-Accept header are listed below:
- Chrome
- Internet Explorer
- Firefox
- Safari
- Opera