Using Rewrite to Redirect on 500 errors

Added by DeeLayna Hurst , last edited by Vishal Ganeriwala on Nov 09, 2007  (view change)
Tags: 

The Rewrite feature of the NetScaler can be used to automatically retry a web site when the backend server responds to a request with a 500 error.

Summary

In this example the rewrite feature will take 500 and replace them with a 302 (to the original URL) and redirect the connection up to 5 times, in hopes that the connection gets directed to a functioning web server on the backend.

Code Snippet

add rewrite action retry_request replace_http_res "\"HTTP/1.1 302 Temporary Redirect\\r\\nLocation:
http://\"+http.req.hostname.http_url_safe+http.req.url.path_and_query.http_url_safe+\"\\r\\nSet-Cookie:
retry=\"+http.req.cookie.value(\"retry\").typecast_num_t(DECIMAL).add(1)+\"\\r\\n\\r\\n<html>Temporary Error, retry</html>\""

add rewrite policy is_500 "http.res.status.eq(500) && http.req.cookie.value(\"retry\").typecast_num_t(decimal).le(5)" retry_request
bind rewrite global is_500 10 END -type RES_DEFAULT

More Information

It will be very helpful if you can explain what each line of the above code accomplishes. 

Posted by Anonymous at Apr 23, 2008 13:13 | Reply To This

add rewrite action retry_request replace_http_res "\"HTTP/1.1 302 Temporary Redirect\\r
nLocation:
http://\"http.req.hostname.http_url_safe+http.req.url.path_and_query.http_url_safe\"\\r
nSet-Cookie:
retry=\"http.req.cookie.value(\"retry\").typecast_num_t(DECIMAL).add(1)\"\\r\\n\\r
n<html>Temporary Error, retry</html>\""

This defines a rewrite action that replaces something in an HTTP response.  The entire reponse is replaced, so the content of rewrite action needs to include all of the HTTP headers that were in the original response.  The replacement information in this case is a properly formatted HTTP status code 302 redirect, complete with the needed Location header, and a tiny HTML page for the HTTP response body.

add rewrite policy is_500 "http.res.status.eq(500) && http.req.cookie.value(\"retry\").typecast_num_t(decimal).le(5)" retry_request
bind rewrite global is_500 10 END -type RES_DEFAULT

This defines the policy that will execute the above-defined rewrite action.  In this case, the policy will evalute as TRUE for an HTTP response if the response has:

 1) HTTP status code 500
 2) The associated HTTP request had a cookie value that includes "retry" with a check for the string length

This rewrite policy is also defined to be part of the Response Default global binding, so it would be used for any Vserver.  This is assuming that the the Rewrite is available in the appliance license, and that the Rewrite feature has been enabled.

-- Anonymous Coward

Posted by Anonymous at Apr 28, 2008 12:57 | Reply To This

Anonymous Coward got something wrong.

The rewrite action is adding a cookie that has a number, first starting at 1.  The policy is checking that cookie to see if the cookie is less than or equal to 5.

This policy is forcing the client computer to retry the same URL that brought it to the Vserver in the first place. If the end user follows this redirect 5 times in a row because the HTTP error 500 keeps coming up in the response, then on the 6th try, the "retry" cookie will equal 6, and the redirect policy will evaluate to false.  The user will not redirect again as a result, which makes sense because its likely that no back-end server is working as expected (they are all giving status 500 errors).  Slick idea, this.

Posted by Anonymous at Apr 30, 2008 13:00 | Reply To This

Anonymous Coward got something wrong.

The rewrite action is adding a cookie that has a number, first starting at 1.  The policy is checking that cookie to see if the cookie is less than or equal to 5.

This policy is forcing the client computer to retry the same URL that brought it to the Vserver in the first place. If the end user follows this redirect 5 times in a row because the HTTP error 500 keeps coming up in the response, then on the 6th try, the "retry" cookie will equal 6, and the redirect policy will evaluate to false.  The user will not redirect again as a result, which makes sense because its likely that no back-end server is working as expected (they are all giving status 500 errors).  Slick idea, this.

Posted by Anonymous at Apr 30, 2008 13:02 | Reply To This