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

Filter by:
  • Solution
  • Technology
code share

XFF Universal Persistence iRule

Problem this snippet solves:

Simple iRule to read the XFF header on an incoming HTTP Request and use a Universal Persistence ID. Orginal iRule found to have an issue with multiple IP addresses in the XFF header for changed to only pass the first XFF IP.

I have updated the iRule line to account for systems where multiple 'X-Forwarded-For' headers have been added.

persist uie [lindex  [ split [HTTP::header X-Forwarded-For] "," ] 0]


persist uie [lindex [ split [lindex [HTTP::header values X-Forwarded-For] 0] "," ] 0]

thanks to the advice from Yann Desmarest. This could also be done with the 'getfield' command see Yann's comments below.

How to use this snippet:

Create iRule using following code (mine is named 'persist_xff_uie') Create Universal Persistence Profile with iRule set to 'persist_xff_uie' (or what ever name you assign to the iRule) Assign Universal Persistence Profile to Virtual Server (ensure virtual server has HTTP profile assigned)

Tested on Version:
Comments on this Snippet
Comment made 08-Dec-2015 by thomasedwin 20
This is great!
Comment made 21-Jun-2016 by Sumanta 236
Hi Amg Will this also need One Connect as mandatory? How is this different from the below code I am using? ********************************************************************* when HTTP_REQUEST { set xff [HTTP::header "x-forwarded-for"] persist uie [HTTP::header "x-forwarded-for"] log local0. "[IP::client_addr]:[TCP::client_port]: XFF: $xff" } *********************************************************************
Comment made 26-Jun-2016 by Andy McGrath 2133
Hi Sumanta, Issue found was when XFF header contained multiple IP addresses so my code splits up the header and only uses the first IP address, this should be the first XFF header applied. If this is not an issue for you, either you happy to use the full XFF header or only ever has a single address in the XFF header, then your code looks fine. Finally no you do not need to use with OneConnect for this to work but in my situation we were using OneConnect as was being applied to an application virtual server where the client was a server using multiplexing. Also one of the reasons we needed this as the full XFF headers changed depending on the which of the many servers sent the request so we needed to strip it back to a common identifier.
Comment made 25-Jul-2016 by Sumanta 236

Thanks a lot !

Comment made 25-Jul-2016 by Yann Desmarest 4479


I recommand you to change :

[lindex [ split [HTTP::header X-Forwarded-For] "," ] 0]


[getfield [lindex [HTTP::header values X-Forwarded-For] 0] "," 1]

If the request contains multiple X-Forwarded-For headers, your code just take the latest header value. Not the first one.

Comment made 25-Jul-2016 by Andy McGrath 2133

Yann, You are correct for most headers where multiple headers exist with the same name however the XFF header gets appended, i.e. Format is;

X-Forwarded-For: client, proxy1, proxy2

So there should only ever be a single X-Forwarded-For header within a HTTP request with the first IP address being closest to the original. I could do the following:

[getfield [HTTP::header X-Forwarded-For] "," 1]

However I test a lot of code directly in TCL so the getfield commend is not valid but this is just down to personal preference.

Comment made 27-Jul-2016 by Yann Desmarest 4479


I'm not 100% sure, but AFAIK, the RFC allow the request to contain more than one HTTP header with the same name. There is nothing specific to X-Forwarded-For header, so I assume the limitations are the same as other headers.

Moreover, in real life, I regularly face this kind of request containing several X-Forwarded-For headers. That's why I suggested to change the code to take into account this possibility.