I was talking to a customer the other day, and was asked about hosting a “simple” error page within the NetScaler that would inform the users that there was a back end problem.

I told the customer about the NetScaler Responder and Rewrite capabilities. And, because they wanted to trigger the custom page based upon a back end (server generated) condition, Rewrite was probably the best way to go.

This is really an old trick, but since I was asked about it, I thought that I would post a blog about it.

While redirecting to a maintenance server that could issue user-friendly pages was an option, a generic page – with the html code embedded within the NetScaler configuration – was preferred in this case.

Here’s how we did it.

Be warned: Judging by the html code we created, you will see why I am an architect, and not a web designer .

This is the page code that generated the page we wanted the user to see.

Now I know that anyone can make the page look better by dressing up the code, but let’s examine how we implemented this.

What It Should Do…

In the NetScaler Rewrite section of the configuration, we added an “Action” object. This basically, is the object that holds the above code.

I called this Action entity – for lack of imagination – “UserFriendly”. Although this can be done using the NetScaler command line, I chose the easy way out by using the NetScaler Management GUI.

Of note is that we specified “REPLACE_HTTP_RES” from the drop down list. This causes the Rewrite routines to insert this response, and discard the server’s response.

Also note that we included two NetScaler based variables. “http.REQ.HOSTNAME” and “http.REQ.URL” in the page’s code. Including these in the response text will cause the page to echo the page that the user was trying to access originally.

We thought that this could be useful in problem determination dialogs with the helpdesk.

When It Should Do It…

Next, we created a policy to “invoke” the Action Object.

We chose to do this on a particularly troublesome application, so we set the Policy object accordingly.

In our example, we want the NetScaler to respond with the user friendly error page any time any of the back-end servers respond with a 400-series status code.

To achieve this, we simply specified http.RES.STATUS.BETWEEN(400,410) in the expression of this Policy object.

And Activate it…

And lastly, we bound the Rewrite Response policy to a Load-Balancing VServer.

This activates the Policy that checks the server response status code, which, if matched, invokes its associated Action that pushes out the NetScaler configuration-embedded error page.

Now for the real test.

Testing 123…

I played dumb-user (easy for me to do!) and accessed a nonexistent page using my browser. I miskeyed (actually misspelled) my request as – do we all see that I should have learned to spell?
Anyway, this user-friendly page told me what had happened.

Sure, the page could use some dressing up, and we could even provide a contact point for the helpdesk(?!). But this example is only a starting point.

But Wait! There’s More!

Hmm… Maybe we will add a check for the contents of the request header “Accept-Language” to serve localized pages, for example.

http.RES.STATUS.BETWEEN(400,410) && HTTP.REQ.HEADER(“Accept-Language”).CONTAINS(“en”)

Might work, n’est-ce pas?

But we’ll leave that until next time after I’ve had time to test it out.

As usual, your comments are welcome.


Follow me at Twitter

Or send me email