Сброс соединения Nginx, ответ от uWsgi потерян - PullRequest
Новая
       9

Сброс соединения Nginx, ответ от uWsgi потерян

21 голосов
/ 19 октября 2010

У меня есть приложение django, размещенное через Nginx и uWsgi.В одном очень простом запросе я получаю различное поведение для GET и POST, чего не должно быть.

Журнал демона uWsgi: 

[pid: 32454|app: 0|req: 5/17] 127.0.0.1 () {36 vars in 636 bytes} [Tue Oct 19 11:18:36 2010] POST /buy/76d4f520ae82e1dfd35564aed64a885b/a_2/10/ => generated 80 bytes in 3 msecs (HTTP/1.0 440) 1 headers in 76 bytes (0 async switches on async core 0)
[pid: 32455|app: 0|req: 5/18] 127.0.0.1 () {32 vars in 521 bytes} [Tue Oct 19 11:18:50 2010] GET /buy/76d4f520ae82e1dfd35564aed64a885b/a_2/10/ => generated 80 bytes in 3 msecs (HTTP/1.0 440) 1 headers in 76 bytes (0 async switches on async core 0)

Журнал доступа Nginx: 

127.0.0.1 - - [19/Oct/2010:18:18:36 +0200] "POST /buy/76d4f520ae82e1dfd35564aed64a885b/a_2/10/ HTTP/1.0" 440 0 "-" "curl/7.19.5 (i486-pc-linux-gnu) libcurl/7.19.5 OpenSSL/0.9.8g zlib/1.2.3.3 libidn/1.15"
127.0.0.1 - - [19/Oct/2010:18:18:50 +0200] "GET /buy/76d4f520ae82e1dfd35564aed64a885b/a_2/10/ HTTP/1.0" 440 80 "-" "curl/7.19.5 (i486-pc-linux-gnu) libcurl/7.19.5 OpenSSL/0.9.8g zlib/1.2.3.3 libidn/1.15"

Журнал ошибок Nginx: 

2010/10/19 18:18:36 [error] 4615#0: *5 readv() failed (104: Connection reset by peer) while reading upstream, client: 127.0.0.1, server: localhost, request: "POST /buy/76d4f520ae82e1dfd35564aed64a885b/a_2/10/ HTTP/1.0", upstream: "uwsgi://unix:sock/uwsgi.sock:", host: "localhost:9201"

По сути, Nginx где-то теряет ответ, если я использую POST, а не так, если я использую GET.

Кто-нибудь знает что-нибудь об этом

Ответы [ 4 ]

25 голосов
/ 25 февраля 2011

Пропуск --post-buffering 1 в Уссги

Это автоматически буферизует все тело http> 1 байт

Проблема возникает из-за того, что nginx управляет отключениями в восходящем направлении

5 голосов
/ 12 июня 2011

У меня такие же проблемы. Я перепробовал все решения выше, но они не работали. Игнорирование тела ответа в моем случае просто не вариант.

Очевидно, это ошибка с nginx и uwsgi при работе с запросами POST, чей ответ меньше 4052 байтов

Для меня это решило добавление «--pep3333-input» в список параметров uwsgi. После этого все сообщения возвращаются правильно.

Версии nginx / uwsgi, которые я использую: 

$ nginx -V
nginx: nginx version: nginx/0.9.6

$ uwsgi --version
uWSGI 0.9.7
5 голосов
/ 18 февраля 2011

Я столкнулся с той же проблемой, но в моем случае я не могу отключить "uwsgi_pass_request_body", поскольку в большинстве случаев (но не всегда) моему приложению нужны данные POST.

Это обходной путь, который я нашел, хотя эта проблема не устранена в uwsgi: http://permalink.gmane.org/gmane.comp.python.wsgi.uwsgi.general/813

import django.core.handlers.wsgi
class ForcePostHandler(django.core.handlers.wsgi.WSGIHandler):
    """Workaround for: http://lists.unbit.it/pipermail/uwsgi/2011-February/001395.html
    """
    def get_response(self, request):
        request.POST # force reading of POST data
        return super(ForcePostHandler, self).get_response(request)

application = ForcePostHandler()
1 голос
/ 19 октября 2010

После удачной находки в дальнейших исследованиях (http://answerpot.com/showthread.php?577619-Several%20Bugs/Page2) Я нашел кое-что, что помогло ...

Использование параметра uwsgi_pass_request_body off; в Nginx conf решает эту проблему ...

...