Forum Discussion
Kevin_Stewart
Mar 12, 2013Employee
There's really three kinds of "scope":
Global to the box
Global to the application
Local to the user
Global to the box is handled with static::variable syntax and is, as it implies, global to everything on the box - all iRules, all applications, all requests and response. Global variables are good for things that never change and are needed, um, globally... The "static::" syntax in front of the variable allows the global variable to be CMP (accessible from multiple TMM instances). If you write to a global variable anywhere but in RULE_INIT you break the CMP for that variable.
Global to the application isn't really a thing, unfortunately. You can create session tables that only a single application will access, but then the tables themselves are global.
Local to the user is a connection-specific scope. By connection I mean TCP (layer 4) connection. HTTP requests are finite and tied to a specific TCP session that is only available to a given client-server connection. If you create a local variable in an iRule it will exist for the life of that TCP session, which could most likely expire before the HTTP or SSL sessions do. You're mostly guaranteed that a variable created in an HTTP_REQUEST event will exist in the corresponding HTTP_RESPONSE, but not necessarily so from HTTP_REQUEST to another HTTP_REQUEST (it depends). The *best* solution then for a per-user "global" variable ACROSS TCP sessions is a persistence mechanism. Because we're talking about HTTP here, a stateless protocol, you can rely on things like browser cookies, client source IP addresses (good unless there's a NAT somewhere), SSL session IDs (not the best with browsers), programmatically-derived persistence (universal and hash), or any combination of these. The idea being that the client stores and transmits some token that identifies an existing "session", and that the BIG-IP has a table entry that stores some variables based on that session token.