Bug ID 2277189: BIG-IP incorrectly sends HTTP2 HEADERS after DATA frame when using 'HTTP::respond' in 'LB_FAILED' irule event

Last Modified: Jul 28, 2026

Affected Product(s):
BIG-IP LTM(all modules)

Known Affected Versions:
17.1.0, 17.1.0.1, 17.1.0.2, 17.1.0.3, 17.1.1, 17.1.1.1, 17.1.1.2, 17.1.1.3, 17.1.1.4, 17.1.2, 17.1.2.1, 17.1.2.2, 17.1.3, 17.1.3.1, 17.1.3.2, 17.1.3.4, 17.5.0, 17.5.1, 17.5.1.2, 17.5.1.3, 17.5.1.4, 17.5.1.5, 17.5.1.6, 17.5.1.8, 21.0.0, 21.0.0.1, 21.0.0.2, 21.0.0.3, 21.1.0, 21.1.0.1

Opened: Apr 14, 2026

Severity: 4-Minor

Symptoms

Under certain conditions, the BIG-IP might send an HTTP2 DATA frame followed by HEADERS frame. Since this is an incorrect sequence (per RFC9113 section 8.1) the receiving device might respond with PROTOCOL_ERROR hence terminating the stream.

Impact

Client sends PROTOCOL_ERROR in response to the incorrect BIG-IP HTTP2 sequence.

Conditions

All of the below together: - HTTP::respond inside LB_FAILED - http2 profile - HTTP_REQUEST iRule event invoked Example iRule: when LB_FAILED { HTTP::respond 200 content "No available VS!\r\n" } when HTTP_REQUEST { }

Workaround

Use HTTP::respond inside HTTP_REQUEST event instead. Use 'active_members' to check availability of pool. Example iRule: when HTTP_REQUEST { if { [active_members /Common/pool-01] < 1 } { HTTP::respond 200 content "No available VS!\r\n" } }

Fix Information

None

Behavior Change

Guides & references

K10134038: F5 Bug Tracker Filter Names and Tips