API Gateway: Connection timeouts when using Keep-Alives and ETags for caching responses.
book
Article ID: 190539
calendar_today
Updated On:
Products
CA API GatewayCA Microgateway
Issue/Introduction
This article discusses a rare situation where the combination of ETags headers and Keep-Alives ends up in timeouts on the Gateway side.
The use-case is trying to use Keep-Alives in the HTTP connection to a backend which is serving up 304 HTTP status codes and ETags in the response headers. The expected behaviour is that the API Gateway would continue to receive the 304 HTTP status codes as long as nothing changed for the caching mechanism, and keep-alives at the HTTP layer would be used and ETags are present in the response headers. The unfortunate behaviour that is observed is that after a few calls the API Gateway times out instead, severing the connection.
This is being tracked as a known issue internally as DE438142. Please look out for this in the "Resolved Issues" list for future API Gateway versions, as that will be when the fix is released.
Environment
This issue affects all supported API Gateway versions as of the publishing date of this article.
Cause
This issue is believed to be caused by a defect in the Apache httpclient library which the API Gateway depends on for managing keep-alives and other HTTP-related items. The defect in the Apache httpclient library appears only when the combination of keep-alives and ETags are present. If ETags are present but the use-case does not require keep-alives, for example, it works as expected.
Resolution
There is no resolution known at this time, only a workaround. The workaround is to simply not use keep-alives. Using ETags and no keep-alives will result in the expected behaviour for that situation.
Until the Apache Foundation fixes the issue in the httpclient library, there is nothing else that can be done. When a fix is issued from the Apache Foundation for the httpclient library, the API Gateway will jump to the patched version of the httpclient library and will test and release the fix in a future API Gateway version. This will likely come as a CR or a major version such as 10.2 for example (no commitment to 10.2 exists, just using this as an example).