I like the concept of public/500.html and public/404.html, but every time I work on APIs I get surprised that it is only for HTML and not any other MIME types. This is what I was thinking of doing.
Part 1) I have already created a middleware at my job that is like that functionality of ActionDispatch::PublicExceptions, but differs in that it will pick up the file using the following pattern: {Rails.public_path}/{Status}.{content_type.symbol}.{I18n.locale}. It also reads the files at load time and stores the contents in a cache to cut down on disk access. This would be the new PublicExceptions. Now developers could define public/500.xml.en and public/404.csv.fr if they so desire.
Part 2) rename public/{404,500}.html to public/{404,500}.html.en. This simplifies some logic and provides more clues to developers that they can localize the responses.
Part 3) Split PublicExceptions into a PublicExceptions and a DynamicExceptions middleware (this would be the to_{format} part) to again simplify logic. This will also allow developers to specify which they would rather have first or get rid of one or the other.
public/404.html is designed to be served directly by the web-server, not Rails. So adding dynamic code like i18n would be difficult.
There’s been a few discussions about basically making rails new or rails generate scaffold
, etc i18n by default. I would be interested to hear what other folks thought of that.
As a side-effect to internationalizing these generated views you would get the behavior you want “for free” and if the routes are satisfied by rails then you get the content-type → format too.
The files will still exist for the webserver to serve as needed. We could also have both 500.html and 500.html.en if that is necessary for the webserver.
As a side-effect to internationalizing these generated views you would get the behavior you want “for free” and if the routes are satisfied by rails then you get the content-type → format too.
I’m not so sure serving these files by the web server is a hard requirement. The intention to have static 500 error page was probably if the Rails server can’t fulfill the request you will not get a pretty page, if I had to guess.