Replace HTTP status response in returned URI.

Iain,

My iRule-foo isn't bad but I wouldn't class myself as an expert. Here's my thoughts.

Create a datagroup as follows:

5xx_codes {
"500" := "/error_500.html", 
"501" := "/error_501.html"
}

And then an irule like this:

when HTTP_RESPONSE {
 if {[HTTP::status] eq 5*} {
 set redirect [class match -value [HTTP::status] equals 5xx_codes]
  HTTP::redirect "http://serveraddress.com/$redirect"
 }
}

This will replace the URI with the relevant one from the datagroup.

Not tested I'm afraid and only a quick, first attempt. Some better iRules than me might be able to improve/correct or even dismiss this attempt 😉

N

This is actually a pretty reasonable approach Nathan. You'd necessarily want a pre-crafted HTML page for each possible 50x status message, so listing them in a data group is a good idea. Minor typo though:

when HTTP_RESPONSE {
    if { [HTTP::status] starts_with 5 } {
        if { [class match [HTTP::status] equals 5xx_codes] } {
            set redirect [class match -value [HTTP::status] equals 5xx_codes]
            HTTP::redirect "http://serveraddress.com${redirect}"
        } else {
             no crafted HTML for this error message - better to just drop then
            reject
        }
    }
}

Nothing major, but the data group would have returned, for example, "/error_500.html", which would have made the redirect URL look like this (notice the double forward slash):

http://serveraddress.com//error_500.html

You could also save yourself the potential hassle of a second server to host these error messages by hosting them locally on the BIG-IP and using iFiles to retrieve them.

Thank you everyone for you help.

It looks like this solution will do exactly the job I was looking for!

There's a question internally over if the "reject" is required on the end for this solution. People don't like the word reject, its a very powerful word.

Regards

Well, you can use reject, drop, or discard. You can redirect to another site with HTTP::redirect or HTTP::respond, or use the latter to send arbitrary HTML content. Or you could simply allow the server's response through to the client. I suspect you're doing all of this to address the security vulnerabilities of verbose server error messages, so depending on what's causing the errors, a reject (simply resetting the connection) is the right choice.