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

Last Modified: Nov 07, 2022

Bug Tracker

Affected Product:  See more info
BIG-IP LTM(all modules)

Known Affected Versions:
11.4.1, 11.5.0, 11.5.1, 11.5.1 HF1, 11.5.1 HF10, 11.5.1 HF11, 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.10, 11.5.2, 11.5.2 HF1, 11.5.3, 11.5.3 HF1, 11.5.3 HF2, 11.6.0, 11.6.0 HF1, 11.6.0 HF2, 11.6.0 HF3, 11.6.0 HF4, 11.6.0 HF5, 11.6.0 HF6, 11.6.0 HF7, 11.6.0 HF8, 11.6.1

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:


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