Nginx réinitialisation de la connexion, la réponse de uWsgi perdu

J'ai un django application hébergée via Nginx et uWsgi. Dans un certain très simple demande, je reçois des comportements différents pour les GET et POST, qui ne devrait pas être le cas.

La uWsgi le journal du démon:

[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)

La Nginx accesslog:

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"

La Nginx errorlog:

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"

En essence, Nginx perd quelque part la réponse, si j'utilise la POSTE, pas donc, si j'utilise l'OBTENIR.

Quelqu'un sait quelque chose à ce sujet?

Voir aussi stackoverflow.com/questions/7273725/...

InformationsquelleAutor Ulf | 2010-10-19

25

Passer --post-buffering 1 à uwsgi

Cela va automatiquement tampon toutes les http body > 1 octet

Le problème est soulevé par la voie de nginx gère en amont des problèmes de déconnexions
- -1: Ajout d'une option pour quoi? nginx? uwsgi?
- C'est un UWSGI option, et ça fonctionne pour moi aussi.
- FWIW, @roberto est l'auteur de uwsgi.
- C'est vraiment la bonne réponse. C'est une option à uwsgi et vous voulez probablement pour l'utiliser conjointement avec --limit-post. projets.unbit.il/uwsgi/wiki/Doc
- Je vais avoir un problème similaire (cela n'a rien à voir avec les Messages). Essayé, le post-mise en mémoire tampon et aussi @ehabkost de ForcePostHandler, mais pas de chance. C'est me rend fou, s'il vous plaît aider!!! stackoverflow.com/questions/18667370/...
- Jamais l'esprit! J'ai été en mesure de résoudre le problème en ajoutant buffer-size = 8192 à uwsgi. Garçon, était-ce dur à comprendre...
- Ce ne serait pas un gros problème de performances, si? uWSGI le doc dit que cela permettra d'économiser tous les corps HTTP plus grand que la limite spécifiée. Sauver le corps de disque pour chaque requête POST pourrait être un problème.
InformationsquelleAutor roberto
5

J'ai frappé le même problème, mais sur mon cas, je ne peux pas désactiver "uwsgi_pass_request_body" comme la plupart du temps (mais pas toujours) mon application ne doivent les données POST.

C'est la solution de contournement que j'ai trouvé, alors que ce problème n'est pas résolu dans 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()
```
- En fait, cela a fonctionné pour moi aussi (dans mon cas avec Flacon de projet). Fondamentalement, vous avez besoin de lire le POST avant de répondre.
- comment avez-vous fait dans le Flacon?
- Voici comment, comme je viens de le faire pour contourner ce désagréable problème: la réponse.données
- réponse est la bonne. Sinon, les grands Postes seront stockées dans la mémoire, et pas de tampon sur le disque.
InformationsquelleAutor ehabkost
5

Je suis confronté aux mêmes problèmes. J'ai essayé toutes les solutions ci-dessus, mais ils n'ont pas de travail. Ignorant le corps de la réponse dans mon cas est tout simplement pas une option.

Apparemment c'est un bug avec nginx et uwsgi lorsque vous traitez avec les requêtes POST dont la réponse est plus petit que 4052 octets

Ce que résolu pour moi a été d'ajouter "--pep3333 d'entrée" à la liste des paramètres de uwsgi. Après que tous les Postes sont retournés correctement.

Versions de nginx/uwsgi je suis en utilisant:
```
$ nginx -V
nginx: nginx version: nginx/0.9.6

$ uwsgi --version
uWSGI 0.9.7
```
- Merci pour la réponse. Juste en ajoutant "--pep3333-entrée" pour uwsgi n'ont pas le fixer. J'ai aussi dû ajouter "--post-mise en mémoire tampon 4096" comme indiqué ici: comments.gmane.org/gmane.comp.python.wsgi.uwsgi.general/812
- Selon Roberto, le --pep3333-input est maintenant obsolète et ne pas faire n'importe quoi sur les nouvelles versions de uwsgi. J'ai enlevé le drapeau et les choses sont encore en cours d'exécution correctement. Vous êtes peut-être confronté à un autre problème que vous avez réussi à résoudre avec --post-buffering?
- Si le problème en question est le même que le problème que j'ai eu, le problème était que si votre code python ne lit jamais les données POST (dans django, ce serait accédant à la demande.POST quelque part dans votre point de vue), puis les choses se faire défoncer jusqu'. Si vous dites à UWSGI de la mémoire tampon les données POST avec l' --post-tampon 1 paramètre comme roberto dit, alors vos requêtes POST ne sera pas d'erreur, peu importe ce que vous faites dans votre vue.
InformationsquelleAutor lullis
1

Après un de la chance de trouver dans d'autres recherches (http://answerpot.com/showthread.php?577619-Several%20Bugs/Page2) j'ai trouvé quelque chose qui a aidé...

La fourniture de la uwsgi_pass_request_body off; paramètre dans la conf Nginx résout ce problème...
- Cela ne fonctionne pas si votre application a besoin réellement les données POST, non?
- Ouais, ce ne sera pas passé le poste de données à uwsgi. Au lieu de post-mise en mémoire tampon doit être activé.
InformationsquelleAutor Ulf

Vous devez vous connecter pour publier un commentaire.