Comments on: Handling Rails 404 and 500 errors http://brian.pontarelli.com/2007/01/14/handling-rails-404-and-500-errors/ Brian Pontarelli Thu, 20 Nov 2008 10:16:09 +0000 http://wordpress.org/?v=2.6 By: Matt http://brian.pontarelli.com/2007/01/14/handling-rails-404-and-500-errors/#comment-3531 Matt Mon, 16 Apr 2007 21:21:40 +0000 http://brian.pontarelli.com/2007/01/14/handling-rails-404-and-500-errors/#comment-3531 You could also do the following at the end of your routes.rb file. map.connect "*anything", :controller => "your_controller", :action => "your_action" This will catch all badly formed requests and send them to the designated controller and view. If you want to see what was passed, you can access them via params[:anything]. You may also need a separate layout for your controller depending on what you're doing. This will behave the same regardless of environment. I found this out coincidently by reading the routes section in AWD w/Rails 2ed. pg. 399 and then looking at the rails rdoc for ActionController::Routing, Route globbing. You could also do the following at the end of your routes.rb file.

map.connect “*anything”, :controller => “your_controller”, :action => “your_action”

This will catch all badly formed requests and send them to the designated controller and view. If you want to see what was passed, you can access them via params[:anything]. You may also need a separate layout for your controller depending on what you’re doing. This will behave the same regardless of environment.

I found this out coincidently by reading the routes section in AWD w/Rails 2ed. pg. 399 and then looking at the rails rdoc for ActionController::Routing, Route globbing.

]]> By: Ben http://brian.pontarelli.com/2007/01/14/handling-rails-404-and-500-errors/#comment-3487 Ben Wed, 11 Apr 2007 16:03:46 +0000 http://brian.pontarelli.com/2007/01/14/handling-rails-404-and-500-errors/#comment-3487 There is a better way to "tell rails to stop sucking" without changing local_request? or the consider_all_request_local. In addition to the rescue_action_in_public method there are 2 other rescue methods defined ... rescue_action & rescue_action_locally. The easier approach is to define: def rescue_action_locally(exception) rescue_action_in_public(exception) end so that your local and public exceptions fail the same way plus you only have to change that one call if you decide to go back to the other way where you get more diagnostic info on a local exception. Thanks for your post it got me looking in the right direction and now I am trapping my errors There is a better way to “tell rails to stop sucking” without changing local_request? or the consider_all_request_local.

In addition to the rescue_action_in_public method there are 2 other rescue methods defined … rescue_action & rescue_action_locally. The easier approach is to define:

def rescue_action_locally(exception)
rescue_action_in_public(exception)
end

so that your local and public exceptions fail the same way plus you only have to change that one call if you decide to go back to the other way where you get more diagnostic info on a local exception.

Thanks for your post it got me looking in the right direction and now I am trapping my errors

]]> By: Brian Pontarelli http://brian.pontarelli.com/2007/01/14/handling-rails-404-and-500-errors/#comment-3081 Brian Pontarelli Fri, 02 Feb 2007 17:00:43 +0000 http://brian.pontarelli.com/2007/01/14/handling-rails-404-and-500-errors/#comment-3081 The problem still remains that if you don't have a controller or view for the URL, then Rails freaks out. So, you need to conenct the catch everything URL just in case. I have a lot of requests, mostly folks doing bad links in Word Documents and Excel spreadsheets, that come in for crap like: /Document+C:\docs\blah/Open.aspx?foo=bar So, I wanted to handle these since I don't have a controller or view directory named Document. In order to pull this off you need a route that handles everything that doesn't exist. This was the tough part to figure out. Plus, the fact that Rails tries to be smart about localhost and remote hosts seems to be really lame. I want development to behave just like production, or at least as close as possible, so I can debug things properly. Not a big fan of getting things into production and crap happens that I didn't expect. Just personal preference I guess. The problem still remains that if you don’t have a controller or view for the URL, then Rails freaks out. So, you need to conenct the catch everything URL just in case. I have a lot of requests, mostly folks doing bad links in Word Documents and Excel spreadsheets, that come in for crap like:

/Document+C:\docs\blah/Open.aspx?foo=bar

So, I wanted to handle these since I don’t have a controller or view directory named Document. In order to pull this off you need a route that handles everything that doesn’t exist. This was the tough part to figure out.

