Forum Discussion
Nimbostratushowto set cookie and cookie persistence at the same time
My iRule assigns pools according to keywords in the URI. For one special URI and the corresponding pool I want to limit the http connections via table command and cookies. Works more or less in the lab but for the persistence...
How can I assign a cookie persistence in HTTP_REQUEST if I set the cookie only in the HTTP_RESPONSE? Here's the iRule:
static variables defined elsewhere
when HTTP_REQUEST {
if { ( [HTTP::uri] contains "" ) } {
set tableName "table_sessionLimit"
set cookieName "TEST_SessionCookie"
set needCookie 0
if {[HTTP::cookie exists $cookieName]} {
set clientID [HTTP::cookie $cookieName]
if { [table lookup -subtable $tableName $clientID] != "" } {
return
}
}
if { [table keys -subtable $tableName -count] < $static::TEST_max_http_connections} {
set needCookie 1
set clientID [format "%08d" [expr { int(100000000 * rand()) }]]
set clientSocket "[IP::client_addr]_[TCP::client_port]"
table add -subtable $tableName $clientID $clientSocket $static::TEST_sessionTimeout
pool pool-shop
} else {
HTTP::redirect ""
}
} elseif { ( [HTTP::uri] contains "" ) } {
pool pool-portal
} else {
HTTP::close
}
}
when HTTP_RESPONSE {
if {[info exists needCookie]} {
if {$needCookie == 1} {
HTTP::cookie insert name $cookieName value $clientID path "/"
}
}
}
3 Replies
dirkenOoops, the formatting hit me... of course, there are keywords in the URI check, and of course there is a redirect URL in the redirect statement...- Kevin_Stewart
Employee
You could use the persist command and insert a persistence entry based on the clientID value, but it may just be simpler to use a built-in cookie persistence profile.
- Kevin_Stewart
The persist cookie and cookie persistence profile provide the same functionality, but do so in a very different way. The cookie persistence profile generates a cookie to the client with a name (usually BIGipServer[something]) and a value that is the encoded pool, node, and port of the chosen pool member. This alleviates LTM from having to do any persistence tracking because the client is carrying the information. The persist cookie command (or any persist command for that matter) generates an internal persistence table entry. The index to that table is the value that the client returns on every request, which could be the cookie name, cookie value, whatever. The corresponding value is the pool/node/port of the chosen pool member. So for the persist command, only a single (consistent) value is required from the client. For the cookie persistence profile, LTM needs the cookie name and the cookie value.
And for what it's worth, you don't have to use persist cookie. You could also use persist uie. The difference is semantic.
In the response event, you'd do a persist add uie command, for example, and add a persistence table entry based on the clientID. Then in the request, if the clientID cookie exists, and the uie persistence table entry exists for that clientID, use the persist uie command to send the traffic to the correct pool member.
