Мое простое приложение Django отлично работало в режиме отладки (manage.py runserver
) и работает под WSGI + Apache на моем устройстве для разработчиков, но когда я перешел на EC2, я начал получать периодические (10-80% времени) ошибки Bad Request (400)
для любых URL-адресов, которые я попробуйте просмотреть (будь то в моем приложении или в админке Django.
Где я могу найти отладочную информацию по этому поводу? Ничего не появляется в /var/log/apache2/error.log
, даже с LogLevel=info
. Я проверил версии, зарегистрировал среду запроса (см. Советы по отладке ModWSGI) и не вижу серьезных различия.
Единственная оставшаяся у меня мысль: я использую mod_wsgi из Ubuntu 12.04 (libapache2-mod-wsgi 3.3-4build1), который был построен против Python 2.7.1; У меня Python 2.7.3. А Django - это 1.6, что новее, чем версия Ubuntu Precise. Я не решаюсь начинать сборку пакетов из исходного кода, так как это так сложно очистить, и это похоже на незначительные изменения версии ...
Спасибо за вашу помощь.
(Для справки, вот конфигурация Apache и приложения WSGI)
Конфигурация Apache (000-по умолчанию)
<VirtualHost *:80>
ServerAdmin webmaster@localhost
DocumentRoot /var/www
WSGIScriptAlias /rz /usr/local/share/rz/rz.wsgi
...
Приложение rz.WSGI
import os
import sys
import django.core.handlers.wsgi
import pprint
path = '/usr/local/share/rz'
if path not in sys.path:
sys.path.insert(0, path)
os.environ['DJANGO_SETTINGS_MODULE'] = 'rz.settings'
class LoggingMiddleware:
def __init__(self, application):
self.__application = application
def __call__(self, environ, start_response):
errors = environ['wsgi.errors']
pprint.pprint(('REQUEST', environ), stream=errors)
def _start_response(status, headers, *args):
pprint.pprint(('RESPONSE', status, headers), stream=errors)
return start_response(status, headers, *args)
return self.__application(environ, _start_response)
application = LoggingMiddleware(django.core.handlers.wsgi.WSGIHandler())
sudo apt-get update
иsudo apt-get upgrade
на рабочем виртуальном сервере, а затем получил 400 ПЛОХОЙ ЗАПРОС. Это привело меня к этому сообщению, и решением было добавить ALLOWED_HOSTS. Я предполагаю, что это связано с тем, что обновление было изменено на Django 1.5 или выше. Обратите внимание на Важно < / b> комментарий здесь: по умолчанию Django 1.3.6 и 1.4.4 установили ALLOWED_HOSTS, чтобы разрешить все хосты. Это означает, что для фактического устранения уязвимости системы безопасности вам следует определить этот параметр самостоятельно сразу после обновления. - person HostileFork says dont trust SE   schedule 24.11.2016