You are currently browsing the tag archive for the ‘404’ tag.

As I discussed in a previous post, simply redirecting a user to a “friendly” 404 page isn’t the best option. First, the user might not remember what they clicked/typed to get them to the page and also, simply clicking the back button might not be an option, especially if they submitted form data. Fortunately, as F5 LTMs are “Strategic Points of Control,” we can use them to better handle the situation.

 

First off, let’s determine the desired behavior when a user request induced an error code. In our case, let’s choose 404 as the error code to watch for. If we detect this error code being sent to the user, let’s redirect them to our Home Page (www.sample.com) rather than simply keeping them at an error page. To make their experience better, let’s also hold the user at an custom page for a few seconds while explaining their issue as well as the request that caused the problem.

 

Since we’re looking for error codes sent by the servers, we’ll need to run our commands from within the “HTTP_RESPONSE” event. As you’ll see from the DevCentral wiki page for HTTP_RESPONSE, there are examples for using the “HTTP::status” command to detect error codes and redirect users. For some, the rule below is perfectly acceptable.

 

when HTTP_RESPONSE {

if { [HTTP::status] eq “404” } {

HTTP::redirect “http://www.sample.com” }

}

 

Unfortunately, that rule would result in the user being sent to the redirect page without any explanation as to what they did wrong. So, we’re going to beef the rule up a bit. As you’ll recall from this post, we can set variables from the HTTP_REQUEST event and then reference them from our HTTP_RESPONSE event in order to show the user the link that caused the error.

Here’s a nice sample rule I just whipped up. We’re using “HTTP::respond” so the response comes directly from LTM. Also, I’m setting a variable “delay” to the amount of seconds to keep the user at the hold page.

 

when HTTP_REQUEST {

set hostvar [HTTP::host]

set urivar [HTTP::uri]

set delay 4

}

when HTTP_RESPONSE {

if { [HTTP::status] eq “404 } {

HTTP::respond 200 content \ “<html><head><title>Custom Error Page</title></head><body><meta http-equiv=’REFRESH” content=$delay;url=http://www.sample.com/></head>\<p><h2>Unfortunately, your request for $hostvar$urivar casued a 404 error. After 4 seconds, you’ll automatically be redirected to our home page. If you feel you’ve tried a valid link, please contact webmaster@sample.com. Sorry for this inconvenience.</h2></p></body></html>” “Content-Type” “text/html”

}

}

 

So, with that rule, the user requests a page that causes a 404 error. LTM will detect the 404 error, and instead of sending it to the user, it will respond with a 200 status code and HTML showing the user the link the requested as well as apologizing and telling them to contact your webmaster if there’s an issue. I was too lazy to use the HTML to make the e-mail address clickable, maybe next time. Also, by using “Meta Refresh,” we’re holding the user at the page for 4 seconds and then sending them to our error page. As you can see, HTTP::respond is a very powerful command. It’s pretty cool being able to use LTM to send HTML to a user.

 

 

Advertisements

It’s a Fall/Winter Sunday which means I’m closely monitoring my Fantasy Football teams. I play on both Yahoo and ESPN but in this blog, we’ll concentrate on ESPN.

When clicking on an ESPN Message Board post to view player discussion, I found myself receiving a 404 error. For those unfamiliar, or unwilling to click the wiki link, a 404 response is when content cannot be found on a server. These responses should always be customized so the user gets more information than the default windows error.

Here’s ESPN’s version:

While this error is descriptive and helps the user understand the error, it’s not representative of the conditions. In this case, the content is available every few refreshes which likely means some replication issues on their end. Here’s what my address bar looks like after receiving the 404.

Since I’m an avid Wooter, I find myself hitting the refresh button as soon as I get a response I don’t like, especially when I know the content is there. As you can see from the address bar, my browser’s address bar is now at ESPN’s 404 page. So, if I hit refresh here, I’m simply going to reload their error page.

Let’s consider the problems this presents from a user’s perspective:

1. I want to access valid content.

2. The content is on some servers, but apparently not on others.

3. When I attempt to access it on a server on which it doesn’t exist, I am redirected to ESPN’s error page.

4. I now must hit the back button on my browser and then re-request the page. Hopefully, I didn’t open the page in a new window/tab and close the previous one.

In my opinion, ESPN should be able to anticipate the user behavior that would cause such an error. Obviously the server should send the error when I request illegitimate content, but we already know that it happens if content replication hasn’t occurred yet. In either case, sending me to a 404 page is valid, keeping me at one isn’t! I believe a more user-friendly reaction might be that the user receives the 404 but is then automatically redirected to the page from which he was referred.

Just my two cents.