Log Django 404s using a separate middleware that hooks in to process_response

[atbaker]

Howdy,

First - thanks for supporting and maintaining this library. Overall, Rollbar has worked out well for our Django site.

We're having trouble accurately reporting 404s, however. We're using Wagtail, a Django-based CMS. Wagtail has a redirects middleware which is almost identical to Django's contrib redirects middleware.

Both middlewares use process_response to catch responses with 404 error codes and check to see if a user-defined redirect is available for them.

If your view still throws a Http404 exception, however, Rollbar's middleware will see and report the exception before any other middleware's process_response method has an opportunity to redirect the response. This happens regardless of the middleware order.

Because of this, our Rollbar dashboard has a ton of 404 warnings reported, but only a minority of them are valid - many are caught by the redirect middleware.

I was looking for solutions. It looks like Sentry solves this problem by providing a separate middleware for logging 404s and putting it at the top of the middleware stack: https://docs.getsentry.com/hosted/clients/python/integrations/django/#logging

We're going to keep using Rollbar to log 404s, even though our 404 logging data is noisy. But it would be great if there was some way I could accurately report 404s from our Django app.

Thanks.

[ezarowny]

Hey @atbaker, we're actually looking at reworking our Django middleware a bit this week. I'll get back to you once we do that.

[ezarowny]

I'm going to file an internal ticket for us to add a 404-capture middleware (or add it to the existing middlware).

[jasonm]

@ezarowny Howdy! Is there anything we could do or contribute to help out?

@atbaker Did you end up writing any workarounds for this? Thanks for the reference to the Sentry approach.

[ezarowny]

@jasonm of course - we always welcome pull requests! You could make another Rollbar middleware solely to catch 404's.

It should also be possible to change the order in which Django middleware executes. However, I believe the execution order has slightly changed since 1.10.

[jasonm]

@ezarowny @atbaker Something along these lines? I'll give this a spin in our app.

https://gist.github.com/jasonm/29c34915c0100c13082d3ab9c9bec170

[ezarowny]

That's pretty good! I'd probably want to add a configurable blacklist or whitelist as well.

[jasonm]

FWIW what I found is that, similar to Sentry404CatchMiddleware I had to have the 404-catching middleware implement process_response and look for an HTTP response with status_code == 404 instead of implementing process_exception.

The process_exception approach in my above gist still causes the Http404 exception to be logged to Rollbar, presumably because the wagtailredirects middleware that intercepts the 404 and returns a response does so by handling process_response instead of process_exception, so the Django middleware's exception handling passes the exception all the way up to the gist's RollbarNotifierMiddlewareOnly404.

Here is a new gist with the classes I eventually used:
https://gist.github.com/jasonm/9de5ca4a5decac13ca812cef2f89e4fd

[jasonm]

FWIW this wagtailredirects module is very similar (largely duplicative) of a builtin Django contrib app named redirects so a separable 404 processing middleware would be useful to more than just wagtail users.

[rivkahstandig3636]

Hi there, I’m closing out all issues opened before 2018 that haven’t had any activity on them since the start of this year. If this is still an issue for you, please comment here and we can reopen this. Thanks!

[dprothero]

This is still an issue. Were you not planning on addressing it?

[jessewgibbs]

@dprothero we recently closed out a lot of our older issues, but since it's still affecting you, we've reopened it and added it to our backlog.