WebSockets on the CA API Gateway
The WebSocket client, normally a browser or mobile app, communicates with the gateway. The Gateway communicates with a WebSocket server. Messages passing through the Gateway can be vetted by a service policy. This opens up possibilities including:
gateway90
The WebSocket client, normally a browser or mobile app, communicates with the
CA API Gateway
. The Gateway communicates with a WebSocket server. Messages passing through the Gateway can be vetted by a service policy. This opens up possibilities including:- Message transformation
- Metrics
- Security
- Routing
- Connection throttling
Every WebSocket connection begins with a handshake. This handshake is done via HTTP(S) GET. At this point, any headers passed will be cached for the duration of this WebSocket connection and used for subsequent message processing.
Since WebSocket handshake is limited to a HTTP(S) GET and the WebSocket message is either a string or byte array, not all policy assertions are appropriate while working with the message within policy. As a result, certain assertions will not work with the WebSocket Message.
WebSocket Message Format
When a message is received across a WebSocket and the connection is associated with a policy, the message is wrapped in a document before being passed into policy.
The following is the format of a WebSocket message:
<request> <websocket> <type /> <origin /> <protocol /> <offset /> <length /> <data /> </websocket> </request>
Each element is described below.
Element | Description |
|---|---|
Type | Type of message: TEXT or BINARY |
Origin | Origin value passed during the WebSocket handshake |
Protocol | Sub-protocol values passed during the WebSocket handshake |
Offset | Offset—used only for BINARY messages |
Length | Length of message—used only for BINARY messages |
Data | Contents of the original message |