iRule to redirect request to another node if HTTP response is 404

Hi Narenda,

You could call HTTP::retry from HTTP_RESPONSE if the status is a 404. I'm not sure about clearing the persistence record though. I wonder if you could call persist none if $retries > 0 and then call persist again with the persistence method you're using.

Here's a rough example to start with:

when CLIENT_ACCEPTED { 
   set retries 0
}
when HTTP_REQUEST {
    Don't retry requests with a payload as we don't
    want to have to collect every payload to retry 404 responses
   switch [HTTP::method] {
      "GET" -
      "HEAD" {
         set request_headers [HTTP::request]
      }
      default {
         set request_headers ""
      }
   }
}
when HTTP_RESPONSE {
   if {$request_headers ne "" && $retries < [active_members [LB::server pool]]}{
      switch [HTTP::status] {
         404 {
            incr retries
            HTTP::retry $request_headers
         }
      }
   }
}

Aaron

Hi Aaron Thanks for the giving the approach.

 

 

When i use HTTP::retry in HTTP_RESPONSE should it be triggering LB_SELECTED event? where i can choose which member of the pool or a different pool could be selected by LB::reselect for serving the request.

 

 

Thanks.

I'd be wary of using a 404 as a sign of an unhealthy pool member. A client could easily DOS a web app by making requests for known non-existent pages in the app. Search engines could easily do this inadvertently.

 

 

Aaron

I'd agree wtih Aaron here. A 404 is not a sign of a server that's unhealthy, it's a sign of a user making requests for pages that don't exist, more often than not. ;)

 

 

500 errors perhaps could indicate health, but 404? Likely not.

 

 

Colin

Thanks Michael/Aaron/Colin for your kind suggestions.

 

 

I have created a iRule like below to redirect the requests to different pool if a node sends http 404. Persistence is enabled at request, if http 404 comes it can break the persistence (i think it will work without that also) and redirect to another pool.

 

 

when CLIENT_ACCEPTED {

 

set retries 0

 

}

 

 

when HTTP_REQUEST {

 

persist source_addr

 

set request_headers [HTTP::request]

 

}

 

 

when LB_SELECTED {

 

if { $retries > 0 } {

 

persist none

 

LB::reselect pool Sample_Pool_1

 

}

 

}

 

 

when HTTP_RESPONSE {

 

if { $request_headers ne "" && $retries < [active_members [LB::server pool]] } {

 

switch [HTTP::status] {

 

404 {

 

incr retries

 

HTTP::retry $request_headers

 

}

 

}

 

}

 

}

I agree with Hoolio and Colin.

 

 

A 404 is not a good indicator of server health, but given the scenario redirecting the user to another server could be almost as problematic.

 

 

In the edge cases where a 404 would be a sign of server health I would recommend a Health Monitor over an iRule.

Hi Michael actually we are on testing phase so we are testing with http errors right now (Our application is not yet ready). Going on production we will be using some header value inserted into http response so that we will be able to decide to which node or pool it should go. It will not be an http error. But your point is duly taken into consideration here.

Oh that makes more sense. A 404 is an easy way to test. ;)

 

 

Colin

Yeah that's why! :))

Looks pretty good. Basically you want to retry once and then find a new server? Is that working for you?

 

 

Colin