Http-header-fields

HTTP-ヘッダーフィールド

HTTPヘッダーフィールドは、要求または応答、またはメッセージ本文で送信されるオブジェクトに関する必要な情報を提供します。 HTTPメッセージヘッダーには4つのタイプがあります。

• * General-header：*これらのヘッダーフィールドには、要求メッセージと応答メッセージの両方に一般的な適用性があります。
• * Client Request-header：*これらのヘッダーフィールドは、リクエストメッセージにのみ適用可能です。
• * Server Response-header：*これらのヘッダーフィールドは、応答メッセージにのみ適用可能です。
• * Entity-header：*これらのヘッダーフィールドは、エンティティ本体に関するメタ情報、または本体が存在しない場合はリクエストによって識別されるリソースに関するメタ情報を定義します。

一般的なヘッダー

キャッシュ制御

Cache-Control general-headerフィールドは、すべてのキャッシングシステムが従わなければならないディレクティブを指定するために使用されます。 構文は次のとおりです。

Cache-Control : cache-request-directive|cache-response-directive

HTTPクライアントまたはサーバーは、 Cache-control 一般ヘッダーを使用して、キャッシュのパラメーターを指定したり、キャッシュから特定の種類のドキュメントを要求したりできます。 キャッシングディレクティブは、コンマ区切りリストで指定されます。 例えば：

Cache-control: no-cache

次の表に、クライアントがHTTP要求で使用できる重要なキャッシュ要求ディレクティブを示します。

S.N.	Cache Request Directive and Description
1	no-cache キャッシュは、元のサーバーとの再検証が成功しない限り、後続の要求を満たすために応答を使用してはなりません。
2	no-store キャッシュには、クライアントのリクエストやサーバーの応答に関する情報を保存しないでください。
3	max-age = seconds クライアントが、指定された秒単位の時間より長くない応答を受け入れることを示します。
4	max-stale [ = seconds ] 有効期限を超えた応答をクライアントが受け入れようとしていることを示します。 秒が指定されている場合、その時間以上に期限切れになってはいけません。
5	min-fresh = seconds クライアントが、フレッシュネスライフタイムが現在の経過時間に秒単位で指定された時間を足したものよりも小さくない応答を受け入れる意思があることを示します。
6	no-transform エンティティ本体を変換しません。
7	only-if-cached 新しいデータを取得しません。 キャッシュは、ドキュメントがキャッシュ内にある場合にのみドキュメントを送信でき、新しいコピーが存在するかどうかを確認するために配信元サーバーに接続しないでください。

サーバーがHTTP応答で使用できる次の重要なキャッシュ応答ディレクティブ：

S.N.	Cache Response Directive and Description
1	public 応答が任意のキャッシュによってキャッシュされる可能性があることを示します。
2	private 応答メッセージのすべてまたは一部が単一のユーザー向けであり、共有キャッシュによってキャッシュされてはならないことを示します。
3	no-cache キャッシュは、元のサーバーで正常に再検証されない限り、後続の要求を満たすために応答を使用してはなりません。
4	no-store キャッシュには、クライアントのリクエストやサーバーの応答に関する情報を保存しないでください。
5	no-transform エンティティ本体を変換しません。
6	must-revalidate キャッシュは、使用する前に古いドキュメントのステータスを確認する必要があり、期限切れのドキュメントは使用しないでください。
7	proxy-revalidate proxy-revalidateディレクティブは、非共有ユーザーエージェントキャッシュに適用されないことを除いて、must-revalidateディレクティブと同じ意味を持ちます。
8	max-age = seconds クライアントが、指定された秒単位の時間より長くない応答を受け入れることを示します。
9	s-maxage = seconds このディレクティブで指定された最大年齢は、max-ageディレクティブまたはExpiresヘッダーで指定された最大年齢を上書きします。 s-maxageディレクティブは、プライベートキャッシュによって常に無視されます。

接続

Connection general-headerフィールドを使用すると、送信者はその特定の接続に必要なオプションを指定でき、プロキシはそれ以上の接続で通信することはできません。 接続ヘッダーを使用するための簡単な構文は次のとおりです。

