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リクエストで使用できる重要なキャッシュリクエストディレクティブを示します。

SN	キャッシュリクエストのディレクティブと説明
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応答で使用できる次の重要なキャッシュ応答ディレクティブ：

SN	キャッシュ応答ディレクティブと説明
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 : "Connection"

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

Connection: close

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

Connection: keep-alive

日付

すべての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ディレクティブであり、下位互換性のためにHTTP1.1で維持されています。今後、新しいPragmaディレクティブは定義されません。

トレーラー

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

Trailer : field-name

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

Transfer-Encoding
Content-Length
Trailer

転送エンコーディング

転送エンコード一般ヘッダフィールドは、変換のタイプが安全送信者と受信者の間に転送するためにメッセージボディに適用されたものを示しています。transfer-encodingsはメッセージのプロパティであり、entity-bodyのプロパティではないため、これはcontent-encodingと同じではありません。Transfer-Encodingヘッダーフィールドの構文は次のとおりです。

Transfer-Encoding: chunked

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

アップグレード

アップグレードの一般ヘッダは、クライアントがサポートしている追加の通信プロトコルを指定することができ、サーバはそれがスイッチプロトコルに適当であると認める場合には、使用したいと思います。例えば：

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

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

経由

ビア一般ヘッダは、中間プロトコルおよび受信者を示すためにゲートウェイやプロキシによって使用されなければなりません。たとえば、リクエストメッセージを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 : warn-code SP warn-agent SP warn-text SP warn-date

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

受け入れる

受け入れリクエストヘッダフィールドは、応答のために許容される特定のメディアタイプを指定するために使用することができます。一般的な構文は次のとおりです。

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/x-c およびが推奨されるメディアタイプですが、それらが存在しない場合は、 text/x-dvi エンティティ、およびそれが存在しない場合は、 text/plain エンティティ。

Accept-Charset

受け入れ、文字セットリクエストヘッダフィールドは、文字セットは、応答のために許容可能であるかを示すために使用することができます。一般的な構文は次のとおりです。

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

受け入れエンコードリクエストヘッダフィールドは、そのまま使用することが同様であるが、応答に許容される内容コーディングを制限します。一般的な構文は次のとおりです。

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: language [q=qvalue]

複数の言語をコンマで区切ってリストすることができ、オプションのqvalueは、0から1のスケールで非優先言語の許容可能な品質レベルを表します。以下に例を示します。

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

承認

認可リクエストヘッダフィールド値は要求されたリソースのレルムのユーザエージェントの認証情報を含む資格情報から成ります。一般的な構文は次のとおりです。

Authorization : credentials

HTTP / 1.0仕様では、BASIC認証スキームが定義されています。ここで、認証パラメータは次の文字列です。 username:password Base64でエンコードされます。次に例を示します。

Authorization: BASIC Z3Vlc3Q6Z3Vlc3QxMjM=

にデコードされる値は guest:guest123 どこ guest はユーザーIDであり、 guest123 はパスワードです。

クッキー

クッキーリクエスト・ヘッダー・フィールドの値は、その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: [email protected]

このヘッダーフィールドは、ログ記録の目的で、および無効または不要な要求のソースを識別する手段として使用できます。

ホスト

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

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

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

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

If-Match

もしマッチリクエストヘッダフィールドは、条件付きにする方法に使用されます。このヘッダーは、このタグの指定された値がで表される指定されたエンティティタグと一致する場合にのみ、要求されたメソッドを実行するようサーバーに要求します。ETag。一般的な構文は次のとおりです。

If-Match : entity-tag

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

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

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

変更された場合-以降

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

If-Modified-Since : HTTP-date

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

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

If-None-Match

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

If-None-Match : entity-tag

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

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

If-Range

もしレンジリクエストヘッダフィールドは、それが変更された場合のみ、変更されていない場合、欠落している実体の部分、及び全体エンティティを要求するために条件付きGETと共に使用することができます。一般的な構文は次のとおりです。

