Learn F5 Technologies, Get Answers & Share Community Solutions Join DevCentral

Filter by:
  • Solution
  • Technology
Clear all filters
Answers

iRule - Fallback Persistence

Hi - I'm trying to create an iRule for the Persistence Profile of one of my applications. The preferred method is to use cookie - the application actually injects a cookie in the HTTP RESPONSE and the F5 looks for this cookie in both the HTTP RESPONSE and HTTP REQUEST to do persistence, identical to how JSESSIONID works.

However in the event that the client has configured their browser to reject / disable cookies, the expectation is that we persist based on their source IP, however as they come in to our data centre via Akamai, we actually need to extract their IP from the X-Forwarded-For header.

What I came up for this was:

when HTTP_REQUEST {
    if { [HTTP::cookie exists "App_SessionId"] } {
        persist uie [HTTP::cookie "App_SessionId"] 1800
    }
    else if {[HTTP::header X-Forwarded-For] != ""} {
        persist uie [lindex [ split [lindex [HTTP::header values X-Forwarded-For] 0] "," ] 0] 1800
    }
    else {
        persist uie [IP::client_addr] 1800
    }
}

when HTTP_RESPONSE {
    if { [HTTP::cookie exists "App_SessionId"] } {
        persist add uie [HTTP::cookie "App_SessionId"] 1800
    }
}

I haven't had the chance to test this but reviewing the logic I see that we may have a problem with the first request cominf from the user's browser.

When a user first lands on the website, the HTTP_REQUEST from their browser will not have the App_SessionId cookie and this causes the LTM to add a persistence record based on the X-Forwarded-For header, or add a persistence record based on the user's source IP address.

When the request makes it to the server and the server responds (HTTP_RESPONSE), that response will have a App_SessionId cookie, and the LTM adds another persistence record based on this cookie.

Then the subsequent HTTP_REQUEST from the users browser will have the App_SessionId cookie, and this will now match the if { [HTTP::cookie exists "App_SessionId"] } section of the iRule and they will be persisted to the same server that inserted the cookie.

This is good but there's the loose end which is the initial persistence record based on the X-Forwarded-For header that's lingering.

  1. Would this lingering persistence record based on the X-Forwarded-For header cause a conflict with the persistence record based on the App_SessionId cookie?
  2. How do I clean up this loose end?

On the flip side, if the user had configured their browser to reject cookies, the persistence record based on the X-Forwarded-For header is vital to maintain session consistency. But now we have the loose end of the persist add uie [HTTP::cookie "App_SessionId"] 3600 in the HTTP_RESPONSE.

0
Rate this Question

Answers to this Question