Forum Discussion

Kai_Wilke's avatar
Kai_Wilke
Icon for MVP rankMVP
Dec 15, 2022
Solved

Dealing with iRule $variables for HTTP2 workload while HTTP MRF Router is enabled

Hi Folks, I like to start a discussion on how to deal with iRule $variables, which are traversing independed iRule events, in combination with HTTP2 workload and HTTP MRF Router enabled (e.g. HTTP2...
application delivery
  • Kai_Wilke's avatar
    Kai_Wilke
    Feb 12, 2023

    Hi Pete,

    Somehow found the cause of the variable glitch an a final workaround for my problem.

    If you set any local variables during the CLIENT_ACCEPTED event then the outlined strange variable beharior happens.

    If you dont set any variable during the CLIENT_ACCEPTED event, then the HTTP_REQUEST event is able to pass variables to the SERVER_CONNECTED and SERVERSSL_* events and you can also pass variable out of those events to the HTTP_REQUEST_RELEASE event.

    Looks like a very annoying bug. I would love to open a new case, but my MVP support contract just has become outdated.... 🤐

    Cheers, Kai

Kai_Wilke's avatar
Kai_Wilke
Icon for MVP rankMVP
Sep 17, 2025

The "14.1 limitation" mentioned in the HTTP2 CloudDoc is a different issue. The SERVER_CONNECTED and SERVERSSL_* $varible "bug" is still in place in TMOS 17.x.

K24532424 describes the intended $varible scoping behavior for MRF scenarios, but does not cover the bug that happens is you already set any $variables during "CLIENT_ACCEPTED". 

You may ask F5-Support to repro this issue.

 

Cheers, Kai

 

 

Juergen_Mang's avatar
Juergen_Mang
Icon for MVP rankMVP
Sep 17, 2025

but does not cover the bug that happens is you already set any $variables during "CLIENT_ACCEPTED". 

I asked exactly this.