Bug ID 511782: The HTTP_DISABLED event does not trigger in some cases

Last Modified: May 14, 2019

Bug Tracker

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

Known Affected Versions:
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.2, 11.5.2 HF1, 11.5.3, 11.5.3 HF1, 11.5.3 HF2, 11.5.4, 11.5.4 HF1, 11.5.4 HF2, 11.5.4 HF3, 11.5.4 HF4, 11.5.5, 11.5.6, 11.5.7, 11.5.8, 11.5.9, 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.3.1, 11.6.3.2, 11.6.3.3, 11.6.3.4, 11.6.4, 12.0.0, 12.0.0 HF1, 12.0.0 HF2

Fixed In:
12.1.0, 12.0.0 HF3

Opened: Mar 11, 2015
Severity: 2-Critical
Related AskF5 Article:
K16424

Symptoms

HTTP_DISABLED is not triggered by the HTTP::disable iRule command, requests using the CONNECT method, and Web-sockets traffic.

Impact

The HTTP_DISABLED event does not trigger.

Conditions

If the HTTP filter is switched into pass-through mode by the HTTP::disable command, CONNECT requests, or via Web-sockets traffic.

Workaround

This issue has the following workaround: -- For HTTP::disable, add the logging code within HTTP_DISABLED after that iRule command. -- For CONNECT, use an iRule to match the method in HTTP_REQUEST, and check that 200 Connected is returned as the status in HTTP_RESPONSE. If so, invoke the logging code within HTTP_DISABLED. -- For Web-sockets, use an iRule to match the 101 Switching Protocols status code in HTTP_RESPONSE. If this happens invoke the logging code that is also within HTTP_DISABLED.

Fix Information

The iRule HTTP_DISABLED is now triggered as expected when using HTTP::disable iRule command, requests using the CONNECT method, and Web-sockets traffic.

Behavior Change