ERR_INCOMPLETE_CHUNKED_ENCODING 未读取请求正文时
ERR_INCOMPLETE_CHUNKED_ENCODING when the request body is not read
以下是我对一个有趣的错误的讨伐,尽管我已经解决了这个错误,但我还是不明白。我找到了一个 解决方案 ,但我真的希望有人能提供一些关于错误真正原因的见解。
问题背景
这个问题首先出现在我们 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.")
该请求是将对象标记为关闭 的简单请求。我们在网站的很多地方都使用了这种模式,所以这个问题显然需要引起注意。
解决方案
我们的第一个线索是请求确实关闭了对象。也就是说,必须到达if contract.submit()
行。这将问题缩小到响应。我做了一些阅读,这个错误的原因有很多种。我们尝试过:
- 在 Django 中显式设置内容长度
- 一些迫使 nginx 更可靠地判断内容长度的 hack
- 用几种不同的方式重写代码
没有任何效果,本地仍然没有出现问题。所以我们决定在本地复制整个堆栈并进行测试。一次一个,我们删除了网络层的元素,并确定删除 nginx 并直接与 uWSGI 对话解决了这个问题。
所以现在我们确信问题出在nginx上,但仍然没有解决办法。好吧,在 Google 的第三页深处的某个地方,我遇到了一个 Whosebug post,它在某处有一个简短的评论,提到 阅读请求正文 有某种对 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,但请求正文中没有信息,因此正文被忽略
- 我发现一条关于 Whosebug 问题的评论提到 读取 POST 请求的主体对 nginx 的请求缓冲区有某种影响
- 简单地将请求主体分配给一个变量(从而读取缓冲区)解决了这个问题
毕竟,我只是想知道为什么会发生这种情况。不读取可能导致此错误的请求正文是什么意思?为什么只有nginx?为什么只有 Safari?
希望 Whosebug 社区能帮我解释一下!解决起来很有趣。我也做了一个简短的 presentation 与一些同事分享。
您没有指定 nginx 的版本。如果几个月没更新,可能是这个已关闭的issue:
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.
我的猜测是创建引用使缓冲区在设置 ack 来回切换后保持打开状态。
尝试升级nginx,因为这个补丁被合并了。如果您升级后仍然有问题,这是一个回归,我会开一张新的 nginx 票。
以下是我对一个有趣的错误的讨伐,尽管我已经解决了这个错误,但我还是不明白。我找到了一个 解决方案 ,但我真的希望有人能提供一些关于错误真正原因的见解。
问题背景
这个问题首先出现在我们 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.")
该请求是将对象标记为关闭 的简单请求。我们在网站的很多地方都使用了这种模式,所以这个问题显然需要引起注意。
解决方案
我们的第一个线索是请求确实关闭了对象。也就是说,必须到达if contract.submit()
行。这将问题缩小到响应。我做了一些阅读,这个错误的原因有很多种。我们尝试过:
- 在 Django 中显式设置内容长度
- 一些迫使 nginx 更可靠地判断内容长度的 hack
- 用几种不同的方式重写代码
没有任何效果,本地仍然没有出现问题。所以我们决定在本地复制整个堆栈并进行测试。一次一个,我们删除了网络层的元素,并确定删除 nginx 并直接与 uWSGI 对话解决了这个问题。
所以现在我们确信问题出在nginx上,但仍然没有解决办法。好吧,在 Google 的第三页深处的某个地方,我遇到了一个 Whosebug post,它在某处有一个简短的评论,提到 阅读请求正文 有某种对 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,但请求正文中没有信息,因此正文被忽略
- 我发现一条关于 Whosebug 问题的评论提到 读取 POST 请求的主体对 nginx 的请求缓冲区有某种影响
- 简单地将请求主体分配给一个变量(从而读取缓冲区)解决了这个问题
毕竟,我只是想知道为什么会发生这种情况。不读取可能导致此错误的请求正文是什么意思?为什么只有nginx?为什么只有 Safari?
希望 Whosebug 社区能帮我解释一下!解决起来很有趣。我也做了一个简短的 presentation 与一些同事分享。
您没有指定 nginx 的版本。如果几个月没更新,可能是这个已关闭的issue:
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.
我的猜测是创建引用使缓冲区在设置 ack 来回切换后保持打开状态。
尝试升级nginx,因为这个补丁被合并了。如果您升级后仍然有问题,这是一个回归,我会开一张新的 nginx 票。