12 Point Design  

(209) 565-12PD
Email Us

12 Point Design/hosting/features/error_messages.asp  

Error Management System

The 12PointDesign Error Management System is a powerful url-analytical tool to help preserve the requests to your site. It provides an expandable array or common linking and addressing errors that can be treated and corrected using either pattern analysis or simple redirection, effectively fixing problems before they exist.

Error Management System

Making Sense of Error Messages

What's this sort of message about? Do I have a bad link or something?

Something like that. This particular one says that you don't have a file on your server named "favicon.ico" - which is the file requested for the icon when someone bookmarks any page on your site. I'll go through this with you though so you can see what happens for every bad request...

First, it was a *corrected* error on your site. This is noted by the square brackets around the "WWWError". If it was an *uncorrected* error (completely 404) then the subject tag and document heading would use exclamation points instead ("!WWWError!"). Most common minor errors are already fixed, but you receive an alert about them anyway (which can be disabled). The most important lines are prefixed with an @ in front of the square brackets that wrap the value.


This is the date/time that the error occurred:
  @[ 2005-07-30 13:42:00 ](Server Time)

Type of error (initially - 404 is a file cannot be found, 500 is a scripting error):
  @[ Err:404 ]

The actual requested file:
  @[ /favicon.ico ]

And it's "URL" style path:
  @[ http://www.example.com:80/favicon.ico ]

Who requested it. This information can sometimes be used to determine if it's just a virus trying to find email addresses or if it's a search engine that doesn't know where to look for a file. Lookup the IP address on either ARIN ( http://ws.arin.net/cgi-bin/whois.pl ) or DNSStuff ( http://www.dnsstuff.com/ )
  @[ ]

This is the "ID" of the record in the "te_errors" table that you can use to modify handling of the error. For example, if you wanted to turn off emails about this particular error you'd go to phpMyAdmin and login, select your database from the drop-down on the left side, click on the "grid" icon beside "te_errors", now on the left side, and page through the results (using the "[>]" button) until you find "141" in the "ID" column. Click 'edit' on the appropriate line, and finally, change the line that reads "mail" with a "1" in the box to a "0" (zero). And click "go" to save it. From then on it will still 'handle' the error, but will not email you that it has been handled.
  +[ ID : 141 ]

If it was a scripting error the following section would provide details:

The following lists all the "server variables" which include the cookie, browser type, IP address, security settings and other minutea that sometimes can be effective in diagnosing the error. The most important line is often the "User-Agent" as that tells you what browser - or SPIDER - was hitting your site. If it's "Yahoo Slurp" or "GoogleBot", for example, then it's very important that the error be fixed, if it is not already.

  • [ServerVariables]
  • ...
  • User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT
  • 5.1; SV1; .NET
  • CLR 1.1.4322; MSN 9.0;MSN 9.1; MSNbVZ02; MSNmen-us; MSNcOTH; MPLUS)

If there were 'non-session' cookies they would be listed here:

Likewise with form data:

And querystring stuff (the text that appears after the "?" in a URL):
  404;http://www.example.com:80/favicon.ico :

And more form-data - usually the bigger stuff:

