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

MR::store, MR::restore as well as most other MR::* command are broken for HTTP2 workloads. MRF-HTTP2 is a very purpose driven, optimized and stripped down MRF-Mode.

Regarding HTTP_REQUEST_SEND: You may check the HTTP2-MRF event flow observations i gathered during my DEBUG_PAGE explorations. Between the lines your will find the solution for this...

	# Information: Dealing with Keep-Alive Sessions for HTTP2 is sometimes annoying. Restart your browser or kill connections 
	#              via TMSH if you feel that LTM does not do what you want... 

	# CLIENT_ACCEPTED
	# CLIENTSSL_CLIENTHELLO
	# CLIENTSSL_CLIENTCERT
	# CLIENTSSL_HANDSHAKE
	# CLIENTSSL_DATA_CS_INGRESS

	# Note: HTTP2::disconnect is badly needed to trigger CLIENTSSL_* events on every single request.
	#       Unfortunately Chromium will stall after 6 GOAWAY responses (used by HTTP2::disconnect) for up to 5 minutes, because of 
	#       a well known bug (see Chromium bug tracker ID=1030255).
	#       You may use Fiddler Everywhere as MitM to get full HTTP2::disconnect support to dig into the CLIENTSSL_* events. But even 
	#       then you will end up with limited DEBUG PAGE support because of lacking SSL Renegotiation to inject cookies backwards 
	#       into the session.
	#
	#       My best advise is to debug clientside SSL handshakes using HTTP/1 to get full a interactive experience. 

	# HTTP_REQUEST

	# MR_INGRESS_CS (the event is called MR_INGRESS, but filtering is based on [IP::remote_addr] eq [IP::client_addr])

	# PERSIST_DOWN (async event) 
	# LB_SELECTED (async event)
	# LB_FAILED (async event if error happens during SS connection establishment) 
	# MR_FAILED (async event if error happens during SS connection establishment) 

	# Note: LB_FAILED and MR_FAILED trigger at the same time. Both event allow HTTP2 based responses. 

	# SERVER_CONNECTED
	# SERVERSSL_CLIENTHELLO_SEND
	# SERVERSSL_SERVERHELLO
	# SERVERSSL_SERVERCERT
	# SERVERSSL_HANDSHAKE
	# SERVERSSL_DATA_SS_EGRESS

	# Note: SERVERSSL_DATA_SS_EGRESS (the event is called SERVERSSL_DATA) get triggered when SSL::collect was called in SERVERSSL_HANDSHAKE  
	#       It seems to be egress HTTP2.0 communication to the backend server to negotiate the HTTP2 session.

	# MR_EGRESS_SS (the event is called MR_EGRESS, but filtering is based on [IP::remote_addr] eq [IP::server_addr])
	# HTTP_REQUEST_RELEASE 

	# Note: The HTTP_REQUEST_SEND event does not trigger for HTTP2 in GW mode (could be a bug). Only HTTP_REQUEST_SEND triggers.

	# SERVERSSL_DATA_SS_INGRESS

	# Note: SERVERSSL_DATA_SS_INGRESS (the event is called SERVERSSL_DATA) get triggered when SSL::collect was called in HTTP_REQUEST_RELEASE  
	#       It seems to be ingress HTTP2.0 communication from the backend server. 
	#       The event is able to receive a cookie header via variable, but you can not pass information to other events via table nor variables (at least not stable!). 
	#       Using static:: namespace allows a stable cross communication to the HTTP RESPONSE event to become able to deliver the page. 

	# HTTP_RESPONSE
	# MR_INGRESS_SS
	# MR_EGRESS_CS
	# HTTP_RESPONSE_RELEASE

	# Note: Using the DEBUG PAGE for event trigger after HTTP_RESPONSE_RELEASE is not possible, because we wont get a chance 
	#       to send a HTTP response after this event has been triggered.
	#       You may still trigger the page on those event an store the HTLM to [table] and review the content later, 
	#       but this is not very useful.

	# CLIENTSSL_DATA_CS_EGRESS

	# Note: CLIENTSSL_DATA_CS_EGRESS (the event is called CLIENTSSL_DATA) get triggered when SSL::collect was called in HTTP_RESPONSE_RELEASE  
	#       It seems to be egress HTTP2.0 communication to the client. 

Note: Whenever you see *_CS and *_SS or even *_CS_INGRESS  and *_CS_EGGRESS event names. It means that a given even triggers more tan once during a single HTTP Request/Response.

Drop me an E-Mail and I will give you a personal DEBUG_PAGE session for HTTP2 with MRF-Router 

Cheers, Kai