HTTP Redirect When Pool is down

is LB::server pool usable?

LB::server

e.g.

when HTTP_REQUEST { 
  if { [active_members [LB::server pool]] < 1 } {
    HTTP::redirect "http://frdcsd.app.medcity.net/vdi/"
  }
}

Thanks. I was reading the "pool" as where I was to put the name not just a generic default pool reference.

thats nice. Till today, I did it on the same way like Joe.

Additional question:

If I put this in a seperate irule and respond with a HTTP::respond instead of an HTTP::redirect, do I need to add a priority tag to the HTTP_request and and an event deisable behind?

i.e.:

• one global irule for availability check

  when HTTP_REQUEST priority 999 {
      if { [active_members [LB::server pool]] < 1 } {  
          HTTP::respond 503 "Server is down"
  
          event disable all
          return
      }  
  }  
  

• custom irule for VS

  when HTTP_REQUEST {do some stuff}
  

If I put this in a seperate irule and respond with a HTTP::respond instead of an HTTP::redirect, do I need to add a priority tag to the HTTP_request and and an event disable behind?

i would do to ensure there is no conflict (e.g. multiple redirects). please be noted that event will be disabled throughout the connection or until event is re-enabled.

If I put this in a seperate irule and respond with a HTTP::respond instead of an HTTP::redirect, do I need to add a priority tag to the HTTP_request and and an event disable behind?

i would do to ensure there is no conflict (e.g. multiple redirects). please be noted that event will be disabled throughout the connection or until event is re-enabled.

Wouldn't it be simpler to make use of LB_FAILED for this?

when LB_FAILED {
        HTTP::respond 503 content "server is down"
        return
}

it looks simpler, but it isn't 1. it is triggered after http_request, but I want to check the pool before I do all the irule stuff

The advantages of using LB_FAILED are that;

• it catches when the pool is down (no active members) and also when the pool has not been marked down, but the pool member chosen is unresponsive, so it's actually more powerful than just checking [active_members [LB::server pool]]
• it's slightly more efficient as it saves potentially unnecessary checking in HTTP_REQUEST and you wouldn't need to worry about event disabling in HTTP_REQUEST (assuming you do not implement LB_FAILED in your other iRules) - this may not be a concern but worth noting

There may be other situation-specific reasons for wanting to execute the check in HTTP_REQUEST but if not LB_FAILED works well too as a generic rule for catching errors.

Beware of this, though:

sol9456: Using the HTTP::respond iRule command in the LB_FAILED event may result in truncated responses

Long-standing issue that does not seem to have been resolved.

If doing a 302 redirect to a sorry page though as the original asker wanted, this would not be a problem.

Having said that.....I think you've just directed me to a solution I needed!! I have seen this behaviour when trying to return large pages with embedded content to the client and was meaning to raise a case (but now don't need to).