Connection : "Connection"

HTTP/1.1は、送信者が「完了」接続オプションを定義して、応答の完了後に接続が閉じられることを通知します。 例えば：

Connection: close

デフォルトでは、HTTP 1.1は永続的な接続を使用します。この場合、接続はトランザクション後に自動的に閉じられません。 一方、HTTP 1.0には、デフォルトでは永続的な接続がありません。 1.0クライアントが永続的な接続を使用する場合、次のように keep-alive パラメーターを使用します。

Connection: keep-alive

Date

すべてのHTTP日付/時刻スタンプは、例外なくグリニッジ標準時（GMT）で表されなければなりません。 HTTPアプリケーションは、日付/時刻スタンプの次の3つの表現のいずれかを使用できます。

Sun, 06 Nov 1994 08:49:37 GMT  ; RFC 822, updated by RFC 1123
Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, obsoleted by RFC 1036
Sun Nov  6 08:49:37 1994       ; ANSI C's asctime() format

ここでは、最初の形式が最も優先されます。

プラグマ

Pragma general-headerフィールドは、要求/応答チェーンに沿った受信者に適用される可能性のある実装固有のディレクティブを含めるために使用されます。 例えば：

Pragma: no-cache

HTTP/1.0で定義されている唯一のディレクティブはno-cacheディレクティブであり、下位互換性のためにHTTP 1.1で維持されています。 将来、新しいプラグマディレクティブは定義されません。

トレーラー

Trailer一般フィールド値は、ヘッダーフィールドの指定されたセットが、チャンク転送コーディングでエンコードされたメッセージのトレーラに存在することを示します。 Trailerヘッダーフィールドの構文は次のとおりです。

Trailer : field-name

Trailerヘッダーフィールドにリストされるメッセージヘッダーフィールドには、次のヘッダーフィールドを含めることはできません。

• 転送エンコード
• コンテンツ長
• トレーラー

転送エンコード

Transfer-Encoding general-headerフィールドは、送信者と受信者の間で安全に転送するために、メッセージ本文に適用された変換のタイプを示します。 transfer-encodingはエンティティ本体ではなくメッセージのプロパティであるため、これはcontent-encodingとは異なります。 Transfer-Encodingヘッダーフィールドの構文は次のとおりです。

Transfer-Encoding: chunked

すべての転送コーディング値は大文字と小文字を区別しません。

アップグレード

_Upgrade_ジェネラルヘッダーを使用すると、クライアントは、サポートする追加の通信プロトコルを指定し、サーバーがプロトコルの切り替えに適していると判断した場合に使用することを指定できます。 例えば：

Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11

Upgradeヘッダーフィールドは、HTTP/1.1から他の互換性のないプロトコルへの移行のためのシンプルなメカニズムを提供することを目的としています。

Via

Via general-headerは、中間プロトコルと受信者を示すためにゲートウェイとプロキシによって使用される必要があります。 たとえば、HTTP/1.0ユーザーエージェントから「fred」というコード名の内部プロキシにリクエストメッセージを送信できます。このプロキシは、HTTP/1.1を使用してnowhere.comのパブリックプロキシにリクエストを転送します。 www.ics.uci.eduのオリジンサーバーに転送します。 www.ics.uci.eduが受信したリクエストには、次のViaヘッダーフィールドが含まれます。

Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1)

Upgradeヘッダーフィールドは、HTTP/1.1から他の互換性のないプロトコルへの移行のためのシンプルなメカニズムを提供することを目的としています。

警告

Warning general-headerは、メッセージに反映されない可能性のあるメッセージのステータスまたは変換に関する追加情報を伝えるために使用されます。 応答には、複数の警告ヘッダーが含まれる場合があります。

Warning : warn-code SP warn-agent SP warn-text SP warn-date

クライアントリクエストヘッダー

受け入れる

Accept request-headerフィールドを使用して、応答に受け入れられる特定のメディアタイプを指定できます。 一般的な構文は次のとおりです。

Accept: type/subtype [q=qvalue]

複数のメディアタイプをカンマで区切ってリストできます。オプションのqvalueは、0〜1のスケールの受け入れタイプの許容品質レベルを表します。 以下はその例です。

