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

Was this article helpful?

12 Comments

Sort By
Show More
  • 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