Session Table iRules

Understandable. Let's look at the table add command from the wiki:

 

 

table add [-notouch] [-subtable name] key value [timeout [lifetime]]

 

 

The first thing to understand is that the table command is a new and improved way of accessing the original session table - a bit of memory initially set aside to store persistence information but made way more useful by allowing essentially anything to be stored in it. The original session table had some significant limitations, so the table command represents a new and more flexible way to store arbitrary information in quasi-table format, in system memory. Using the table command without the -subtable option is roughly the same as accessing the original (flat) session table. So the -subtable option allows you to separate your data into distinct (memory?) spaces, specified by the "name" argument which is completely arbitrary. For example, "table add -subtable FOO" creates a subtable called "FOO". It's helpful to think of a hash structure in terms of the key and value, or perhaps a table that only supports TWO columns of data. The key is another arbitrary value intended as an index to the data in the "value" column. It's generally important, but not necessarily required, that the key be unique. You might use a subtable to store information about a user based on their source address:

 

 

table set -subtable FOO [IP::client_addr] "data"

 

 

A somewhat useless example, admittedly, but the above creates a table entry in the subtable "FOO" with a key of the client source address and a value of "data". To use that information later:

 

 

table lookup -subtable FOO [IP::client_addr]

 

 

You then have table commands to add, replace, increment, append, and delete entries. Tables are also global, so you can set a value in one VIP/iRule and retrieve it in another. It gets really interesting when you start thinking of the session table as a way of storing arbitrary application information about a user. So for example, let's say a user has been issued a unique session token (cookie). You can then store any arbitrary information in a subtable based on that cookie. The value column can contain ANYTHING, including lists and arrays, so some have used subtables to store lists of data (credential data, application cookies that you don't want the user to have or pass across the Internet, last request time, number of requests, etc.). Very powerful stuff.

 

 

As for exporting the session table contents, that is definitely possible, but generally not the intention.