Accept: text/plain; q=0.5, text/html, text/x-dvi; q=0.8, text/x-c

これは text/html および text/xc として解釈され、優先されるメディアタイプですが、存在しない場合は text/x-dvi エンティティを送信し、存在しない場合は送信します text/plain エンティティ。

受け入れ文字セット

Accept-Charset request-headerフィールドを使用して、応答に受け入れられる文字セットを示すことができます。 一般的な構文は次のとおりです。

Accept-Charset: character_set [q=qvalue]

複数の文字セットをコンマで区切ってリストできます。オプションのqvalueは、0〜1のスケールでの非優先文字セットの許容品質レベルを表します。 以下はその例です。

Accept-Charset: iso-8859-5, unicode-1-1; q=0.8

*Accept-Charset* フィールドに存在する特別な値「*」はすべての文字セットに一致し、 *Accept-Charset* ヘッダーが存在しない場合、デフォルトでは任意の文字セットが受け入れられます。

受け入れエンコード

Accept-Encoding request-headerフィールドはAcceptに似ていますが、応答で受け入れられるコンテンツコーディングを制限します。 一般的な構文は次のとおりです。

Accept-Encoding: encoding types

例は次のとおりです。

Accept-Encoding: compress, gzip
Accept-Encoding:
Accept-Encoding: *
Accept-Encoding: compress;q=0.5, gzip;q=1.0
Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0

受け入れ言語

Accept-Language request-headerフィールドはAcceptに似ていますが、リクエストへの応答として優先される自然言語のセットを制限します。 一般的な構文は次のとおりです。

Accept-Language: language [q=qvalue]

複数の言語をコンマで区切ってリストできます。オプションのqvalueは、0〜1のスケールでの非優先言語の許容品質レベルを表します。 以下はその例です。

Accept-Language: da, en-gb;q=0.8, en;q=0.7

承認

Authorization request-headerフィールド値は、要求されているリソースのレルムのユーザーエージェントの認証情報を含む資格情報で構成されます。 一般的な構文は次のとおりです。

Authorization : credentials

HTTP/1.0仕様では、BASIC認可スキームが定義されています。認可パラメータは、base 64でエンコードされた username：password の文字列です。 以下はその例です。

Authorization: BASIC Z3Vlc3Q6Z3Vlc3QxMjM=

デコードされる値は guest：guest123 です。 guest はユーザーID、 guest123 はパスワードです。

クッキー

Cookie request-headerフィールドの値には、そのURLに保存されている情報の名前と値のペアが含まれています。 一般的な構文は次のとおりです。

Cookie: name=value

次のように、セミコロンで区切って複数のCookieを指定できます。

Cookie: name1=value1;name2=value2;name3=value3

期待する

Expect request-headerフィールドは、クライアントがサーバービヘイビアーの特定のセットを必要とすることを示すために使用されます。 一般的な構文は次のとおりです。

Expect : 100-continue | expectation-extension

サーバーが、サポートしていないExpectation-Extensionを含むExpectフィールドを含む要求を受信した場合、417（Expectation Failed）ステータスで応答する必要があります。

From

From request-headerフィールドには、要求元のユーザーエージェントを制御する人間のユーザーのインターネット電子メールアドレスが含まれています。 次に簡単な例を示します。

From: [email protected]

このヘッダーフィールドは、ロギングの目的で、無効または不要なリクエストのソースを識別する手段として使用できます。

Host

Host request-headerフィールドは、要求されているリソースのインターネットホストとポート番号を指定するために使用されます。 一般的な構文は次のとおりです。

Host : "Host" ":" host [ ":" port ] ;

末尾のポート情報のない host は、デフォルトのポートである80を意味します。 たとえば、_http：//www.w3.org/pub/WWW/_のオリジンサーバでのリクエストは次のようになります。

GET/pub/WWW/HTTP/1.1
Host: www.w3.org

一致する場合

If-Match request-headerフィールドは、条件付きにするメソッドとともに使用されます。 このヘッダーは、このタグの特定の値が ETag で表される特定のエンティティタグと一致する場合にのみ、要求されたメソッドの実行をサーバーに要求します。 一般的な構文は次のとおりです。

