Bug ID 583101: ADAPT::result bypass after continue causes bad state transition

Last Modified: Apr 19, 2021

Bug Tracker

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

Known Affected Versions:
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, 11.6.1 HF1, 11.6.1 HF2, 11.6.2, 11.6.2 HF1, 11.6.3,,,,, 11.6.4, 11.6.5,,,, 12.0.0, 12.0.0 HF1, 12.0.0 HF2, 12.0.0 HF3, 12.0.0 HF4, 12.1.0, 12.1.0 HF1, 12.1.0 HF2, 12.1.1, 12.1.1 HF1, 12.1.1 HF2, 12.1.2, 12.1.2 HF1, 12.1.2 HF2, 12.1.3,,,,,,,, 12.1.4,, 12.1.5,,,, 12.1.6

Fixed In:

Opened: Mar 25, 2016
Severity: 3-Major
Related AskF5 Article:


Tcl command 'ADAPT::result bypass' does not work in ADAPT_REQUEST_RESULT when the ICAP server has previously returned 100-continue.


ADAPT logs an unexpected state transition and resets the connection, making it impossible for iRules to replace the ICAP response.


iRules exist on a VS with an adapt profile, containing: when ADAPT_REQUEST_RESULT { ADAPT::result bypass } or when ADAPT_RESPONSE_RESULT { ADAPT::result bypass }


Avoid 'ADAPT::result bypass' commands in cases where there is no preview (either configured for no preview, or after the preview has been dropped due to a 100-continue or 200-ok ICAP response).

Fix Information

Tcl command 'ADAPT::result bypass' is allowed in ADAPT_REQUEST_RESULT and ADAPT_REPSONSE_RESULT at any time, even outside a preview (such as when the ICAP server has previously returned 100-continue and the preview has been dropped). No further payload is sent to the IVS, and further IVS response payload is ignored by ADAPT. The unmodified HTTP headers, any preview, and any future original payload bypass the IVS. A warning is logged in cases where some payload might have been lost (such as when there is no preview or it has been dropped, as is the case after ICAP 100-continue). The HTTP connections remain intact and amenable to user iRules replacing the content.

Behavior Change