Last Modified: Feb 13, 2019
See more info
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
Opened: Aug 08, 2013
Related AskF5 Article: K15126
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.
In events raised by middle-layer filters, HTTP iRules would not work correctly.
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.
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.)