If-Match : entity-tag

アスタリスク（*）は任意のエンティティに一致し、トランザクションはエンティティが存在する場合にのみ続行されます。 可能な例は次のとおりです。

If-Match: "xyzzy"
If-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
If-Match: *

一致するエンティティタグがない場合、または「*」が指定されていて現在のエンティティが存在しない場合、サーバーは要求されたメソッドを実行してはならず、412（前提条件失敗）応答を返す必要があります。

If-Modified-Since

If-Modified-Since request-headerフィールドは、条件付きにするメソッドとともに使用されます。 このフィールドで指定された時間以降に要求されたURLが変更されていない場合、エンティティはサーバーから返されません。代わりに、メッセージ本文なしで304（変更なし）応答が返されます。 if-modified-sinceの一般的な構文は次のとおりです。

If-Modified-Since : HTTP-date

フィールドの例は次のとおりです。

If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT

一致するエンティティタグがない場合、または「*」が指定されていて現在のエンティティが存在しない場合、サーバーは要求されたメソッドを実行してはならず、412（前提条件失敗）応答を返す必要があります。

If-None-Match

If-None-Match request-headerフィールドは、条件付きにするメソッドとともに使用されます。 このヘッダーは、このタグの特定の値の1つが ETag で表される特定のエンティティタグと一致する場合にのみ、要求されたメソッドを実行するようサーバーに要求します。 一般的な構文は次のとおりです。

If-None-Match : entity-tag

アスタリスク（*）は任意のエンティティと一致し、トランザクションはエンティティが存在しない場合にのみ続行されます。 可能な例は次のとおりです。

If-None-Match: "xyzzy"
If-None-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
If-None-Match: *

If範囲

If-Range request-headerフィールドを条件付きGETで使用して、変更されていない場合はエンティティの一部のみ、変更されている場合はエンティティ全体を要求できます。 一般的な構文は次のとおりです。

If-Range : entity-tag | HTTP-date

エンティティタグまたは日付を使用して、すでに受信した部分エンティティを識別できます。 例えば：

If-Range: Sat, 29 Oct 1994 19:43:31 GMT

ここで、指定された日付以降にドキュメントが変更されていない場合、サーバーはRangeヘッダーで指定されたバイト範囲を返します。それ以外の場合は、すべての新しいドキュメントを返します。

未修正の場合

If-Unmodified-Since request-headerフィールドは、条件付きにするメソッドとともに使用されます。 一般的な構文は次のとおりです。

If-Unmodified-Since : HTTP-date

このフィールドで指定された時間以降に要求されたリソースが変更されていない場合、サーバーはIf-Unmodified-Sinceヘッダーが存在しないかのように要求された操作を実行する必要があります。 例えば：

If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT

リクエストの結果が2xxまたは412ステータス以外の場合、_If-Unmodified-Since_ヘッダーは無視する必要があります。

マックスフォワード

Max-Forwards request-headerフィールドは、リクエストを次のインバウンドサーバーに転送できるプロキシまたはゲートウェイの数を制限するためのTRACEおよびOPTIONSメソッドを備えたメカニズムを提供します。 一般的な構文は次のとおりです。

Max-Forwards : n

Max-Forwards値は、この要求メッセージを転送できる残りの回数を示す10進整数です。 これは、TRACEメソッドを使用したデバッグに役立ち、無限ループを回避します。 例えば：

Max-Forwards : 5

HTTP仕様で定義されている他のすべてのメソッドでは、Max-Forwardsヘッダーフィールドは無視される場合があります。

プロキシ承認

Proxy-Authorization request-headerフィールドを使用すると、クライアントは認証を必要とするプロキシに対して自分自身（またはそのユーザー）を識別できます。 一般的な構文は次のとおりです。

Proxy-Authorization : credentials

Proxy-Authorizationフィールドの値は、リクエストされているリソースのプロキシまたはレルムのユーザーエージェントの認証情報を含む資格情報で構成されます。

範囲

