Our .NET CF 3.5 application connects to two different endpoints/URLs, https://api.reservix.de/1/system/time
and https://test.acm.reservix.io/graphql
, using Rebex HTTPS in the latest version 2019R3.
Sending two consecutive GET requests to the same URL within some seconds, we expect the HTTP session from the first request to be re-used in the second request.
Connecting to the first endpoint api.reservix.de
, this works as expected, as we can see in the Rebex debug log:
2019-09-13 18:39:02 DEBUG HttpRequest(1)[-190209506] HTTP: Using new HTTP session (1) provided by Rebex.Net.HttpRequestCreator(1).
…
2019-09-13 18:39:17 DEBUG HttpRequest(2)[-190209506] HTTP: Using
cached HTTP session (1) provided by Rebex.Net.HttpRequestCreator(1).
Connecting to the second endpoint test.acm.reservix.io
, the HTTP session is not re-used, as we can see in the Rebex debug log:
2019-09-13 18:34:52 DEBUG HttpRequest(1)[303891110] HTTP: Using new HTTP session (1) provided by Rebex.Net.HttpRequestCreator(1).
…
2019-09-13 18:34:59 DEBUG HttpRequest(1)[303891110] HTTP: Closing HTTP session (1).
2019-09-13 18:35:06 DEBUG HttpRequest(2)[303891110] HTTP: Using new HTTP session (2) provided by Rebex.Net.HttpRequestCreator(1).
A difference we spotted between first and the second endpoint in the logs: There seems to be no TLS Session ID emitted by the server.
2019-09-13 18:39:08 DEBUG HttpRequest(1)[-190209506] TLS: Session ID:
0000 |6B-A3-02-D6-DD-0B-C2-38 A6-D0-CD-CC-A3-CA-7C-C8| k......8......|.
0010 |1E-A7-FD-DC-A3-14-78-0A B4-8D-CA-05-49-37-C5-5E| ......x.....I7.^
2019-09-13 18:39:08 INFO HttpRequest(1)[-190209506] HTTP: Sending request: GET /1/system/time
versus
2019-09-13 18:34:58 DEBUG HttpRequest(1)[303891110] TLS: Session ID:
2019-09-13 18:34:58 INFO HttpRequest(1)[303891110] HTTP: Sending request: GET /graphql
The application is the same for both endpoints, running on the same Windows Embedded Handheld 6.5 device via the same internet connection.
The Rebex HttpRequestCreator initialization code looks like this:
HttpRequestCreator creator = new HttpRequestCreator();
creator.Settings.AutoConnectToInternet = AutoConnectType.Enabled;
creator.Settings.HttpSessionCacheEnabled = true;
creator.LogWriter = new Rebex.FileLogWriter(path, Rebex.LogLevel.Debug);
creator.Register();
AsymmetricKeyAlgorithm.Register(EllipticCurveAlgorithm.Create);
AsymmetricKeyAlgorithm.Register(Curve25519.Create);
The code starting requests looks like this:
HttpRequest request = (HttpRequest)WebRequest.Create(url);
try {
using (var response = (HttpResponse)request.GetResponse()) {
try {
…
} finally {
if (response != null) {
response.Close();
}
}
}
} finally {
if (request != null) {
request.Abort();
}
request = null;
}
Basically, the connection can be re-used for the second request on both endpoints, as we observed using curl [url] [url] -v --tlsv1.2
with the following output:
Connected to api.reservix.de (46.243.94.27) port 443 (#0)
…
Connection #0 to host api.reservix.de left intact
Found bundle for host api.reservix.de: 0x207948b34d0 [can pipeline]
Re-using existing connection! (#0) with host api.reservix.de
… and also:
Connected to test.acm.reservix.io (143.204.214.14) port 443 (#0)
…
Connection #0 to host test.acm.reservix.io left intact
Found bundle for host test.acm.reservix.io: 0x26a4d462610 [can pipeline]
Re-using existing connection! (#0) with host test.acm.reservix.io
From our point of view, Rebex HTTPS should re-use the HTTP session on both endpoints as well.
Without reusing HTTP sessions, consecutive requests to the same endpoint consume much more time and data, though the handshake has to be done before every new request again. Therefore we classify the reason for this behavior as a serious bug.