Plus, the fact that Rails tries to be smart about localhost and remote hosts seems to be really lame. I want development to behave just like production, or at least as close as possible, so I can debug things properly. Not a big fan of getting things into production and crap happens that I didn’t expect. Just personal preference I guess.

]]> By: Doug Barth http://brian.pontarelli.com/2007/01/14/handling-rails-404-and-500-errors/#comment-3078 Doug Barth Fri, 02 Feb 2007 15:13:37 +0000 http://brian.pontarelli.com/2007/01/14/handling-rails-404-and-500-errors/#comment-3078 In Rails 1.1, the public/404.html page is rendered on a 404 error. In Rails 1.2, public/500.html is rendered on 500 errors. If you need to render dynamic content, you will need to override the rescue_action_in_public method to point it towards your templates. The local request check is there so that developers can receive debug information in a production environment by logging onto the prod box and hitting it directly. This distinction is only used when your app is started up in production mode. In development, all requests are considered local. I've found that the easiest way to test error pages is to fire up your application in production mode and it it from another computer. If you don't have another computer handy, overriding the local_request? method to always return false will allow you to see what external users do. In Rails 1.1, the public/404.html page is rendered on a 404 error. In Rails 1.2, public/500.html is rendered on 500 errors. If you need to render dynamic content, you will need to override the rescue_action_in_public method to point it towards your templates.

The local request check is there so that developers can receive debug information in a production environment by logging onto the prod box and hitting it directly. This distinction is only used when your app is started up in production mode. In development, all requests are considered local.

I’ve found that the easiest way to test error pages is to fire up your application in production mode and it it from another computer. If you don’t have another computer handy, overriding the local_request? method to always return false will allow you to see what external users do.

]]> By: Henrik N http://brian.pontarelli.com/2007/01/14/handling-rails-404-and-500-errors/#comment-3068 Henrik N Thu, 01 Feb 2007 09:10:53 +0000 http://brian.pontarelli.com/2007/01/14/handling-rails-404-and-500-errors/#comment-3068 Seems you categorized this post incorrectly ("Java", should be "Ruby/Rails"). Seems you categorized this post incorrectly (”Java”, should be “Ruby/Rails”).

]]> By: Brian Pontarelli http://brian.pontarelli.com/2007/01/14/handling-rails-404-and-500-errors/#comment-3034 Brian Pontarelli Wed, 17 Jan 2007 22:24:31 +0000 http://brian.pontarelli.com/2007/01/14/handling-rails-404-and-500-errors/#comment-3034 I've looked at lighthttpd and mongrel, but I haven't messed with it. FastCGI is okay for my needs and it is pretty simple to configure, so I haven't done that fully yet. There are a few things about it that suck, but for the most part it works fine. I don't like how it has to reload the entire rails app if it hasn't been hit in a while. That causes pauses sometimes. However, from what I've seen with SSL, lighthttpd and mongrel can be a bit of a configuration headache, but I could be wrong. In terms of tuning, it is mostly in the application code and then tuning the apache/fcgi connectors (timeouts mostly). Usually I haven't had to tune much and things work fine. What kind of tuning have you been doing? I’ve looked at lighthttpd and mongrel, but I haven’t messed with it. FastCGI is okay for my needs and it is pretty simple to configure, so I haven’t done that fully yet. There are a few things about it that suck, but for the most part it works fine. I don’t like how it has to reload the entire rails app if it hasn’t been hit in a while. That causes pauses sometimes.

However, from what I’ve seen with SSL, lighthttpd and mongrel can be a bit of a configuration headache, but I could be wrong.

In terms of tuning, it is mostly in the application code and then tuning the apache/fcgi connectors (timeouts mostly). Usually I haven’t had to tune much and things work fine.

What kind of tuning have you been doing?

]]> By: jeff judge http://brian.pontarelli.com/2007/01/14/handling-rails-404-and-500-errors/#comment-2987 jeff judge Tue, 16 Jan 2007 05:28:49 +0000 http://brian.pontarelli.com/2007/01/14/handling-rails-404-and-500-errors/#comment-2987 yo! have you had much experience with product deployments yet and stuff like lighthttpd or mongrel? just curious. i've deployed with apache/fastcgi...wanted to see your thoughts on tuning production servers. yo! have you had much experience with product deployments yet and stuff like lighthttpd or mongrel? just curious. i’ve deployed with apache/fastcgi…wanted to see your thoughts on tuning production servers.

]]>