Range request-headerフィールドは、ドキュメントから要求されたコンテンツの部分的な範囲を指定します。 一般的な構文は次のとおりです。

Range: bytes-unit=first-byte-pos "-" [last-byte-pos]

byte-range-specのfirst-byte-pos値は、範囲の最初のバイトのバイトオフセットを示します。 last-byte-pos値は、範囲内の最後のバイトのバイトオフセットを示します。つまり、指定されたバイト位置は包括的です。 バイト単位をバイトとして指定できます。 バイトオフセットはゼロから始まります。 いくつかの簡単な例は次のとおりです。

- The first 500 bytes
Range: bytes=0-499

- The second 500 bytes
Range: bytes=500-999

- The final 500 bytes
Range: bytes=-500

- The first and last bytes only
Range: bytes=0-0,-1

複数の範囲をコンマで区切ってリストできます。 コンマで区切られたバイト範囲の最初の数字が欠落している場合、範囲はドキュメントの最後からカウントされると想定されます。 2番目の数字が欠落している場合、範囲はバイトnから文書の終わりまでです。

リファラー

Referer request-headerフィールドを使用すると、クライアントはURLが要求されたリソースのアドレス（URI）を指定できます。 一般的な構文は次のとおりです。

Referer : absoluteURI | relativeURI

次に簡単な例を示します。

Referer: http://www.finddevguides.org/http/index

フィールド値が相対URIである場合、_Request-URI_を基準にして解釈する必要があります。

TE

TE request-headerフィールドは、応答でどの拡張_transfer-coding_を受け入れるか、およびチャンク_transfer-coding_のトレーラフィールドを受け入れるかどうかを示します。 一般的な構文は次のとおりです。

TE   : t-codings

キーワード「trailers」の存在は、クライアントがチャンク転送コーディングのトレーラフィールドを受け入れようとしていることを示し、次のいずれかの方法で指定されます。

TE: deflate
TE:
TE: trailers, deflate;q=0.5

TEフィールド値が空の場合、またはTEフィールドが存在しない場合、転送コーディングのみがチャンクされます。 転送コーディングのないメッセージは常に受け入れられます。

ユーザーエージェント

User-Agent request-headerフィールドには、リクエストを発信したユーザーエージェントに関する情報が含まれています。 一般的な構文は次のとおりです。

User-Agent : product | comment

例：

User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)

サーバー応答ヘッダー

受諾範囲

Accept-Ranges response-headerフィールドを使用すると、サーバーはリソースに対する範囲要求の受け入れを示すことができます。 一般的な構文は次のとおりです。

Accept-Ranges  : range-unit | none

たとえば、バイト範囲要求を受け入れるサーバーは次を送信できます。

Accept-Ranges: bytes

リソースに対する範囲要求の種類を受け入れないサーバーは、以下を送信できます。

Accept-Ranges: none

これは、範囲要求を試行しないようにクライアントにアドバイスします。

Age

Age response-headerフィールドは、発信元サーバーで応答（またはその再検証）が生成されてからの送信者の推定時間を伝えます。 一般的な構文は次のとおりです。

Age : delta-seconds

年齢の値は負でない10進整数で、秒単位の時間を表します。 次に簡単な例を示します。

Age: 1030

キャッシュを含むHTTP/1.1サーバーは、独自のキャッシュから生成されるすべての応答にAgeヘッダーフィールドを含める必要があります。

ETag

_ETag_応答ヘッダーフィールドは、要求されたバリアントのエンティティタグの現在の値を提供します。 一般的な構文は次のとおりです。

ETag :  entity-tag

ここにいくつかの簡単な例があります：

ETag: "xyzzy"
ETag: W/"xyzzy"
ETag: ""

ロケーション

_Location_応答ヘッダーフィールドは、受信者を完了のためにRequest-URI以外の場所にリダイレクトするために使用されます。 一般的な構文は次のとおりです。

Location : absoluteURI

次に簡単な例を示します。

Location: http://www.finddevguides.org/http/index

Content-Locationヘッダーフィールドは、Content-Locationがリクエストに含まれるエンティティの元の場所を識別するという点でLocationと異なります。

プロキシ認証