If-Range : entity-tag | HTTP-date

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

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

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

If-Unmodified-Since

もし非改変-のでリクエストヘッダフィールドは、それが条件付きにする方法に使用されます。一般的な構文は次のとおりです。

If-Unmodified-Since : HTTP-date

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

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

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

マックスフォワード

マックスを転送リクエストヘッダフィールドは、次のインバウンドサーバに要求を転送することができるプロキシまたはゲートウェイの数を制限するTRACEとOPTIONS方法とメカニズムを提供します。一般的な構文は次のとおりです。

Max-Forwards : n

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

Max-Forwards : 5

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

プロキシ認証

プロキシ認証リクエストヘッダフィールドは、クライアントが認証を必要とするプロキシにそれ自体（又はそのユーザ）を識別することを可能にします。一般的な構文は次のとおりです。

Proxy-Authorization : credentials

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

範囲

レンジリクエストヘッダフィールドは、コンテンツの一部の範囲（複数可）は、文書から要求を指定します。一般的な構文は次のとおりです。

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からドキュメントの終わりまでです。

リファラー

リファラーリクエストヘッダフィールドは、クライアントがURLが要求されたリソースのアドレス（URI）を指定することができます。一般的な構文は次のとおりです。

Referer : absoluteURI | relativeURI

以下は簡単な例です。

Referer: http://www.tutorialspoint.org/http/index.htm

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

TE

TEリクエストヘッダフィールドは、拡張かを示す転送コーディング応答して、チャンクにトレーラフィールド受け入れる意志があるか否かを受け入れる意志がある転送コーディングを。一般的な構文は次のとおりです。

TE   : t-codings

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

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

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

ユーザーエージェント

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

User-Agent : product | comment

例：

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

サーバー応答ヘッダー

Accept-Ranges

受け入れ-範囲レスポンスヘッダフィールドは、サーバがリソースの範囲要求の受諾を示すことを可能にします。一般的な構文は次のとおりです。

Accept-Ranges  : range-unit | none

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

Accept-Ranges: bytes

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

Accept-Ranges: none

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

年齢

年齢レスポンスヘッダフィールドは、応答（またはその再検証）からの経過時間の量の送信者の推定オリジンサーバで生成された搬送します。一般的な構文は次のとおりです。

Age : delta-seconds

経過時間の値は負でない10進整数であり、時間を秒単位で表します。以下は簡単な例です。

Age: 1030

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

ETag

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

ETag :  entity-tag

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

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

ロケーション

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

Location : absoluteURI

以下は簡単な例です。

Location: http://www.tutorialspoint.org/http/index.htm

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

プロキシ認証

プロキシ認証レスポンス・ヘッダー・フィールドは、407（プロキシ認証が必要）応答の一部として含まれなければなりません。一般的な構文は次のとおりです。

Proxy-Authenticate  : challenge

再試行-後

リトライ後レスポンスヘッダフィールドは、サービスを要求しているクライアントに利用できないと予想される時間の長さを示すために503（サービス利用不可）応答と共に使用することができます。一般的な構文は次のとおりです。

Retry-After : HTTP-date | delta-seconds

例：

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

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

サーバ

サーバーレスポンスヘッダフィールドは、リクエストを処理するためにオリジンサーバによって使用されているソフトウェアに関する情報が含まれています。一般的な構文は次のとおりです。

Server : product | comment

以下は簡単な例です。

Server: Apache/2.2.14 (Win32)

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

セットクッキー

Set-Cookieレスポンス・ヘッダー・フィールドは、このURLのために保持する情報の名前/値ペアを含んでいます。一般的な構文は次のとおりです。

Set-Cookie: NAME=VALUE; OPTIONS

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

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

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

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

変化する

