A WebSocket session begins when a client sends the HTTP/1.1 [@https://tools.ietf.org/html/rfc7230#section-6.7 Upgrade] request for [@https://tools.ietf.org/html/rfc6455#section-1.3 WebSocket] on an established connection, and the server sends an appropriate response indicating that the request was accepted and that the connection has been upgraded. The Upgrade request must include the [@https://tools.ietf.org/html/rfc7230#section-5.4 Host] field, and the [@https://tools.ietf.org/html/rfc7230#section-5.3 target] of the resource to request. A typical HTTP Upgrade request created and sent by the implementation will look like this:
The host and target parameters become part of the Host field and request-target in the resulting HTTP request. The key is generated by the implementation. Callers who wish to add, modify, or inspect fields may set the ['decorator] option on the stream (described later).
The [link beast.ref.boost__beast__websocket__stream `websocket::stream`] member functions [link beast.ref.boost__beast__websocket__stream.handshake `handshake`] and [link beast.ref.boost__beast__websocket__stream.async_handshake `async_handshake`] are used to send the request with the required host and target strings. This code connects to the IP address returned from a hostname lookup, then performs the WebSocket handshake in the client role.
When a client receives an HTTP Upgrade response from the server indicating a successful upgrade, the caller may wish to perform additional validation on the received HTTP response message. For example, to check that the response to a basic authentication challenge is valid. To achieve this, overloads of the handshake member function allow the caller to store the received HTTP message in an output reference argument of type [link beast.ref.boost__beast__websocket__response_type `response_type`] as follows:
For servers accepting incoming connections, the [link beast.ref.boost__beast__websocket__stream `websocket::stream`] can read the incoming upgrade request and automatically reply. If the handshake meets the requirements, the stream sends back the upgrade response with a [@https://tools.ietf.org/html/rfc6455#section-4.2.2 ['101 Switching Protocols]] status code. If the handshake does not meet the requirements, or falls outside the range of allowed parameters specified by stream options set previously by the caller, the stream sends back an HTTP response with a status code indicating an error. Depending on the keep alive setting, the connection may remain open for a subsequent handshake attempt. A typical HTTP Upgrade response created and sent by the implementation upon receiving an upgrade request handshake will look like this:
The [@https://tools.ietf.org/html/rfc6455#section-11.3.3 ['Sec-WebSocket-Accept]] field value is generated from the request in a fashion specified by the WebSocket protocol.
The [link beast.ref.boost__beast__websocket__stream `stream`] member functions [link beast.ref.boost__beast__websocket__stream.accept `accept`] and [link beast.ref.boost__beast__websocket__stream.async_accept `async_accept`] are used to read the WebSocket HTTP Upgrade request handshake from a stream already connected to an incoming peer, and then send the WebSocket HTTP Upgrade response, as shown:
It is possible for servers to read data from the stream and decide later that the buffered bytes should be interpreted as a WebSocket upgrade request. To address this usage, overloads of [link beast.ref.boost__beast__websocket__stream.accept `accept`] and [link beast.ref.boost__beast__websocket__stream.async_accept `async_accept`] which accept an additional buffer sequence parameter are provided.