The default server_error view uses Context instead of RequestContext. If you were depending on a context processor to make MEDIA_URL available in your templates, your 500.html template will not render with the correct image paths. This handler adds MEDIA_URL (and nothing else) back to the context that is sent to the template.
This script is an adaptation from http://www.djangosnippets.org/snippets/678/ . Here, it doesnt use the cache middleware but relies on sessions. The script set a session cookie to identify the upload and track it to make it available for a progress bar like this one : http://www.djangosnippets.org/snippets/679/ . Note the progress bar cannot work with development server as it is single-threaded. Tested with apache/mod_python and mod_wsgi. any comments appreciated ;)
For PyCon we have our crash messages go to a mailman group so that people working on the site would be aware of issues. This saved us many times. But sensitive information would some times come up such as login passwords and fields we did not want going on the list. the solution was to mask these POST fields when an exception occurs and is being handled. This is simple drop-in code which will mask the values of POST arguments which contain keywords (such as 'password', 'protected', and 'private').
The default 500 handler does not take into consideration if the HTTP request made is an XMLHttpRequest. If it's an XHR, then it may not be a good idea to send back your default 500 HTML page. To use this custom 500 handler, just add the following to your urls.py: handler500 = 'my_project.my_app.views.my_500'
4 snippets posted so far.