Django Nginx连接重置，来自uWsgi的响应丢失

我有一个通过Nginx和uWsgi托管的django应用程序。在一个非常简单的请求中，我得到了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"

本质上，如果我使用POST，Nginx某处会丢失响应，而如果我使用GET则不会

---

有人知道这件事吗？

在进一步研究中幸运地发现了这一点http://answerpot.com/showthread.php?577619-有几个%20个bug/Page2我发现了一些有用的东西

---

提供uwsgi通过请求身体关闭；Nginx conf中的参数解决了这个问题…

我遇到了同样的问题，但在我的情况下，我不能禁用uwsgi\u pass\u request\u body，因为大多数时候，但我的应用程序并不总是需要POST数据

这是我找到的解决方法，而这个问题在uwsgi中没有解决：

传递-后缓冲1到uwsgi

这将自动缓冲所有大于1字节的http正文

---

nginx管理上游断开连接的方式提出了这个问题

我也面临同样的问题。我尝试了上面所有的解决方案，但都不起作用。在我的例子中，忽略响应体根本不是一个选项

显然，这是一个错误与

解决这个问题的方法是将-PEP33333输入添加到uwsgi的参数列表中。之后，所有帖子都被正确返回

我正在使用的nginx/uwsgi版本：

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

$ uwsgi --version
uWSGI 0.9.7

---

如果你的应用程序确实需要POST数据，这就不起作用了，对吗？是的，这不会将POST数据传递给uwsgi。相反，应该打开后缓冲。在我使用Flask项目的情况下，这实际上也对我有效。基本上，你需要在回复之前阅读帖子。@VictorFarazdagi你是如何在烧瓶里做到这一点的？以下是我刚才如何绕过这个讨厌的问题：回复。data@roberto奥巴马的答案是正确的。否则，大文章将存储在内存中，而不会缓冲到磁盘。谢谢您的回答。只是将-pep3333输入添加到uwsgi并没有修复它。我还必须添加此处引用的-post缓冲4096：根据Roberto的说法，-pep3333输入现在已经过时，在更新版本的uwsgi上没有任何作用。我移除了旗帜，一切仍然正常运行。也许您正面临着其他一些您设法解决的问题-post缓冲？如果问题中的问题与我遇到的问题相同，那么问题是如果您的python代码从未在django中读取post数据，这将是访问您视图中某个地方的request.post，那么事情就会搞砸。如果您告诉UWSGI使用-POST buffering 1参数缓冲POST数据，正如roberto所说，那么无论您在视图中做什么，您的POST请求都不会出错。另请参见FWIW，@roberto是UWSGI的作者。这确实是正确的答案。这是uwsgi的一个选项，您可能希望将其与-limit post结合使用。我有一个类似的问题，只是它与帖子无关。尝试过后缓冲和@ehabkost的ForcePostHandler，但没有运气。这让我快发疯了，请帮帮我！！！不要介意！通过向uwsgi添加缓冲区大小=8192，我能够解决这个问题。天哪，真的很难弄明白……但这不是一个很大的性能问题吗？uWSGI的文档称，这将保存所有大于指定限制的HTTP正文。将每个POST请求的正文保存到磁盘可能是一个问题。

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

$ uwsgi --version
uWSGI 0.9.7