ゲッターとセッターでビジネス ロジックを記述することは非常に悪いプログラミング手法であることは知っていますが、応答が既にコミットされている場合に例外を処理する方法はありますか?
「レスポンスはすでにコミットされています」と「ヘッダーはすでにクライアントに送信されています」の正確な意味は何ですか?
質問する
15700 次
2 に答える
16
応答が既にコミットされている場合、例外を処理する良い方法はありません。HTTP レスポンスは、基本的にヘッダーとボディで構成されます。ヘッダーは基本的にクライアント (Web ブラウザー) に、応答をどのように処理する必要があるかを指示します。たとえば、コンテンツの種類、コンテンツの長さ、文字のエンコード、本文のエンコード、キャッシュの指示などです。
Web ブラウザーの開発者ツールセットの HTTP トラフィック モニターでヘッダーを確認できます。Chrome/IE9+/Firefox23+ で F12 を押して、「ネットワーク」タブを確認します。以下のスクリーンショットは、現在の質問で私の Chrome が表示するものです。
(注: 「応答」タブには応答本文が表示されます)
応答本文は実際のコンテンツであり、通常は一連の HTML コードに似ています。通常、サーバーには、応答を書き込むための固定サイズのバッファーがあります。バッファ サイズは、サーバーのメーカー/バージョンおよび構成によって異なり、通常は 2KB ～ 10KB です。このバッファがオーバーフローすると、接続の反対側であるクライアントにフラッシュされます。これは応答のコミットです。クライアントはすでに応答の最初の部分を取得しており、通常はすでにヘッダー全体と、場合によっては本文の一部を表しています。
応答のコミットは後戻りできません。サーバーは、送信済みのバイトを取り戻すことはできません。応答ヘッダーを変更するには遅すぎます (たとえば、リダイレクトは基本的Locationに新しい URL を含むヘッダーによって指示されます)、応答本文は言うまでもありません。あなたができる最善のことは、既に書き込まれた応答本文にエラー情報を追加することです。しかし、その時点でどの HTML タグを閉じる必要があるかがわからないため、奇妙な HTML になる可能性があります。ブラウザが正しく表示できない場合があります。
応答のレンダリング中に例外がスローされないようにゲッターでビジネス ロジックを回避することとは別に、既にコミットされた応答を回避する別の方法は、Web アプリケーションが提供できる最大のページと同じ大きさになるように応答バッファー サイズを構成することです。その方法は、サーバーのメーカー/バージョンによって異なります。たとえばTomcatでは、要素bufferSizeの属性<Connector>として設定できます。flush()独自のコードが (暗黙的に)応答出力ストリームを呼び出している場合、これはフラッシュを妨げないことに注意してください。
于 2013-01-18T10:51:44.223 に答える