在我的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会显示该消息。
到目前为止，它有效。但对我来说，这看起来像一个肮脏的黑客。所以我的问题是：
（注意：我不是第一个to experience that problem）。
答案 0 :(得分：3)
首先，这是一些特定浏览器的问题（可能是服务器端的长处理），这不是django中的问题。
来自django上的bug report：
这是常见错误，只要您的浏览器在开发服务器仍在忙于发送数据时关闭连接时就会发生这种错误。我们最好的办法是提供更明确的错误信息。
实际上它可能发生在其他系统上，例如来自cherrypy
没有什么可担心的，因为这只意味着客户端在服务器之前关闭了连接。在此追溯之后，您的CherryPy服务器仍将继续正常运行。
这是对你的第一个问题的介绍：
嗯，这只是浏览器关闭连接 - 一种客户端超时。 这个Django + WebKit = Broken pipe答案确实回答了这个问题。
为什么更改location.href而不使用location.reload()会有效？嗯，我猜，但这只是一个猜测，Firefox的行为略有不同，重新加载将以不同的方式超时。
我认为消息已被消耗，因为当浏览器触发触发器并关闭连接时，请求已经被发送。
开发服务器是单线程的，这也可能是问题的一个因素。
我通常在真实（本地）服务器上进行开发（nginx + apache + mod_wsgi，没什么特别的） - 避免遇到生产中永远不会发生的愚蠢问题。
嗯，它可能不适用于在重新加载之前检查href是否已更改的浏览器。或者它可能会触及缓存而不是执行实际请求（您可以使用reload（）强制避免缓存）。并且所有浏览器的行为可能不一致。
但同样，你已经打了一个浏览器怪癖，所以我不会太担心它本身。
顺便说一下，你可以这样做：
location.href = location.href
我宁愿担心处理需要10秒！这真的不应该发生。 编辑所以它看起来像是浏览器本身引发了长处理时间和管道错误。听起来像单线程django服务器上的（坏）并行请求给我。的 EndEdit中
在真实的网络服务器上测试，优化您的代码;如果这还不够，那就用celery + rabbitmq在后台进程上启动长任务;在任何情况下都不要在一个不是真正问题的问题上浪费时间！
您可能能够使用location.reload()并进行一些调整，或者只是一个真正的测试环境！
答案 1 :(得分：0)
破坏的管道错误也可能导致Django调试服务器缺少对某些功能的支持 - 一个值得注意的问题是Django缺乏对Range HTTP requests的支持（详见此处：Byte Ranges in Django）这是在传送[流媒体]媒体内容时常用的。
使用Wireshark等数据包捕获程序调查实际的HTTP交换可能是值得的，这样您就可以看到问题出现的地点和时间。