Bug ID 599456: RAM Cache Churn with HTTP Compression Filter

Last Modified: Apr 28, 2025

Affected Product(s):
BIG-IP LTM(all modules)

Known Affected Versions:
13.0.0, 13.0.0 HF1, 13.0.0 HF2, 13.0.0 HF3, 13.0.1, 13.1.0, 13.1.0.1, 13.1.0.2, 13.1.0.3, 13.1.0.4, 13.1.0.5, 13.1.0.6, 13.1.0.7, 13.1.0.8, 13.1.1, 13.1.1.2, 13.1.1.3, 13.1.1.4, 13.1.1.5, 13.1.3, 13.1.3.1, 13.1.3.2, 13.1.3.3, 13.1.3.4, 13.1.3.5, 13.1.3.6, 13.1.4, 13.1.4.1, 13.1.5, 13.1.5.1

Opened: Jun 15, 2016

Severity: 3-Major

Symptoms

In certain configurations with certain kinds of content variation, RAM cache on a virtual that also has a httpcompression profile attached will experience greater than necessary cache churn.

Impact

Impact varies according to traffic pattern and number of documents that exhibit this variation. The result, however, is unnecessary cache content eviction, resulting in a greater number of origin web server requests.

Conditions

If a given URI produces content that varies in size, say because it varies by User-Agent, or is dynamically generated, and this variation crosses back and forth across the compression threshold, the HTTP compression filter will unnecessarily change the Vary header, causing cache churn.

Workaround

If possible, the server should be modified to give the proper Vary header in its responses. For content that might be compressed by the BIG-IP, the Vary header should be set to always include the Accept-Encoding header. An iRule may also be used to do this.

Fix Information

None

Behavior Change

Guides & references

K10134038: F5 Bug Tracker Filter Names and Tips