And this is the play-by-play of what actually took place to diagnose the error and then do something about it:


  • RB("/admin$", "http://www.fbi.gov/"): Failure
  • KSRX("/favicon.ico","/printer$"): Failure
  • RB("/_vti_inf", "http://www.fbi.gov/"): Failure
  • RB("/_vti_bin/", "http://www.fbi.gov/"): Failure
  • RB("/af.cgi/", "http://www.fbi.gov/"): Failure
  • RB("/formmail", "http://www.fbi.gov/"): Failure
  • RB("/tellafriend", "http://www.fbi.gov/"): Failure
  • RB("/cgi-", "http://www.fbi.gov/"): Failure
  • FP(): Failure
  • KSRX("Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1;)","deepak-USC"): Failure
  • KSRX("Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1;)","Program Shareware 1\.0\.3"): Failure
  • KSRX("Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1;)","RPT-HTTPClient/"): Failure
  • KSRX("Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1;)","SlySearch"): Failure
  • KSRX("Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1;)","LeechGet"): Failure
  • KSRX("Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1;)","^Java\/[0-9\.]*$"): Failure
  • KSRX("","^12\.148\.209\.196$"): Failure
  • KSRX("","^12\.40\.85\."): Failure
  • KSRX("","^216\.200\.196\.((1[0-9])|([89]))$"): Failure
  • PFRX("/favicon.ico","^(.*)(javascript:[.\s\S]*)","$1"): Failure
  • PFRX("/favicon.ico","^(/search/cache\?[^/]*)(/[^&]*)&(.*)","$2 "): Failure
  • RB("/"">", "/"): Failure
  • LAR("/", ">click", "/", ""): Failure
  • LAR("/", "%a0", "/", ""): Failure
  • LAR("/", "%25a0", "/", ""): Failure
  • LAR("/", "%c2", "/", ""): Failure
  • LAR("/", "%25c2", "/", ""): Failure
  • LAR("/", "%20", "/", ""): Failure
  • LAR("/", "%2520", "/", ""): Failure
  • LAR("/", "&", "/", ""): Failure
  • LAR("/", ")", "/", ""): Failure
  • LAR("/", ",", "/", ""): Failure
  • LAR("/", ".", "/", ""): Failure
  • LAR("/", ">", "/", ""): Failure
  • LAR("/", "]", "/", ""): Failure
  • LAR("/%20", "", "/", ""): Failure
  • LAR("/", "favicon.ico", "/favicon.ico?", ""): Success
  • RedirectTo: http://example.com/favicon.ico?

The most important part in that mess is usually the last couple lines, where it says what method of testing was taken, whether it passed or failed, and what action was taken. In this particular event (a request for "/favicon.ico") it determined that the file "favicon.ico" was requested from the server (from any directory) and redirected the request to "http://example.com/favicon.ico?"

That effectively "fixed" it from being a 404, so your visitor received content they were probably expecting.

The "Management" of Errors

The rules themselves have a number of different types of tests which can be performed based on various input. These rules are summarized here.

"RB" - redirect branch:

If the text that is tested matches the first parameter, redirect to the URL in the second parameter. This is the ideal solution for when a directory changes names on the server.

"LAR" - Left and Right:

If the left side of the requested URL matches the first parameter, and the right side of the requested URL matches the second parameter, then replace the left part with the third parameter and the right part with the fourth. This is the most common correction for pages that are linked to incorrectly, with bad characters at the very end of them (like links with a closing parenthesis, period or comma: "www.example.com)" or "www.example.com." or "www.example.com,".

"FP" - Fix Parameters:

This is a general purpose fix for errant URL's from other sites or miscomposed links - often related to forgetting to encode the URL correctly in an anchor.

"KSRX" - Kill Something using Regular Expressions:

The first parameter is variable - which can be anything from the requesting IP address to the browser type to the file name, and the second parameter is the regular expression to test against. If the test is true then it simply kills the response, because the request is made by ether a scum spider, known email scalper address range or other malcontent wanting nothing more than to abuse your site.

"PFRX" - Pattern Fix using Regular Expressions:

This is the most powerful method. The first parameter is variable, like KSRX, the second is the Regular Expression to test against, the third is the replacement operator. Basically, it lets you do anything with anything to correct the errant URL. It's very powerful, but also requires a little more consideration. One mistake in the test expression or the replacement operation can really be a doosy, forwarding them to a URL that doesn't exist or parsing incorrectly, potentially causing an endless loop.

All of the native rules that are in there now are functional and have been tested and working for years. It's actually quite effective at eliminating spambots, while also correcting other more important stuff, like Yahoo or Google trying to get the wrong URL from your server because someone else linked incorrectly - and "thinking" that it's your fault, effectively degrading your sites perceived value.

Anyway... No, I don't expect you to jump in and make a billion changes to this thing right away, just to be aware that it's there and how it works. For this particular error a generic 12PD icon is returned. I recommend you find a picture you'd like to use for your icon and generate one out of it (I'd be happy to generate the icon for you). That way you 1) skip the error and 2) increase 'brand recognition' of your site with a more personal style.