We now take care of this globally in  & . : https://github.com/freerange/business/wiki/Setting-up-a-new-Linode-instance#set-default-locale : https://github.com/freerange/business/wiki/Setting-up-a-new-Linode-instance#set-lang-env-var-for-apache-based-on-default-locale
This is a copy of the content from the original wiki page , however I've had to tweak the formatting slightly to deal with our crazy CSS. In particular our styles don't work well for *nested* bullet points. : https://github.com/freerange/business/wiki/Checking-our-Annual-Accounts
This commit replaces the `Rack::MailExceptions` middleware with `Airbrake::Rack` for the reporting of exceptions. We're already using Airbrake to report exceptions from our `video` and `webhooks` apps to our instance of Errbit running on Heroku. So it makes sense to bring this app into line. Errbit makes it easier to manage exceptions when they occur e.g. commenting on them and marking them as resolved. Errbit notifies us by email of any exceptions, so none of the original behaviour is lost.
We were seeing exceptions like the one below in production which were resulting in 500 Internal Server Error responses which the `Rack::MailExceptions` correctly emails us about: A ArgumentError occured: invalid %-encoding (<%MYTEST) =================================================================== Request Body: =================================================================== <%MYTEST=REquEst("autoshell"):EvaL(MYTEST)%> I was able to reproduce the problem using a command like this on my local development environment: curl -v -XPUT --data "<%MYTEST=REquEst("autoshell"):EvaL(MYTEST)%>" "http://localhost:9292/" Upgrading Rack to v1.6.0 means that this type of request now raises a more specific exception: `Rack::Utils::InvalidParameterError`. Rails handles  this more specific exception and responds with a "400 Bad Request" response. I've attempted to reproduce similar behaviour using some custom Rack middleware loosely based on the `rack-robustness` middleware gem . I've inserted this middleware just in front of the `Rack::MailExceptions` middleware so that the app responds with a "400 Bad Request" response instead of emailing us with about a "500 Internal Server Error". @chrisroos: I'm not sure this is the best solution and it does feel as if we're reinventing the wheel a bit. It makes me wonder again whether we'd be better off with a Rails app! But this solution does mean that we won't continually be bothered with emails about such exception emails. : rails/rails@75eaefc : https://github.com/blambeau/rack-robustness