django - 未读取请求正文时出现ERR_INCOMPLETE_CHUNKED_ENCODING

Question

以下是我对一个有趣错误的讨伐的记录，尽管我已经解决了该错误，但我不明白该错误。我找到了一个解决方案，但我真的希望有人能够提供一些有关该错误的实际原因的见解。

问题背景

此问题首先出现在我们的 Django 应用程序的生产服务器上。堆栈如下

• AngularJS
• nginx
• uWSGI
• Django
• PostgreSQL

我们的团队发现 Safari 上的单个 POST 请求存在问题。 Safari 会因响应而窒息并吐出 ERR_INCOMPLETE_CHUNKED_ENCODING。 post请求如下:

class ContractCloseOutSubmitView(APIView):
    def post(self, request, contract_id):
        contract = get_object_or_404(
            ContractCloseOut, pk=contract_id)
        if contract.submit():
            return Response({"detail": "Closed successfully."}, status=200)
        else:
            raise ParseError("Could not submit.")

该请求是将对象标记为已关闭的简单请求。我们在网站的很多地方都使用了这种模式，所以这个问题显然需要引起注意。

解决方案

我们的第一个线索是请求确实关闭了对象。也就是说，必须已到达 ifcontract.submit() 行。这将问题范围缩小到了响应。我读了一些资料，发现导致此错误的原因有很多种。我们尝试过:

• 在 Django 中显式设置内容长度
• 一些迫使 nginx 更可靠地判断内容长度的 hack
• 用几种不同的方式重写代码

没有任何效果，问题在本地仍然没有发生。因此我们决定在本地复制整个堆栈并进行测试。我们一次一个地删除了网络层的元素，并发现删除 nginx 并直接与 uWSGI 对话可以解决问题。

所以现在我们确信问题出在nginx上，但是仍然没有解决方案。好吧，在 Google 第三页的深处，我发现了一篇 StackOverflow 帖子，其中有一条简短的评论，提到读取请求正文对 nginx 的缓冲区以及它如何判断内容长度有某种影响(这是我不太熟悉的东西)。无论如何，显然解决此问题的方法是简单地读取缓冲区。也就是说，使用请求正文。因此，我尝试通过将其值分配给变量来简单地触摸请求正文:

class ContractCloseOutSubmitView(APIView):
    def post(self, request, contract_id):

        data = request.data #touchie touchie

        contract = get_object_or_404(
            ContractCloseOut, pk=contract_id)
        if contract.submit():
            return Response({"detail": "Closed successfuly."}, status=200)
        else:
            raise ParseError("Could not submit.")

tl;博士

• 收到对非常简单的调用的响应时遇到 ERR_INCOMPLETE_CHUNKED_ENCODING
• 问题仅发生在生产环境的 Safari 中
• 在调试时，我们一次删除了堆栈的一部分，并确定删除 nginx 可以解决问题
• 该请求是 POST，但请求正文中没有信息，因此正文被忽略
• 我发现一个 StackOverflow 问题的评论提到读取 POST 请求的正文会对 nginx 的请求缓冲区产生某种影响
• 只需将请求正文分配给变量(从而读取缓冲区)即可解决问题

毕竟，我只是想知道为什么会发生这种情况。不读取请求正文会导致此错误，这是什么原因？为什么只有 nginx？为什么只有 Safari？

我希望 StackOverflow 社区能帮我解释一下这个问题!解决这个问题很有趣。我还做了个短presentation与一些同事分享。

Answer 1

您没有指定 nginx 的版本。如果几个月没有更新，可能是这个已关闭的问题:

https://trac.nginx.org/nginx/ticket/959

Previously, the stream's window was kept zero in order to prevent a client from sending the request body before it was requested (see 887cca40ba6a for details). Until such initial window was acknowledged all requests with data were rejected (see 0aa07850922f for details). That approach revealed a number of problems: Some clients (notably MS IE/Edge, Safari, iOS applications) show an error or even crash if a stream is rejected; This requires at least one RTT for every request with body before the client receives window update and able to send data. To overcome these problems the new directive "http2_body_preread_size" is introduced. It sets the initial window and configures a special per stream preread buffer that is used to save all incoming data before the body is requested and processed.

我的猜测是创建引用在设置确认来回后保持该缓冲区打开。

尝试升级 nginx，因为此补丁已合并。如果您升级后仍然存在问题，那么这是一种回归，我会开一张新的 nginx 票证。