Spammed with 'Invalid HTTP_HOST header' messages

396 views
Skip to first unread message

Jon Dufresne

unread,
Dec 5, 2013, 2:21:33 PM12/5/13
to django...@googlegroups.com
I am running Django 1.6.

I receive a lot of false positive errors from my Django application
when accessed with an invalid HTTP_HOST. I have verified that these
are in fact HTTP_HOST values that I am not interested in. So I *do*
want to return an error to the user. However, it doesn't help me as an
admin to receive an email every time this happens.

What is the most straight forward way to prevent these errors from
emailing the admins? I want to continue to receive other errors.

Thanks,
Jon

Zach Borboa

unread,
Dec 6, 2013, 10:47:06 AM12/6/13
to django...@googlegroups.com
SuspiciousOperation should now return a 400 error [1]. You could also use something like Sentry [2] or filter these messages.

Jon Dufresne

unread,
Dec 6, 2013, 11:28:37 AM12/6/13
to django...@googlegroups.com
On Fri, Dec 6, 2013 at 7:47 AM, Zach Borboa <zachb...@gmail.com> wrote:
> SuspiciousOperation should now return a 400 error [1].

It is true, the response is a 400 Bad Request error, but I still
receive emails going to my admins/managers email account. I thought
400 errors shouldn't be mailed out. I would prefer to avoid installing
Sentry if there is a simple fix. Any ideas?

Bill Freeman

unread,
Dec 6, 2013, 2:23:09 PM12/6/13
to django-users
Simple is in the eye of the beholder.  Unless someone we haven't heard from comes up with pre-existing switches or sub filtering attachment points, I see two possibilities.

1. Patch or monkey patch the code that decides to send the e-mail to check for this case to omit the e-mail.  This has to be checked whenever Django gets updated, but only adds work when an error is being returned.
2. At the WSGI application level, add code (essentially a middleware in the the WSGI meaning of the word) to check whether the request *would* cause this problem, return the 400 yourself, and skip calling down into Django.  The WSGI interface is stable, and should be proof against future upgrades, but this affects the performance of every request.

I'd go with 1, unless the site doesn't require best performance.



--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users...@googlegroups.com.
To post to this group, send email to django...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CADhq2b7C7X2%2Bx%3DOUkaECzBMftNBoxM%3D_h%2BhHJbPmZ%3DfV3X%2B3kA%40mail.gmail.com.

Zach Borboa

unread,
Dec 6, 2013, 2:46:56 PM12/6/13
to django...@googlegroups.com
Can you not add a filter to your logger handler? http://stackoverflow.com/a/19534738

Jon Dufresne

unread,
Dec 6, 2013, 2:55:04 PM12/6/13
to django...@googlegroups.com
> Can you not add a filter to your logger handler? http://stackoverflow.com/a/19534738

I will give this a shot.

But what I don't understand is that the post claims that this is fixed
in newer versions. I am using version 1.6. By "fixed" does he simply
mean 500 error is now a 400 error? Or is he implying this should not
be emailed anymore? I assumed the latter which makes me think
something is wrong with my configuration, but I could easily be wrong.

Zac Audette

unread,
Feb 26, 2014, 9:14:10 AM2/26/14
to django...@googlegroups.com, jon.du...@gmail.com
I am running 1.6 and this also emails me the errors. I was
also assuming by fixed they meant that this is no longer
an issue but that does not seem to be the case.
Reply all
Reply to author
Forward
0 new messages