Proxy-Authenticate response-headerフィールドは、407（Proxy Authentication Required）応答の一部として含める必要があります。 一般的な構文は次のとおりです。

Proxy-Authenticate  : challenge

再試行後

Retry-After response-headerフィールドを503（Service Unavailable）応答と共に使用して、要求元のクライアントがサービスを利用できないと予想される期間を示すことができます。 一般的な構文は次のとおりです。

Retry-After : HTTP-date | delta-seconds

例：

Retry-After: Fri, 31 Dec 1999 23:59:59 GMT
Retry-After: 120

後者の例では、遅延は2分です。

サーバ

Server response-headerフィールドには、要求を処理するためにオリジンサーバーが使用するソフトウェアに関する情報が含まれています。 一般的な構文は次のとおりです。

Server : product | comment

次に簡単な例を示します。

Server: Apache/2.2.14 (Win32)

応答がプロキシを介して転送される場合、プロキシアプリケーションはサーバーの応答ヘッダーを変更してはなりません。

セットクッキー

Set-Cookie response-headerフィールドには、このURLで保持する情報の名前と値のペアが含まれています。 一般的な構文は次のとおりです。

Set-Cookie: NAME=VALUE; OPTIONS

Set-Cookie応答ヘッダーは、トークンSet-Cookieの後に1つ以上のCookieのコンマ区切りリストが続きます。 オプションとして指定できる値は次のとおりです。

S.N.	Options and Description
1	Comment=comment このオプションを使用して、Cookieに関連付けられたコメントを指定できます。
2	Domain=domain Domain属性は、Cookieが有効なドメインを指定します。
3	Expires=Date-time Cookieの有効期限が切れる日付。 空白の場合、訪問者がブラウザを終了すると、Cookieは期限切れになります。
4	Path=path Path属性は、このCookieが適用されるURLのサブセットを指定します。
5	Secure セキュア接続下でのみクッキーを返すようにユーザーエージェントに指示します。

以下は、サーバーによって生成される単純なCookieヘッダーの例です。

Set-Cookie: name1=value1,name2=value2; Expires=Wed, 09 Jun 2021 10:18:14 GMT

Vary

Vary response-headerフィールドは、エンティティに複数のソースがあることを指定しているため、指定されたリクエストヘッダーのリストによって異なる場合があります。 一般的な構文は次のとおりです。

Vary : field-name

複数のヘッダーをコンマで区切って指定し、アスタリスク「*」の値を指定すると、未指定のパラメーターが要求ヘッダーに限定されないことを通知できます。 次に簡単な例を示します。

Vary: Accept-Language, Accept-Encoding

ここで、フィールド名は大文字と小文字を区別しません。

WWW-認証

WWW-Authenticate response-headerフィールドは、401（無許可）応答メッセージに含める必要があります。 フィールド値は、Request-URIに適用可能な認証スキームとパラメーターを示す少なくとも1つのチャレンジで構成されます。 一般的な構文は次のとおりです。

WWW-Authenticate : challenge

WWW-Authenticateフィールドの値には複数のチャレンジが含まれる場合があります。または、複数のWWW-Authenticateヘッダーフィールドが提供される場合、チャレンジ自体のコンテンツに認証パラメーターのコンマ区切りリストを含めることができます。 次に簡単な例を示します。

WWW-Authenticate: BASIC realm="Admin"

エンティティヘッダー

許可する

Allow entity-headerフィールドには、Request-URIで識別されるリソースでサポートされるメソッドのセットがリストされます。 一般的な構文は次のとおりです。

Allow : Method

複数のメソッドをコンマで区切って指定できます。 次に簡単な例を示します。

Allow: GET, HEAD, PUT

このフィールドは、クライアントが他の方法を試みることを防ぐことはできません。

コンテンツエンコード

Content-Encoding entity-headerフィールドは、メディアタイプの修飾子として使用されます。 一般的な構文は次のとおりです。

Content-Encoding : content-coding

content-codingは、Request-URIによって識別されるエンティティの特性です。 次に簡単な例を示します。

Content-Encoding: gzip

