Bug ID 472092: ICAP loses payload at start of request in response to long execution time of iRule

Last Modified: Oct 16, 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.3.0, 11.4.0, 11.4.1, 11.5.0, 11.5.1, 11.5.2, 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.0 HF4, 11.5.3, 11.4.1 HF6

Opened: Jul 17, 2014

Severity: 3-Major

Related Article: K16311

Symptoms

A long-running iRule in ICAP_REQUEST can cause the loss of payload while the iRule is running, resulting in the beginning of the payload being omitted in the request to the ICAP server. (Note that headers are unaffected.)

Impact

ICAP request to ICAP server can lose the beginning of the payload.

Conditions

This issue occurs when the following conditions are met: -- request-adapt or response-adapt is used. -- IVS with ICAP. -- iRule on ICAP_REQUEST event that takes a long time to execute.

Workaround

When possible, keep iRule duration short by minimizing processing in ICAP_REQUEST and avoiding unnecessary processing, or move the processing elsewhere.

Fix Information

The complete request payload is now sent to the ICAP server, even in the presence of a long-running iRule in ICAP_REQUEST.

Behavior Change

Guides & references

K10134038: F5 Bug Tracker Filter Names and Tips