djangoの壊れたパイプエラーの不快な解決策

Question

私のdjangoアプリでは、まれにAjaxルーチンでlocation.reload();を呼び出します。これはChromeでもうまくいきますが、Firefox4では開発サーバー（Django 1.2.5、Python 2.7）で2回、約10秒かかってerror: [Errno 32] Broken pipeが2回発生します。
このエラーは、私がdjangoメッセージフレームワークを使用して表示しようとしているメッセージを食べているようです。

んが、私は

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

でこの行を置き換えていない今のリロードはまだいくつかの10秒がかかりますが、Firefoxはメッセージが表示されます。

これまでのところ動作します。しかし、私にとっては、これは汚れたハックのように見えます。だから私の質問は次のとおりです：

1. 最初にエラーが何であるか説明できますか？
2. この「解決策」が将来私を噛んでしまうような問題はありますか？

（注：私は最初toexperiencethatproblemありませんよ）。

Answer 1

まず第一に、これはdjangoの問題ではなく、特定のブラウザ（おそらく、サーバー側での長い処理）の問題です。ジャンゴのbug reportから

：

これはdevのサーバーは、まだデータを送信ビジー状態である間、あなたのブラウザが接続を閉じたときに起こる一般的なエラーです。私たちができることは、より明示的なエラーメッセージを表示することです。実際にこれはちょうど、クライアントがサーバの前に、接続を閉じたことを意味して心配することは何もありませんcherrypy

から例えば、他のシステム上で発生する可能性が

。このトレースバックの後、CherryPyサーバーは引き続き正常に動作します。

だからそれはあなたの最初の質問への導入です：

1. 誰もが説明（または推測する）ことができ、エラーが最初の場所ですか？

まあ、それは単にブラウザが接続を閉じることです - クライアント側のタイムアウトのようなものです。 こちらはDjango + WebKit = Broken pipe答えはその質問にお答えします。

なぜlocation.hrefを変更し、location.reload()を使用しないと機能するのですか？まあ、私は推測しますが、それはFirefoxの動作がわずかに異なり、リロードが異なるようにタイムアウトするということだけです。

ブラウザがトリガーをプルして接続をシャットダウンしたときにリクエストが既に送信されているため、メッセージが消費されると思います。

devサーバはシングルスレッドであり、これも問題の要因となる可能性があります。

私は通常、実際の（ローカルの）サーバ（nginx + apache + mod_wsgi、何も気にしない）で自分の開発を行います。

2. この「解決策」が今後私を苦しめる可能性がある問題はありますか？

再ロードする前にhrefが変更されているかどうかを確認するブラウザではうまくいきません。または、実際のリクエストを行う代わりにキャッシュにヒットする可能性があります（reload（）でキャッシュを回避することができます）。また、すべてのブラウザで動作が一貫していない可能性があります。 しかし、もう一度、あなたはすでにブラウザの奇妙なことにぶつかっているので、私はあまり心配しません。ところで

、あなたは、単に行うことができます：私はむしろ処理が10秒かかることを心配でしょう

location.href = location.href 

！それは本当に起こるべきではありません。 だから、ブラウザ自体が長い処理時間と壊れたパイプエラーを引き起こしているようです。シングルスレッドのdjangoサーバー上の（悪い）並列要求が私に聞こえます。 endedit

実際のウェブサーバーでテストし、コードを最適化します。それが十分でないなら、セロリ+ rabbitmqを使ってバックグラウンドプロセスで長いタスクを立ち上げてください。いずれにせよ、本当に問題ではない問題で時間を失うことはありません！

あなたはたぶんlocation.reload()とちょっとした調整をしたり、実際のテスト環境を使ったりすることができます。

Answer 2

Djangoデバッグサーバの特定の機能のサポートが不足している可能性があります.DjangoのRange HTTP requests（詳細はByte Ranges in Djangoを参照してください）ストリーミング]メディアコンテンツ。

Wiresharkなどのパケットキャプチャプログラムを使用して実際のHTTP交換を調べることで、問題の発生場所と時期を確認できます。