smithvoice.com
 Y'herd thisun? 

“You can export from and to any data format... once you know the middleware trick.”

from this classic page by smith

MONO/Ubuntu part 11 - Handling Apache and Mono Errors

TaggedASP.Net, MONO, Linux

Raise your hand if you've ever proudly created a killer ASP.Net site and not given a thought to what a user sees if they type a URL without a managed file extension. I've done it and a few minutes of hitting sites on the net shows that I'm not alone :-(.

As with MS ASP.Net on IIS, Mono ASP.Net on Apache puts the work on you to cover at least the major server errors twice, not just in the web.config but also in the web server.

An interesting thing is that if you've done more ASP.Net typing than IIS management you may find that doing the work in Apache's files is more comfortable than clicking around IIS.

Before you begin: Get around the old IE "helpfulness"

Internet Explorer, starting with IE5, has an odd default where custom error pages from sites would be ignored if those page sizes weren't what Microsoft considered to be big enough. So if you made a short & sweet custom error page the user could instead get a blue generic page from the browser and the user perception would be that you suck.

Different server errors have different file size requirements. If you want to see what those are on your machine call up the Registry Editor via Start>Run and typing "regedit" in the command box (no quotes when you type it). Click your way down the treeview to "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\MAIN\ErrorThresholds" and you'll see the error codes IE handles and the threshold bytesizes for site response files in Hex and parenthetically in decimal notation.

Users could turn this feature off by going into Tools>Internet Options>Advanced, scrolling down the list of options and unchecking "Show friendly HTTP error messages". Users could, but they never do.

A weird thing about IE8 is that all of those registry values are still there and the option is still turned on by default but I've noticed that if a smallish custom error page is returned IE8 will usually display it. Maybe the logic is now smarter than just file sizes, dunno. However, since it will take a while for IE8 to replace older versions it's still the best idea to beef up your error pages to get around the problem.

To save space in the examples below we're not showing it fully, but we'd suggest in your pages that you add some hidden text to the body of your html. Over the years I've made it rote to add 20 or so copies of this line and it seems to have been enough to make IE stop being so 'helpful.'

<!-- This is padding to force Internet Explorer to show this website's custom error pages -->

General steps

We'll use the biggie FileNotFound 404 error for example, the steps are the same for all errors.

1) While coding/testing your site, create a separate page for each specific error. While building your site you don't want these pages to be fancy or have any code that might itself cause errors; Just plain, short HTML that tells *you* what error number got you to the page.

2) Cover the unmanaged error handling by adding ErrorDocument lines to the virtual host file.

3) Cover the managed error handling by switching on customErrors and adding error nodes to the customErrors node in the web.config

4) Before release, consider making site management easier and users less confused by reducing the error pages to just one or two that nicely say "try again" without a lot of detail. Logs are for details, users don't care.

Step 1, create the test error pages

Use nano to create an unmanaged and managed version of a 404 error page in your site root folder. (You don't have to have two files for every error, we're only doing this to fully test our error management.) Keep the files very short and simple.

sudo nano err404.html

 

<html>
<body>
<p>this is the err404.html page</p>
 
<!-- This is padding to force Internet Explorer to show this website's custom error pages  -->
...
<!-- This is padding to force Internet Explorer to show this website's custom error pages  -->
 
</body>
</html>

And the managed...

sudo nano err404.aspx
<html>
<body>
<p>this is the err404.ASPX page</p>
 
<!-- This is padding to force Internet Explorer to show this website's custom error pages  -->
...
<!-- This is padding to force Internet Explorer to show this website's custom error pages  -->
 
</body>
</html>

 

Step 2, redirect unmanaged errors

Open the site virtual host file...

sudo nano /etc/apache2/sites-available/asdf

Add a line to redirect 404s to the unmanaged page:

Note the prepended slash, this makes it so even errors in subfolders will use the error page located in the site's root folder.

Goose the Apache service with a reload or restart so it picks up the changes then give it a test.

