Configuring the HTTP Client for HTTP Pass-Through and Tunneling
To configure HTTP pass-through and tunneling, set related http-client properties in your configuration file for the Connection Server. The full group name of the properties to configure is cx-server.http-client.
 |
For security best practices, use SSL/TLS for HTTP Pass-Through and tunneling, as explained in the Minimal Configuration for Connecting to a Single-Server ThingWorx Platform Installation Using SSL/TLS or in the Optional Configuration section of the High Availability Configuration topic.
|
Follow these steps to configure the HTTP client that is used for HTTP pass-through (REST API) and for tunneling:
1. Depending on where you are in setting up your Connection Server, this step varies:
◦ If you have just finished configuring other properties for the Connection Server and have not yet set the environment variable and started it, leave the file open and continue to the next step.
◦ If you have previously started your Connection Server, stop it and then open the configuration file using a text editor. Continue to the next step.
2. Locate the cxserver.protocol.http-client group.
3. Ensure that the HTTP keep-alive enabled setting is set as shown here:
http-client {
keep-alive-enabled = true
. . .
}
4. An HTTP client is created per event loop, so keep that in mind when sizing the connection pool. The pool size is specified in the Vert.x configuration property, cx-server.protocol.vertx.event-loop-pool-size. The following example uses the default value:
http-client {
keep-alive-enabled = true
max-connection-pool-size = 50
. . .
}
5. An HTTP Websocket client is created per event loop, so keep that in mind when sizing max-websockets. The event loop pool size is specified in the Vert.x configuration property, cx-server.protocol.vertx.event-loop-pool-size. The following example uses the default value:
http-client {
keep-alive-enabled = true
max-connection-pool-size = 50
max-websockets = 50
. . .
}
6. Depending on the anticipated traffic, set the size of the wait queue that holds requests when all connections in the connection pool are in use. A value of -1 results in an unbounded queue being used. A value of 0 means that the request is immediately rejected if all connections are busy. The rejection results in a 503 Service unavailable response.
http-client {
keep-alive-enabled = true
max-connection-pool-size = 50
max-wait-queue-size = 10
}
7. By default, the Tunneling Manager is configured to allow a maximum of 50 concurrent tunneling sessions through the Connection Server. If this value suffices, continue to the next step. To change this number, locate the protocol.tunneling group and change the value of the property, max-concurrent-tunnels:
protocol (
. . .
tunneling {
max-concurrent-tunnels = 50
. . .
}
}
8. If desired, you can configure the HTTP headers to copy from the incoming tunneling WebSocket request to the back-end WebSocket request. The client side uses cookies while the server side uses the application key. You will need to add the headers-to-copy property to the tunneling group, with the desired values. Here are the default headers:
protocol (
. . .
tunneling {
max-concurrent-tunnels = 50
headers-to-copy = ["appKey", "Cookie"]
. . .
}
}
|
|
This property takes an array of Strings, with the server-side header first and the client-side header second.
|
9. If you have not configured the trust store for the http-client, complete Step 7 in the Optional Configuration section of the Minimal Configuration topic.
10. Save the file.
11. At this point, you have the following options:
◦ If you want to configure metrics reporting now, leave your configuration file open and see Configuring Metrics Reporting.
◦ Close the file and set the environment variable to point to your configuration file, as explained in Setting the Environment Variable.
◦ If you have previously started your Connection Server, close the file and start it again.