在我的django應用程序中，在極少數情況下，我在Ajax例程中調用location.reload();。這適用於Chrome，但使用Firefox4，我在開發服務器（Django 1.2.5，Python 2.7）上獲得了兩次error: [Errno 32] Broken pipe，這大約需要10秒。
而錯誤似乎吃了我試圖使用django消息框架顯示的消息。django中的破損管道錯誤的可疑解決方案
沒有我換成這符合
var uri = location.href;
location.href = uri;
現在重裝仍需要一些10秒，但Firefox顯示消息。
到目前爲止，它的工作原理。但對我來說，這看起來像一個骯髒的黑客。所以我的問題是：
（注：我不是第一toexperiencethatproblem）。
首先，這是一些特定的瀏覽器（並可能在服務器端進行長時間處理）的問題，而不是django中的問題。
從bug report上的Django：
這是發生時，您的瀏覽器關閉連接，同時開發服務器仍忙於發送數據的常見錯誤。我們可以做的最好的是有一個更明確的錯誤信息。
它實際上可以在其他系統，例如發生從cherrypy
沒有什麼可擔心的，因爲這只是意味着客戶端關閉服務器之前的連接。在此追蹤之後，您的CherryPy服務器仍將繼續正常運行。
所以這是介紹你的第一個問題：
那麼，它只是瀏覽器關閉連接 - 類型的客戶端超時。 這個Django + WebKit = Broken pipe答案確實回答了這個問題。
爲什麼它通過更改location.href而不是使用location.reload()？那麼我會猜測，但這只是一個猜測，Firefox的行爲稍有不同，重載會有不同的超時。
我認爲消息被消耗，因爲當瀏覽器拉動觸發器並關閉連接時，請求已被髮送。
開發服務器是單線程的，這也可能是問題的一個因素。我通常在真正的（本地）服務器（nginx + apache + mod_wsgi，沒什麼特別的）上做我的開發 - 這樣可以避免陷入生產中永遠不會發生的愚蠢問題。
那麼，它可能無法在瀏覽器上檢查是否href已重新加載之前已更改。或者它可能撞到緩存而不是做一個真正的請求（你可以用reload（）強制避免緩存）。所有瀏覽器上的行爲可能都不一致。 但是，你已經碰到了瀏覽器的怪癖，所以我不會擔心它本身太多。
順便說一句，你可以簡單地做：
location.href = location.href
我寧願擔心處理需要10秒！這真的不應該發生。 編輯所以它看起來就像是瀏覽器本身引發了很長的處理時間和破損的管道錯誤。聽起來像單線程django服務器上的（壞）並行請求給我。 endsit
測試一個真正的網絡服務器，優化你的代碼;如果這還不夠，用celery + rabbitmq啓動後臺進程的長時間任務;無論如何，不要在一個並非真正問題的問題上浪費時間！
你或許可以和location.reload()住在一起，稍微調整一下，或者只是一個真正的測試環境！
破裂的水管中的錯誤，也可以到缺乏在Django的調試服務器的特定功能的支持 - 一個值得注意的問題是，Django的爲Range HTTP requests缺乏支持（在這裏看到的細節：Byte Ranges in Django）交付時，通常使用的[流媒體]媒體內容。
使用Wireshark等數據包捕獲程序可能值得研究實際的HTTP交換，以便您可以查看問題發生的位置和時間。
你在使用django-sentry嗎？如果是這樣，你有什麼設置你的本地配置？ – Tom 2011-05-12 16:07:49