ヴァリエンティティが複数のソースを有し、したがって、リクエストヘッダ（単数または複数）の指定されたリストに応じて変化し得ることレスポンス・ヘッダー・フィールドを指定します。一般的な構文は次のとおりです。

Vary : field-name

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

Vary: Accept-Language, Accept-Encoding

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

WWW-認証

WWW認証応答ヘッダフィールドは401（不正な）応答メッセージに含まれなければなりません。フィールド値は、Request-URIに適用可能な認証スキームとパラメーターを示す少なくとも1つのチャレンジで構成されます。一般的な構文は次のとおりです。

WWW-Authenticate : challenge

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

WWW-Authenticate: BASIC realm="Admin"

エンティティヘッダー

許可する

許可エンティティヘッダフィールドのリストをリクエストURIによって識別されたリソースによってサポートされるメソッドのセット。一般的な構文は次のとおりです。

Allow : Method

複数のメソッドをコンマで区切って指定できます。以下は簡単な例です。

Allow: GET, HEAD, PUT

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

コンテンツエンコーディング

コンテンツ符号化エンティティ-ヘッダフィールドはメディアタイプの修飾子として使用されます。一般的な構文は次のとおりです。

Content-Encoding : content-coding

コンテンツコーディングは、Request-URIによって識別されるエンティティの特性です。以下は簡単な例です。

Content-Encoding: gzip

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

コンテンツ-言語

コンテンツ言語エンティティヘッダフィールドは、同封のエンティティの対象読者の自然言語（複数可）を記述する。一般的な構文は次のとおりです。

Content-Language : language-tag

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

Content-Language: mi, en

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

コンテンツの長さ

Content-Lengthエンティティヘッダフィールドは、HEADメソッドの場合には、受信者に送信されるか、またはオクテットの進数、送信されたであろうエンティティボディのサイズは、エンティティボディのサイズを示しますリクエストはGETでした。一般的な構文は次のとおりです。

Content-Length : DIGITS

以下は簡単な例です。

Content-Length: 3495

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

コンテンツ-場所

コンテンツロケーションエンティティヘッダフィールドは、そのエンティティは、要求されたリソースのURIから離れた場所からアクセス可能である場合、メッセージで囲まれたエンティティのリソースの場所を供給するために使用されてもよいです。一般的な構文は次のとおりです。

Content-Location:  absoluteURI | relativeURI

以下は簡単な例です。

Content-Location: http://www.tutorialspoint.org/http/index.htm

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

コンテンツ-MD5

コンテンツ-MD5エンティティヘッダフィールドは、受信するメッセージの完全性をチェックするためのエンティティのMD5ダイジェストを供給するために使用されてもよいです。一般的な構文は次のとおりです。

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

以下は簡単な例です。

Content-MD5  : 8c2d46911f3f5a326455f0ed7a8ed3b3

MD5ダイジェストは、適用されたコンテンツコーディングを含むが、メッセージボディに適用された転送エンコーディングを含まないエンティティボディのコンテンツに基づいて計算されます。

コンテンツ範囲

コンテンツレンジエンティティヘッダフィールドは、完全なエンティティボディに身体部分が適用されるべき場所を指定する部分エンティティボディで送信されます。一般的な構文は次のとおりです。

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エンティティヘッダフィールドは、HEADメソッドの場合には、受信者に送信されたエンティティボディのメディアタイプを示し、または、送信されたであろうメディアタイプは、リクエストがGETされていました。一般的な構文は次のとおりです。

Content-Type : media-type

次に例を示します。

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

有効期限が切れます

有効期限エンティティヘッダフィールドは、応答が古くなったとみなされた後の日付/時間を与えます。一般的な構文は次のとおりです。

Expires : HTTP-date

次に例を示します。

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

最終更新日

Last-Modifiedエンティティヘッダフィールドは、オリジンサーバがバリアントが最後に変更されたと考えていた日時を示します。一般的な構文は次のとおりです。

Last-Modified: HTTP-date

次に例を示します。

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