Last Modified: Sep 13, 2023
Affected Product(s):
BIG-IP LTM
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.3.1, 11.6.3.2, 11.6.3.3, 11.6.3.4, 11.6.4, 11.6.5, 11.6.5.1, 11.6.5.2, 11.6.5.3, 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.
Compression is now disabled after an HTTP response with empty payload for iRule-based enabling.