HTTP/2 on BIG-IP: the Full Proxy, the MRF Router, and iRules per Stream

BIG-IP can speak HTTP/2 on both sides of the proxy, and the setting that makes it possible, the HTTP MRF Router, swaps the connection-oriented TCP proxy for message routing. What the virtual server is built from, what the design rules out (OneConnect, hash and SSL persistence, connection mirroring, NTLM), how iRules behave when every stream is routed on its own, and the bug records worth checking against your build.

carries many streams over one connection. That suits the client and strains a proxy built around one request per connection. The history of the HTTP versions explains the framing; this article is about what BIG-IP does with it. F5's HTTP/2 full-proxy chapter states the capability plainly: the system can process HTTP/2 requests and responses on both the client and server sides, carrying multiple simultaneous, bidirectional streams "through the use of the BIG-IP system's message-routing proxy, instead of the traditional connection-oriented TCP proxy" (configuring HTTP/2 full-proxy support).

What the full proxy is built from

The chapter's steps assemble the virtual server from five parts:

an HTTP profile on the client side, with the server side set to Use Client Profile or given a profile of its own;
the clientssl-secure and serverssl-secure profiles, chosen because they disable mid-stream SSL renegotiation, which the chapter calls a requirement for an HTTP/2 full-proxy deployment;
an HTTP/2 profile on the client side and, through Use Client Profile or a second profile, on the server side, with Enforce TLS Requirements enabled (also required);
the HTTP MRF Router check box, which the chapter singles out as the setting to make sure you select;
a pool whose members are HTTP/2-capable web servers.

F5's profile overview, K04412053, adds the history and one guard rail. Client-side HTTP/2 arrived in 11.6.0 and server-side processing in 14.1.0, when the webacceleration and OneConnect profiles were not supported in full proxy mode; webacceleration support in full proxy mode followed in 15.0.0. Its note under Enforce TLS Requirements says that adding a client SSL profile to an HTTP/2 virtual server raises a configuration error if TLS renegotiation is not disabled and the (elliptic curve ephemeral) cipher is not allowed.

The HTTP/2 profile's settings and defaults, from the same chapter and, for the first two rows, from K04412053:

Setting	Default	What it sets
Concurrent Streams Per Connection	10	Maximum number of concurrent streams BIG-IP advertises to the client in the SETTINGS exchange
Connection Idle Timeout	300	Seconds an HTTP/2 connection may stay idle before BIG-IP sends GOAWAY to close it
Activation Modes		What makes BIG-IP handle an incoming connection as HTTP/2 (the alternative is Always)
Frame Size	2048	Size, in bytes, of the data frames HTTP/2 produces
Receive Window	32	Size, in kilobytes, of the HTTP/2 flow-control receive window
Write Size	16384	Size, in bytes, of the SSL records HTTP/2 produces
Header Table Size	4096	Table size for header compression, which the chapter marks as unused; K04412053 describes it as the maximum size, in bytes, of the dynamic table of HTTP/2 header compression ( 7541, section 4.2)

The two F5 documents disagree on Header Table Size, so check its behaviour on your release before tuning it. K04412053 also dates the activation modes: BIG-IP has not accepted NPN (Next Protocol Negotiation) since 13.1.0, and Always, which runs HTTP/2 in plain text, was developed for debugging only and requires removing the client SSL profiles from the virtual server.

The chapter's Applies To list runs from 15.0.1 to 21.0.0, so confirm each point against the documentation for your release before relying on it on 21.1.

What it rules out

The same chapter lists the features that are not supported in an HTTP/2 full-proxy deployment: OneConnect, the Hash and SSL persistence types, and connection mirroring in high-availability configurations. Virtual Desktop Infrastructure (VDI) is not supported either, and a virtual server carrying both an HTTP/2 profile and a VDI profile can return ERR_HTTP2_PROTOCOL_ERROR. And the HTTP/2 protocol is not compatible with . K04412053 adds that load balancing of gRPC calls in HTTP/2 streams is an enhancement F5 is tracking, ID1311961. Each line meets a decision made elsewhere: connection reuse, choosing a persistence method and persistence mirroring.

iRules, one stream at a time

With the MRF router enabled, BIG-IP load balances each HTTP/2 stream individually, and the message-routing framework raises an MR_EGRESS event before the request passes through the server-side stack. F5 describes this mechanism in Bug 2294701, which also shows what does not belong in that event: HTTP::respond in MR_EGRESS fails with "Can't execute in the current context". The record lists 17.5.0 to 17.5.1.10 as known affected with no fix, and its workaround is to answer earlier, from a client-side event such as HTTP_REQUEST, or later, from a server-side event such as HTTP_REQUEST_RELEASE.

Four more habits keep per-stream rules predictable.

