SPDY/HTTP2 Profile Impact on Variable Use

When using SPDY/HTTP2 profile, TCL variables set before the HTTP_REQUEST event are not carried over to further events. This is by design as the current iRule/TCL implementation is not capable of handling multiple concurrent events, which may be they case with SPDY/HTTP2 multiplexing. This is easily reproducible with this simple iRule:

when CLIENT_ACCEPTED {
  set default_pool [LB::server pool]
}
when HTTP_REQUEST {
  log local0. "HTTP_REQUEST EVENT Client [IP::client_addr]:[TCP::client_port] - $default_pool -" 
#  - can't read "default_pool": no such variable while executing "log local0. "HTTP_REQUEST EVENT -- $default_pool --"
}

Storing values in a table works perfectly well and can be used to work around the issue as shown in the iRule below.

when CLIENT_ACCEPTED {
  table set [IP::client_addr]:[TCP::client_port] [LB::server pool]
}
when HTTP_REQUEST {
  set default_pool [table lookup [IP::client_addr]:[TCP::client_port]]
  log local0. "POOL: |$default_pool|"
}

This information is also available in the wiki on the HTTP2 namespace command list page.

Published Dec 19, 2016
Version 1.0
application delivery
devops
http2
iRules
LTM
spdy
  • Kai_Wilke's avatar
    Kai_Wilke
    Icon for MVP rankMVP
    Dec 21, 2016

    Hi Jason,

    how about using 

    static::variables
    to store those information? Should be slightly more friendly to CMP, isn't it?

    when CLIENT_ACCEPTED {
    set static::(DefPool_[virtual]) [LB::server pool]
}
when HTTP_REQUEST {
    log local0. "POOL: |$static::(DefPool_[virtual])|"
}

    Can you hand out some additional information how HTTP/2 request are processed by the TCP runtime environment? Are those HTTP/2 requests handled as a child stackframe 

    ([info level] = 3
    ) of the TCP connection (
    [info level] = 2
    )? If a child stackframe is used, can 
    [uplevel]
    / 
    [upvar]
    be used to access the TCP connection variables?

    Cheers, Kai