Bug ID 523513: COMPRESS::enable keeps compression enabled for a subsequent HTTP request.

Last Modified: Sep 13, 2023

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

Known Affected Versions:
11.5.1 HF1, 11.5.1 HF2, 11.5.1 HF3, 11.5.1 HF4, 11.5.1 HF5, 11.5.1 HF6, 11.5.1 HF7, 11.5.1 HF8, 11.5.1 HF9, 11.5.1 HF10, 11.5.1 HF11, 11.5.2 HF1, 11.5.3 HF1, 11.5.3 HF2, 11.5.4 HF1, 11.5.4 HF2, 11.5.4 HF3, 11.5.4 HF4, 11.4.1, 11.5.0, 11.5.1, 11.5.2, 11.5.3, 11.6.0, 11.6.1, 11.6.2, 11.6.3,,,,, 11.6.4, 11.6.5,,,, 12.1.0 HF1, 12.1.0 HF2, 12.1.1 HF1, 12.1.1 HF2, 12.1.2 HF1, 12.1.2 HF2

Fixed In:
12.0.0, 11.6.1 HF1, 11.5.4, 11.4.1 HF10

Opened: May 15, 2015

Severity: 3-Major

Related Article: K87832255


COMPRESS::enable keeps compression enabled for a subsequent HTTP request. The response for the first HTTP request enables the compression, but it is not used since the payload is empty. For the second HTTP request (whose URI indicates that it is not supposed to be compressed), the system still compresses the response because the first request did not disable compression.


Unintended compression for subsequent HTTP responses.


Subsequent HTTP requests in the same TCP connection. - First HTTP response contains empty payload and enabling the compression. - Second HTTP response still gets compressed.


Disable compression in the else case manually in the iRule using COMPRESS::disable.

Fix Information

Compression is now disabled after an HTTP response with empty payload for iRule-based enabling.

Behavior Change

Guides & references

K10134038: F5 Bug Tracker Filter Names and Tips