Notice that while the browser is showing the text from the error file, the browser address bar, tab and window bar are all still showing the bad url that the user typed. This information can be helpful to the user. If instead you want to have a full redirection so all those areas show the url of the error page, just put a full url

Managed error handling

If you've done ASP.Net on IIS, this is exactly what you're used to.

When a request comes in for a file type that Apache hands off to Mono, errors also are passed to Mono's court.

Back in session 10 we created the web.config and turned off all custom errors, open the file again now to fix that.

sudo nano /home/kilgore/sites/asdf/web.config

Change the customErrors mode to "RemoteOnly", and add a sub node for the 404 error code.

<?xml version="1.0"?>
<configuration>
<system.web>
<compilation debug="true">
</compilation>
<customErrors mode="RemoteOnly">
<error statusCode="404" redirect="/err404.aspx" />
</customErrors>
</system.web>
</configuration>

You can set the customErrors value to "On" but with RemoteOnly your user browsers will show the custom pages and logging into the server and calling up the page with the Lynx browser will show the raw details.

No need to reload Apache, just like ASP.Net on IIS Mono's filewatcher takes care of making the latest web.config settings available to all new connections. A quick test shows the .Net result of the error page with the page the user typed in the address bar as a query string argument.

Step 4, cleanup for release

When you're all done testing (that's a joke, get it?) you'll obviously replace your simple ugly error pages with ones that match the look and feel of your site.

At the same time, you might want to thin the herd a bit, leaving just an unmanaged or just a managed version instead of both. You'll also likely want to do some grouping so that similar but different errors give a single message, such as 404 FileNotFound and 403 Forbidden are different to the back end but to the user the bottom line is the same (the Url they requested ain't gonna be shown). Just edit the lines for both errors in the virtual host and web.config files and have them route to the same error page.

The managed error system has a nice feature that it appears Apache doesn't yet offer. You can route all errors that are not excplicitly handled to a single page using the defaultRedirect attribute:

<customErrors mode="RemoteOnly" defaultRedirect="/defpage.aspx">

As far as my yahooing has shown, Apache requires each and every error code to be explicitly handled in the virtual host (or .htaccess) file. Drag.

Just an FYI: No Mono-Magic, 500s are still mostly untrappable

500 is a service error and if ASP.Net is the service that is hosed then your error routing is probably also hosed. So putting a error node in the web.config for 500s usually won't get you out of a code jam, especially if you have 500s redirecting to a managed errorpage file. Further, 500s out of ASP.net won't bubble up to ErrorDocument settings in Apache. The original request that caused the error was for a managed resource and at that point Apache was out of the picture.

Yeah, it's been the same deal with good ol' MS.Net for years but Mono being a different implementation under the covers it's a good idea to give your sites maybe a little more go-over before release than you'd do with .Net. (I 500-ed on this site for weeks for certain users, didn't hit it myself and the code appeared ok - at first. Looking deeper it was a mybad simple error but one that .Net/IIS would let us get away with and the stricter Mono wouldn't. Stuff happens. Every error adds up to better code the next time.)

 


 

Coming next: Subdomains and the default domain trap.


jump to:

  • 1: Why?
  • 2: Installation
  • 3: Update the OS with APT
  • 4: Remoting to the box with SSH
  • 5: NANO quickies for 95% of the jobs
  • 6: Firewalling Ubuntu 8.10 Server
  • 7: Installing Apache2 and MONO
  • 8: Test client host files
  • 9: Configure MONO on Apache2
  • 10: Apache default pages
  • 11: Handling Apache and Mono Errors
  • 12: Subdomains and Christian porn
  • 13: Virtual Host Tweak: unmanaged cAse sensitiviTy
  • 14: Managed cAse sensitiviTy
  • 15: Managing files and folders
  • 16: Logging Apache Accesses and Errors
  • 17: Ubuntu Task Managers
  • 18: Ubuntu Services and Service Managers
  • 19: Installing Oracle 10g XE Server
  • 20: Connecting Mono to Oracle


  • home     who is smith    contact smith     rss feed π
    Since 1997 a place for my stuff, and it if helps you too then all the better smithvoice.com