Last Modified: Nov 07, 2022
See more info
Known Affected Versions:
11.4.0, 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.6.0, 11.6.0 HF1, 11.6.0 HF2, 11.6.0 HF3
12.0.0, 11.6.0 HF4, 11.5.2, 11.4.1 HF9
Opened: Aug 26, 2014
Related Article: K15727
After sending an ICAP preview, the BIG-IP system waits for a response from the ICAP server. If the BIG-IP system receives the complete ICAP response before it has completed sending the ICAP request (for example, when the response contains an encapsulated 302 redirect), it stops sending the request payload and closes the TCP connection. However when a OneConnect profile (CONNPOOL filter) is on the IVS, the TCP connection to the ICAP server is not terminated.
The ICAP server cannot detect the end of the ICAP request so might get confused.
This occurs when the following conditions are met: -- Using ICAP and OneConnect profiles on an IVS. -- The BIG-IP ICAP client has resumed sending the request body on receiving a 200-OK response after the preview. -- ICAP server response completes before it has received the entire request body (for example, encapsulated redirect).
Do not use OneConnect. As an alternative, if the ICAP server completes its response, it could ignore any further input from the client until it detects another RESPMOD or REQMOD indicating the beginning of a new transaction. ICAP servers are not required to do this, but it would allow connection reuse in the case where the server completes its response before the request is complete.
In this release, if the BIG-IP system receives the complete ICAP response from the ICAP server before it has completed sending the ICAP request, and a OneConnect profile is on the IVS, the TCP connection to the ICAP server is terminated and that connection is not reused.