Bug ID 427423: HTTP iRule commands don't work correctly when invoked by other filters

Last Modified: Feb 13, 2019

Bug Tracker

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

Known Affected Versions:
10.0.0, 10.0.1, 10.1.0, 10.2.0, 10.2.1, 10.2.2, 10.2.3, 10.2.4, 11.0.0, 11.1.0, 11.2.0, 11.2.1, 11.3.0, 11.4.0, 11.4.1

Fixed In:
11.5.0

Opened: Aug 08, 2013
Severity: 3-Major
Related AskF5 Article:
K15126

Symptoms

If a middle-layer filter raises an event and wants to use an HTTP iRule command, that command might not work correctly. Typically, HTTP will return an error instead of executing it.

Impact

In events raised by middle-layer filters, HTTP iRules would not work correctly.

Conditions

If another filter handles a request itself, the server-side HTTP filter never sees that request. This means that the "owned" bit is never flipped in the http_data structure. So when HTTP iRules are invoked, HTTP is confused over whether the client or server side should own the data. To be safe, HTTP rejects the command with an error.

Workaround

None.

Fix Information

HTTP now recognizes that "generic" iRule commands can be executed on both the request and response. Instead of failing when the http_data structure ownership status is mismatched, HTTP will execute the iRule command. The remaining "non-generic" HTTP commands that will still fail are: HTTP::version HTTP::collect HTTP::release HTTP::redirect HTTP::respond HTTP::retry HTTP::close HTTP::header insert_modssl_fields The commands that must be invoked in a request are: HTTP::method HTTP::uri HTTP::path HTTP::query The commands that must be invoked in a response are: HTTP::status HTTP::is_redirect This means that HTTP commands can now be executed in many more events. (Those raised by other filters.)

Behavior Change