Forum Discussion

wlopez's avatar
wlopez
Icon for Cirrocumulus rankCirrocumulus
Apr 02, 2018

iRule to replace content of the location header on HTTP Responses

I'm trying to create an iRule that will detect if a web server is sending it's private IP address in the location header on it's responses. The logic is to read the location header in the responses, detect if the private IP addresses of the servers are included on them and replace the content of the location header to the website's URL, leaving everything else intact. This is the initial code I came up with. Should this work? Any better suggestions?

 

when HTTP_RESPONSE {
if { ( [HTTP::header Location] contains "10.0.0.11" ) || ( [HTTP::header Location] contains "10.0.0.12" ) } {
    [HTTP::header Location] replace "www.mywebsite.com" }
    }
application delivery
http header
http response
iRules
LTM
replace http location header
  • JRahm's avatar
    JRahm
    Icon for Admin rankAdmin
    Feb 24, 2024

    nice, antonio503 . If you scale up to a lot of IPs and get in a long list of or statements, you can dump the IPs in a data-group and check the header value against your list. The lookup against hashed data in a data-group large data set is a way more efficient operation. But at two IPs, this is a perfect solution and needs no alteration; just adding context for you and others should scale be an issue.

  • antonio503's avatar
    antonio503
    Icon for Nimbostratus rankNimbostratus
    Feb 22, 2024

    I was having a similar issue. In my case we were doing external PCI scans and it was showing the internal IP of the pool servers. I ended up creating an iRule with the following to address this issue for us. After applying this iRule it now replaced the location information with the public name and not the internal IP addresses of the servers.   

    when HTTP_RESPONSE {
    if { ( [HTTP::header Location] contains "x.x.x.x" ) || ( [HTTP::header Location] contains "y.y.y.y" ) }{
        HTTP::header Location {https://www.mysite.org}
    }
}
  • crodriguez's avatar
    crodriguez
    Ret. Employee
    Apr 02, 2018

    One of the potential issues I see with your current "contains" approach is that there is the possibility of a match on IP addresses other than 10.0.0.11 and 10.0.0.12, such as 10.0.0.110, 10.0.0.120, 110.0.0.121, 210.0.0.119, etc. All of these "contain" one or the other of the strings you're comparing against. (The likelihood of these other IP addresses actually appearing is probably remote, so you may be just fine.) To completely avoid an unanticipated match, you can make the "contains" strings more specific - maybe incorporate slashes into your matching strings - "/10.0.0.11/" and "/10.0.0.12/" (or maybe even something like ";) - but you would want to make sure you understand how the application always formats the Location header when it responds with an IP address instead of a host name.