Variables. The HTTP2 command reference notes that with an HTTP/2 profile in versions before 14.1, variables set before HTTP_REQUEST are not carried over to later events. A rule written in that era may still carry its workaround.
Scope. In a full proxy, with HTTP/2 profiles on both sides, each stream has its own Tcl context and so its own local variables, by design, so that streams never access the same set concurrently (K24532424). A value set while handling one stream is not there for the next; where a value must cross streams, the article points to session table variables, which persist across streams within the same TCP session.
Version checks. HTTP::version returns "2.0" for HTTP/2 from v16.0, though it cannot set it, and HTTP2::active tells a rule whether a request was generated by HTTP/2.
Priorities. Bug 1043985 records that after an iRule is edited, the execution order of events with the same priority may change; the workaround is to give iRules that handle the same event explicit priorities. The priority article covers the command.

Testing it, and reading it

curl negotiates HTTP/2 inside the TLS handshake for an HTTPS URL, which matches the profile's ALPN activation mode. Its manual adds that curl does not itself insist on TLS 1.2 or higher for HTTP/2 over HTTPS, although the specification requires it, and that --tlsv1.2 adds the requirement (curl manual).

# Negotiate HTTP/2 through the TLS handshake and insist on TLS 1.2 or later, as the specification requires
curl --http2 --tlsv1.2 -sv https://www.example.com/ -o /dev/null

When you test an iRule or profile change, use a new connection. K13253 states that changes to local traffic objects such as iRules, monitors and profiles apply only to connections established after the change, while existing connections keep the options they started with, so an HTTP/2 client that reuses one connection for many requests can go on showing the old behaviour. The article's command for clearing a test client's existing connections is tmsh delete /sys connection cs-client-addr <client> cs-server-addr <virtual> cs-server-port <port>.

In a capture, every HTTP/2 frame begins with a 9-octet frame header, and a stream identifier of zero is used for connection control messages rather than for a request (RFC 9113). Frames on stream zero concern the connection as a whole; frames on any other stream belong to one exchange of request and response.

The stream limit is a security setting

Concurrent Streams Per Connection defaults to 10, and F5's advisory for -2023-44487, the HTTP/2 Rapid Reset attack, says that default was set because F5 had anticipated this type of flaw in the protocol (K000137106). With an HTTP/2 profile on the virtual server, the default behaviour keeps exploit attempts from reaching the load-balanced application; a FastL4 virtual server, or one with only a TCP profile that passes HTTP/2 through to the pool, has no visibility into the HTTP/2 traffic and cannot protect the members. The advisory's mitigations follow from that: iRules are not an effective mitigation; where a configuration can use either protocol, F5 recommends HTTP with HTTP/2 disabled; and where HTTP/2 must stay, lowering the concurrent streams per connection lessens the impact, at a possible cost in performance. The indicator is in the HTTP/2 profile statistics: RST_STREAM frames received should be low next to DATA and SETTINGS frames, and a count that far exceeds them may mean an attack. The BIG-IP fixes are 17.1.1.3, 16.1.4.3 and 15.1.10.4; 14.x and 13.x will not be fixed.

The builds that matter

F5's Bug Tracker and security advisories, read on 26 October 2026, list these records on the HTTP/2 full-proxy path. Records change after publication, so re-read one before you plan around it.

Bug	What happens	Fixed in
2251517	A Stream profile is rejected on a virtual server that carries an HTTP or HTTP/2 profile and the HTTP router	21.1.0
2331445	A connection stalls after about 16 KB when one message queues more DATA frames in one egress pass than the profile's write size; the workaround is a frame size lower than the write size	21.1.0.2, 17.5.1.9, 17.1.3.5
1921049	Updating an policy in use by HTTP/2 connections can send them RST_STREAM; the workaround is not to update it while HTTP/2 connections are active	21.0.0, 17.5.1.10, 17.1.3.6
1196505	BIG-IP may reset an HTTP/2 connection with `[F5RST:mrhttp_proxy bad transition]` when ASM is in use	21.1.0.3, 17.5.1.10, 17.1.3.6
1341093	Attaching a client SSL profile whose cipher rule uses TLS 1.3 ciphers only to a virtual server with an HTTP/2 profile raises a configuration error	21.1.0, 17.5.1.6, 17.1.3.2
1100421	With the HTTP router, server-side traffic can leave with the base instead of the masquerade MAC, and can pick non-floating addresses	21.1.0, 17.5.1.9
2294701	`HTTP::respond` fails in `MR_EGRESS` with the HTTP MRF Router; known affected 17.5.0 to 17.5.1.10	No fix listed
2304693 (CVE-2026-59762)	With an HTTP/2 profile on a virtual server, undisclosed requests can raise memory use until TMM restarts; the mitigation is a custom eviction policy with Slow Flow Monitoring enabled on the affected virtual server. The 21.1.0.1 release notes list it as "Improvements in HTTP/2 on TMM"	21.1.0.1, 21.0.0.3, 17.5.1.8, 17.1.3.4