List all assigned variables

Hi Vernon,

there exist some valid usecases to perfrom variable deletions, esp. if long living keep-alive connections are beeing used. I guess the most important ones are:

• Its frees memory at your wish (e.g. a set http_response [HTTP::payload] containig just 100kbyte for the entire connection lifetime instead of just a few CPU clicks to process the information will hurt)
• Its required if [info exists var_name] is used as controlstatement to trigger certain codeblocks based on previous (rare) conditions or to simplify the communication between independent events.

• Using a well designed variable handling based on request "flows" (e.g. accessing 100 objects below of a certain /uri) will not overwrite an already existing variable on each request. It would remove/assign the variables just in the case a "flow change" occours (accesing a different /uri). See the example below...

  when CLIENT_ACCEPTED {
     set session(flow) "" 
  } 
  when HTTP_REQUEST { 
     unset -nocomplain temp 
     if { [set $temp(low_path) [string tolower [HTTP::path]]] eq "/path1" } then { 
        if { $session(flow) eq "path1" } then { 
           Keep the configuration 
        } else { 
           set session(flow) "path1" 
           unset -nocomplain conf 
           set conf(param1) "xyz" 
           set conf(param3) true 
           set conf(param5) true 
           set conf(param7) false 
           set conf(param9) true 
           set conf(param11) false 
           set conf(param13) false 
           set conf(param15) true 
        } 
     } else { 
        if { $session(flow) eq "else" } then { 
           Keep the configuration 
        } else { 
           set session(flow) "else" 
           unset -nocomplain conf 
           set conf(param1) "abc" 
           set conf(param2) true 
           set conf(param3) false 
           set conf(param4) true 
           set conf(param6) true 
           set conf(param8) false 
           set conf(param10) true 
           set conf(param14) false 
           set conf(param30) false 
           set conf(param41) true 
        } 
     } 
     if { [info exists conf(param1)] } then { 
        Trigger codblock 1 
        set temp(string1) "50bytes" 
     } 
     # ...
     if { [info exists conf(param20)] } then { 
        Trigger codeblock 20 
        set temp(string20) "100bytes" 
     } 
  } 
  when HTTP_REQUEST_DATA { 
     if { [info exists conf(param21)] } then { 
        Trigger codeblock 20 
        set temp(request_payload) [HTTP::payload] 
        Code of your choice... 
        unset -nocomplain temp 
     } 
     # ... 
     if { [info exists conf(param40)] } then { 
        Trigger codeblock 40 
        set temp(string40) "50bytes" 
     } 
  } 
  when HTTP_RESPONSE { 
     if { [info exists conf(param41)] } then { 
        Trigger codeblock 41 
        set temp(string41) "100bytes" 
     } 
     # ... 
     if { [info exists conf(param60)] } then { 
        Trigger codeblock 60 
        set temp(string) "20bytes" 
     } 
  } 
  when HTTP_RESPONSE_DATA { 
     if { [info exists conf(param61)] } then {
        Trigger codeblock 61 
        set temp(request_payload) [HTTP::payload] 
        Code of your choice
        unset -nocomplain temp 
     } 
     # ... 
     if { [info exists conf(param80)] } then { 
        set temp(string) "20bytes" 
        Trigger codeblock 80 
     } 
  }

The more complex the content-switching scenario gets and the more independent ruleset and codeblocks are required to support the individual backend ressources, the more important a good variable handling will be.

Interesting note on using flow: I've also asked the F5 support to rollback the [pool] selection behavior in combination with [ONECONNECT] to the state of pre TMOS v12.1. Its now reverting the currently selected pool back to the default pool on each single HTTP request, so that the mentioned flow mechanic isn't able to offload the pool selections anymore (it has saved >10 CPU clicks on each single request in previous TMOS versions). ... 😞

Cheers, Kai