Last Modified: Dec 20, 2023
Affected Product(s):
BIG-IP TMOS
Known Affected Versions:
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.0.0, 12.0.0 HF1, 12.1.0 HF1, 12.0.0 HF2, 12.1.0 HF2, 12.0.0 HF3, 12.0.0 HF4, 12.1.1 HF1, 12.1.1 HF2, 12.1.2 HF1, 12.1.2 HF2, 12.1.0, 12.1.1, 12.1.2, 12.1.3, 12.1.3.1, 12.1.3.2, 12.1.3.3, 12.1.3.4, 12.1.3.5, 12.1.3.6, 12.1.3.7, 12.1.4, 12.1.4.1, 12.1.5, 12.1.5.1, 12.1.5.2, 12.1.5.3, 12.1.6, 13.0.0, 13.0.0 HF1, 13.0.0 HF2, 13.0.0 HF3, 13.0.1, 13.1.0, 13.1.0.1, 13.1.0.2, 13.1.0.3, 13.1.0.4, 13.1.0.5, 13.1.0.6, 13.1.0.7, 13.1.0.8, 13.1.1, 13.1.1.2, 13.1.1.3, 13.1.1.4, 13.1.1.5, 13.1.3, 13.1.3.1, 13.1.3.2, 13.1.3.3, 13.1.3.4, 13.1.3.5, 13.1.3.6, 13.1.4, 13.1.4.1, 13.1.5, 13.1.5.1, 14.0.0, 14.0.0.1, 14.0.0.2, 14.0.0.3, 14.0.0.4, 14.0.0.5, 14.0.1, 14.0.1.1, 14.1.0, 14.1.0.1, 14.1.0.2, 14.1.0.3, 14.1.0.5, 14.1.0.6, 14.1.2, 14.1.2.1, 14.1.2.2, 14.1.2.3, 14.1.2.4, 14.1.2.5, 14.1.2.6, 14.1.2.7, 14.1.2.8, 14.1.3, 14.1.3.1, 14.1.4, 14.1.4.1, 14.1.4.2, 14.1.4.3, 14.1.4.4, 14.1.4.5, 14.1.4.6, 14.1.5, 14.1.5.1, 14.1.5.2, 14.1.5.3, 14.1.5.4, 14.1.5.6, 15.0.0, 15.0.1, 15.0.1.1, 15.0.1.2, 15.0.1.3, 15.0.1.4, 16.0.0, 16.0.0.1, 16.0.1, 16.0.1.1, 16.0.1.2, 16.1.0, 16.1.1, 16.1.2, 16.1.2.1, 16.1.2.2, 16.1.3, 16.1.3.1, 16.1.3.2, 16.1.3.3, 16.1.3.4, 16.1.3.5, 16.1.4, 16.1.4.1, 16.1.4.2
Fixed In:
15.1.0
Opened: Jul 24, 2018 Severity: 3-Major
Payload data is collected at the HTTP_REQUEST event and finishes collecting (HTTP::release) when the NAME_RESOLVED event occurs. On releasing, data is forwarded to the serverside, triggering the HTTP_REQUEST_SEND event. When trying to raise HTTP_REQUEST_SEND, the iRule queues it and returns IN_PROGRESS, because the system is already in the process of running TCLRULE_NAME_RESOLVED. (Nested iRules: TCLRULE_NAME_RESOLVED -> TCLRULE_HTTP_REQUEST_SEND) Due to the IN_PROGRESS status, tcp_proxy skips forwarding HUDCTL_REQUEST to the serverside, but not the subsequent payload. So the HTTP filter considers this an invalid action.
The second request gets reset, and the system logs errors in the LTM log file.
-- Standard virtual server with iRules attached (for example, using the following configuration for a virtual server): when HTTP_REQUEST { HTTP::collect NAME::lookup @10.0.66.222 'f5.com' } when NAME_RESOLVED { HTTP::release } when HTTP_REQUEST_SEND { log local0. "Entering HTTP_REQUEST_SEND" } -- Client sends two HTTP Post requests. -- After the first request, the second connection is kept alive (for example, by using HTTP header Connection) so that the second request can reuse the same connection.
To avoid nested iRules in this instance, simply remove the HTTP_REQUEST_SEND from the iRule.
None