web-dev-qa-db-ja.com

必要なHTTP応答ヘッダー

サーバーからクライアントに送信するのに必要なHTTP応答ヘッダーは何ですか？

HTTP応答のオーバーヘッドを最小化するために、HTTP応答ヘッダーを最適化する作業をしています。 「オーバーヘッド」はいくぶん誇張されていることは知っていますが、きれいな出力が好きです。

冗長キャッシュヘッダーを送信する多くのWebサイトが表示されます。

例えば.

ExpiresとCache-Control: max-ageの両方を指定したり、Last-ModifiedとETagの両方を指定したりすることは冗長です。

  • ソース
  • HTTP/1.1：ヘッダーフィールド定義
httphttp-headershttpresponse
58
Beni

必要であると定義するものに依存します。状況に関係なく、すべての応答で送信する必要のあるヘッダーフィールドはありませんが、実際にはshould送信するヘッダーフィールドがあります。近くに来る唯一のヘッダーフィールドはDateですが、それでも必要ない状況があります。

RFC 2119 の用語では、用語[〜＃〜] must [〜＃〜]は、何かが仕様の要件であり、要件を満たさないことは無効であることを意味します。 RFCで定義されたヘッダーフィールドはありません 7230 、 7231 、 7232 、 7233 、 7234 、または 7235 that[〜＃〜] [〜＃〜]はOriginサーバーによって送信される必要がありますすべての場合。

たとえば、次のヘッダーは省略できます（おそらく送信する必要があります）。

7.1.1.2。日付

Originサーバーは、協定世界時の現在のインスタンスの合理的な近似値を提供できるクロックを持たない場合、Dateヘッダーフィールドを送信してはいけません。応答がステータスコードの1xx（情報）または5xx（サーバーエラー）クラスの場合、OriginサーバーはDateヘッダーフィールドを送信できます。 Originサーバーは、他のすべての場合にDateヘッダーフィールドを送信しなければなりません。

引用の最後の文に注意してください。 Dateヘッダーフィールド[〜＃〜] [〜＃〜]は、Originサーバーが「 UTCでの日付の合理的な近似」ですが、サーバーがそれ自体を不正確に表示するのを止めるものは何もありません。

7.4.2。サーバ

Originサーバーは、その応答でServerフィールドを生成する場合があります。

3.3.2。コンテンツ長

[有限数の事前定義済みのケース]を除き、Transfer-Encodingがない場合、Originサーバーは、ヘッダーセクション全体を送信する前にペイロードのボディサイズがわかっている場合、Content-Lengthヘッダーフィールドを送信する必要があります。

Content-LengthとTransfer-Encodingについては、どちらも送信できないことに注意してください。この場合、応答の長さは「サーバーが接続を閉じる前に受信したオクテットの数によって決まります」。

3.1.1.5。コンテンツタイプ

Content-Typeヘッダーフィールドが存在しない場合、受信者はapplication/octet-stream（RFC2046、セクション4.5.1）のメディアタイプを想定するか、データを調べてそのタイプを判断できます。

特定のヘッダーが必要になる状況があります。たとえば、次のとおりです。

56
Whymarrh

応答の詳細に依存しますが、一般的に、Originサーバーからの応答には以下が必要です。

  • 日付
  • コンテンツタイプ
  • サーバ

content-Length、Transfer-Encoding、またはConnection：closeのいずれか。

キャッシングを行う場合は、Cache-Controlを追加します（例：max-age）;通常、有効期限はもう必要ありません。クライアントが検証できるようにする場合は、Last-ModifiedまたはETagを追加します。

22
Mark Nottingham