Your error page can be better

Error pages. Most people don't really consider error pages when building a website or application. They usually contain some debug information so that when something goes wrong the developer knows what is wrong. But in a lot of cases when an application goes into production, this information is still exposed.

Today the Giro d'Italia is coming through our province (Utrecht). For this, a special website was set up which gives information on the route and all kinds of related topics. I wanted to check on the info, but instead of getting the main site, I got this:
 

Posted using Mobypicture.com

Now, with sites like this you never know what kind of loads you can get. There are solutions for that (cloud computing would apply well here) but that's not what I wanted to talk about. I wanted to talk about what I'm seeing in the above image...

Your average visitor will come to your site expecting information. If something goes wrong (which can always happen), they only need to know that something went wrong, and perhaps they should get a phone number or e-mailaddress where they can report the error. At the least, the visitor should be informed of the error in the design of the rest of the website, so that they are aware of the fact that this error is indeed generated by your website, and it's not a problem on their side for instance.

The thing is, most people won't know what MySQL is, or which database is giving an error here. For all they know, a database could be part of the browser, and MySQL could be some kind of code for the error.  It gets worse when with some applications full exception stack traces are outputted, sometimes including database credentials. Not only do you give the average visitor information they don't need, you also give malicious users a huge amount of information they can use to try and get into your application.

If you are working on a website or an application, you should output all that information in your development environment. But before moving to production, this should be switched to a simpler, more user-friendly error-page. Now frameworks such as Zend Framework and symfony have special settings for that using different environments, which makes it really easy for a developer to switch between the developer-view of an error-page and the user-friendly one. Perhaps more systems, including CMS-es, should pay more attention to this. But in the end, it is also the responsibility of the developer to keep this in mind. Next time, before you deploy a new version of your application, consider the error page, and think about what it should and should not expose to your average visitor.

Update: It's not just your application that you need to check, and so I found out the hard way right after publishing this article and running into some Nginx error 500 pages. I'm going to read up on Nginx configuration soon ;)


Add comment

Comments

gravatar zhaiduo: It's hard to handle critical error. That scratches me for a long time.
July 21, 2010

Php5_zce_logo

not tested in IE


Upcoming events

I will be speaking 08-10-2010: Symfony Day Cologne 2010
I will be speaking 09-10-2010: Symfony workshop

Tags

1337 2008 2010 4developers access modifiers accessibility AdaLovelaceDay09 advent agavi agile amsterdam apache apple article articles atk atkMetaNode audioscrobbler azure backwards compatibility barcelona bbc bbq beatstad belgium best practices bittorrent boards of canada book books bughuntday caching cake cal evans career cat cerf certificate cfp clear cms cologne common sense communities community conference conferences continuous integration contribute crisis css custom datetime DbFinderPlugin decorator decorators deployment devdays development directoryindex documentation download dpc dpc09 dpc10 DPC2008 dreamhost dv7 eclipse ed efficiency enterprise errors event events expertise ezcomponents facebook flickr framework frameworks freelance freeze frontend fun games germany getting real google googletalk graceful degradation hack hackers hidden gem hiphop howto hp html http ibuildings icann ide idm imovie indy ingewikkeld internet IPC ipc ipc08 javascript job jobeet john peel joomla kubuntu left on the web lighttpd lime linux live london loudblog m2ts mac malware mambo marjolein mediterra meeting meme meta methodology microsoft movie music mysql namespace namespaces netbeans netherlands nllgg odmarco open source opinion ORM osx paradiso pavilion pear performance personal pfc10 pfcongres pfcongrez photo php phpabstract phpazure phpBB phpbb phpbelgium phpbenelux phpbnl10 phpgg phpitalia phpnw phpnw08 phptek phptek09 phpuk2009 phpUnderControl phpunit php|architect php|tek podcast politics portability postcrossing presentation presentations private projects protected public qa recruiting refactoring review rewrite ruby on rails schedule scifi script security seven things sfdaycgn simplexml slides smfony software sogeti solar sound standard standards star trek static steer strings subversion symfony Symfony2 symfonycamp symfonyday symfonyUnderControlPlugin talk talks technology techportal tek09 telecommuting terratec terrorism testfest testing textpattern tips tld tomas training twig uncon unet usability usergroup validation vhost video vinyl virus warp weblogging wiki windows winphp women work workshop world world of warcraft wpi writing xml xpath xsd yara year youtube ZCE zemanta zend zend framework zend server zend studio Zend_Form
© 2004 - 2010 Stefan Koopmanschap + Powered by Symfony, photos powered by Flickr, links powered by Delicious, Shanghai smilies by Iconbuffet. Feeds: rss / atom. Left on the Web v4.4.0.1