Forum Discussion
Kai_Wilke
MVP
MVPDealing 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...
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_WilkeMVP
MVPHey PeteWhite,
finally found some time to experiment with MR_INGRESS and MR_EGRESS event and the MR::store and MR::restore commands.
Unfortunately those two commands are neither able to copy/link a given variable from lets say the "HTTP_REQUEST" event to the "SERVER_CONNECTED" event. And also not from "SERVER_CONNECTED" to lets say "HTTP_REQUEST_RELEASE" event.
SERVER_CONNECTED and SERVERSSL_* behaving slightly weirdo. Could you please double check the information you've provided?
This simple test illustrates the issue...
when CLIENT_ACCEPTED {
set CON_ID [TMM::cmp_unit][clock clicks]
set REQ_ID ""
log local0.debug "$CON_ID|$REQ_ID"
}
when HTTP_REQUEST {
set REQ_ID [TMM::cmp_unit][clock clicks]
log local0.debug "$CON_ID|$REQ_ID"
}
when REMAINING_EVENTS {
log local0.debug "$CON_ID|$REQ_ID"
}
Log output:
tmm1[17801]: Rule <CLIENT_ACCEPTED>: 11674705152203080|
tmm1[17801]: Rule <HTTP_REQUEST>: 11674705152203080|11674705152236713
tmm1[17801]: Rule <MR_INGRESS>: 11674705152203080|11674705152236713
tmm1[17801]: Rule <LB_SELECTED>: 11674705152203080|11674705152236713
tmm1[17801]: Rule <SERVER_CONNECTED>: 11674705152203080|
tmm1[17801]: Rule <SERVERSSL_CLIENTHELLO_SEND>: 11674705152203080|
tmm1[17801]: Rule <SERVERSSL_SERVERHELLO>: 11674705152203080|
tmm1[17801]: Rule <SERVERSSL_SERVERCERT>: 11674705152203080|
tmm1[17801]: Rule <SERVERSSL_HANDSHAKE>: 11674705152203080|
tmm1[17801]: Rule <MR_EGRESS>: 11674705152203080|11674705152236713
tmm1[17801]: Rule <HTTP_REQUEST_RELEASE>: 11674705152203080|11674705152236713
tmm1[17801]: Rule <HTTP_RESPONSE>: 11674705152203080|11674705152236713
tmm1[17801]: Rule <MR_INGRESS>: 11674705152203080|11674705152236713
tmm1[17801]: Rule <MR_EGRESS>: 11674705152203080|11674705152236713
tmm1[17801]: Rule <HTTP_RESPONSE_RELEASE>: 11674705152203080|11674705152236713
Adding MR::store and/or MR::restore wont make any difference. The SERVER_CONNECTED and SERVERSSL_* events wont see the $var added by HTTP_REQUEST...
Cheers, Kai
Kai_WilkeMVP
MVPHi 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