django中断管错误的可疑解决方案

Question

在我的 django 应用程序中，在极少数情况下，我会在 Ajax 例程中调用 location.reload();。这适用于 Chrome，但使用 Firefox4 我在我的开发服务器（Django 1.2.5，Python 2.7）上得到了两次error: [Errno 32] Broken pipe，这需要大约 10 秒。
并且该错误似乎吞噬了我尝试使用 django 消息框架显示的消息。

不，我将这一行替换为

var uri = location.href;
location.href = uri;

现在重新加载仍然需要大约 10 秒，但 Firefox 会显示该消息。

到目前为止，它有效。但对我来说，这看起来像一个肮脏的黑客。所以我的问题是：

1. 谁能首先解释（或猜测）错误是什么？
2. 您是否发现这种“解决方案”将来会影响我的任何问题？

（注意：我不是第一个toexperiencethatproblem）。

Answer 1

首先，这是某些特定浏览器的问题（并且可能是服务器端的长时间处理）在 django 中不是问题。

来自 django 上的bug report：

这是一种常见错误，当您的浏览器关闭连接而开发服务器仍在忙于发送数据时，就会发生这种错误。我们能做的最好的事情就是提供更明确的错误信息。

它实际上可能发生在其他系统上，例如来自cherrypy

没有什么好担心的，因为这只是意味着客户端在服务器之前关闭了连接。在此回溯之后，您的 CherryPy 服务器仍将继续正常运行。

所以这是对您的第一个问题的介绍：

1. 谁能首先解释（或猜测）错误是什么？

嗯，这只是浏览器关闭连接 - 一种客户端超时。 这个Django + WebKit = Broken pipe 的答案确实回答了这个问题。

为什么改变location.href而不使用location.reload()会起作用？好吧，我猜，但这只是一个猜测，Firefox 的行为略有不同，重新加载的超时也会不同。

我认为消息已被消费，因为当浏览器扣动触发器并关闭连接时，请求已经在发送。

开发服务器是单线程的，这也可能是问题的一个因素。

我通常在真正的（本地）服务器上进行开发（nginx+apache+mod_wsgi，没什么特别的）——以避免遇到在生产中永远不会发生的愚蠢问题。

1. 您是否发现这种“解决方案”将来会影响我的任何问题？

好吧，它可能不适用于在重新加载之前检查href 是否已更改的浏览器。或者它可能会命中缓存而不是执行真正的请求（您可以使用 reload() 强制避免缓存）。并且行为可能在所有浏览器上都不一致。 但同样，您已经遇到了浏览器的怪癖，所以我不会太担心它本身。

顺便说一句，你可以这样做：

location.href = location.href

我宁愿担心处理需要 10 秒！那真的不应该发生。 edit 所以看起来是浏览器本身引发了较长的处理时间和损坏的管道错误。对我来说，这听起来像是单线程 django 服务器上的（坏）并行请求。 结束

在真实的网络服务器上测试，优化你的代码；如果这还不够用 celery+rabbitmq 在后台进程中启动长任务；在任何情况下都不要在一个不是真正问题的问题上浪费时间！

您可能可以使用location.reload() 并稍作调整，或者可能只是一个真正的测试环境！

Answer 2

损坏的管道错误也可能归结为 Django 调试服务器中缺乏对某些功能的支持 - 一个值得注意的问题是 Django 缺乏对常用的 Range HTTP requests 的支持（详见此处：Byte Ranges in Django）在传送 [流式传输] 媒体内容时。

可能值得使用 Wireshark 等数据包捕获程序调查实际的 HTTP 交换，以便您了解问题发生的时间和地点。