要求メッセージ内のエンティティのコンテンツコーディングがオリジンサーバに受け入れられない場合、サーバは415（サポートされていないメディアタイプ）のステータスコードで応答する必要があります。

コンテンツ言語

Content-Language entity-headerフィールドは、囲まれたエンティティの対象オーディエンスの自然言語を示します。 一般的な構文は次のとおりです。

Content-Language : language-tag

複数の視聴者を対象としたコンテンツには、複数の言語がリストされる場合があります。 次に簡単な例を示します。

Content-Language: mi, en

Content-Languageの主な目的は、ユーザーがユーザー自身の優先言語に従ってエンティティを識別および区別できるようにすることです。

コンテンツ長

Content-Length entity-headerフィールドは、10進数のOCTETで受信者に送信されたエンティティ本体のサイズ、またはHEADメソッドの場合は送信されたエンティティ本体のサイズを示します。リクエストがGETであった場合。 一般的な構文は次のとおりです。

Content-Length : DIGITS

次に簡単な例を示します。

Content-Length: 3495

ゼロ以上の任意のContent-Lengthは有効な値です。

コンテンツの場所

Content-Location entity-headerフィールドは、要求されたリソースのURIとは別の場所からアクセスできる場合、メッセージに含まれるエンティティのリソースの場所を提供するために使用できます。 一般的な構文は次のとおりです。

Content-Location:  absoluteURI | relativeURI

次に簡単な例を示します。

Content-Location: http://www.finddevguides.org/http/index

Content-Locationの値は、エンティティのベースURIも定義します。

コンテンツ-MD5

Content-MD5 entity-headerフィールドは、受信時にメッセージの整合性をチェックするためのエンティティのMD5ダイジェストを提供するために使用できます。 一般的な構文は次のとおりです。

Content-MD5  : md5-digest using base64 of 128 bit MD5 digest as per RFC 1864

次に簡単な例を示します。

Content-MD5  : 8c2d46911f3f5a326455f0ed7a8ed3b3

MD5ダイジェストは、エンティティ本体のコンテンツに基づいて計算されます。これには、適用されたコンテンツコーディングが含まれますが、メッセージ本文に適用される転送エンコードは含まれません。

コンテンツ範囲

Content-Range entity-headerフィールドは、部分的なエンティティ本体とともに送信され、完全なエンティティ本体のどこに部分的な本体を適用するかを指定します。 一般的な構文は次のとおりです。

Content-Range : bytes-unit SP first-byte-pos "-" last-byte-pos

エンティティに合計1234バイトが含まれると仮定した、byte-content-range-spec値の例：

- The first 500 bytes:
Content-Range : bytes 0-499/1234

- The second 500 bytes:
Content-Range : bytes 500-999/1234

- All except for the first 500 bytes:
Content-Range : bytes 500-1233/1234

- The last 500 bytes:
Content-Range : bytes 734-1233/1234

HTTPメッセージに単一の範囲のコンテンツが含まれる場合、このコンテンツはContent-Rangeヘッダーと、実際に転送されたバイト数を示すContent-Lengthヘッダーと共に送信されます。 例えば、

HTTP/1.1 206 Partial content
Date: Wed, 15 Nov 1995 06:25:24 GMT
Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
Content-Range: bytes 21010-47021/47022
Content-Length: 26012
Content-Type: image/gif

コンテンツタイプ

Content-Type entity-headerフィールドは、受信者に送信されたエンティティ本体のメディアタイプ、またはHEADメソッドの場合、送信されたメディアタイプ（リクエストがGETであった場合）を示します。 一般的な構文は次のとおりです。

Content-Type : media-type

以下はその例です。

Content-Type: text/html; charset=ISO-8859-4

有効期限

Expires entity-headerフィールドは、応答が古くなったと見なされる日時を示します。 一般的な構文は次のとおりです。

Expires : HTTP-date

以下はその例です。

Expires: Thu, 01 Dec 1994 16:00:00 GMT

最終更新日

Last-Modified entity-headerフィールドは、オリジンサーバがバリアントが最後に変更されたと信じる日時を示します。 一般的な構文は次のとおりです。

Last-Modified: HTTP-date

以下はその例です。

Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT