Are global variables shared between all HTTP requests?

Any thoughts anyone?

Does each http request have it's own global variable or do they share one global variable?i understand it is shared.

 

 

Is HTTP Request 1 global variable still "ABC" or is it "ZAC"?it should be ZAC.

Thanks! In that case how would one achieve for each request to have it's own global variable vs. a share global variable?

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.