セキュリティテスト-HTTPヘッダーフィールド

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.No.	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.No.	Cache Request 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クライアントが永続的な接続を使用したい場合、それは次のように*キープアライブ*パラメータを使用します-

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のパブリックプロキシに要求を転送します。 [[1]] 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: 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 : HTTP-date

フィールドの例は-

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

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

If-None-Match

If-None-Match request-headerフィールドは、条件付きにするメソッドとともに使用されます。このヘッダーは、このタグの特定の値のいずれかが 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

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

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

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

ユーザーエージェント

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

以下は2つの簡単な例です-

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.No.	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を返すようにユーザーエージェントに指示します。

以下は、サーバーによって生成された単純な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フィールドは、OCTETの10進数で受信者に送信されたエンティティ本体のサイズを示します。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

Security-testing-http-headerfields

セキュリティテスト-HTTPヘッダーフィールド

HTTPヘッダーフィールド

一般的なヘッダー

キャッシュ制御

接続

Date

プラグマ

トレーラー

転送エンコード

アップグレード

Via

警告

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

受け入れる

受け入れ文字セット

受け入れエンコード

受け入れ言語

承認

クッキー

期待する

From

Host

一致する場合

If-Modified-Since

If-None-Match

If範囲

未修正の場合

マックスフォワード

プロキシ承認

範囲

リファラー

TE

ユーザーエージェント

サーバー応答ヘッダー

受諾範囲

Age

ETag

ロケーション

プロキシ認証

再試行後

サーバ

セットクッキー

Vary

WWW-認証

エンティティヘッダー

許可する

コンテンツエンコード

コンテンツ言語

コンテンツ長

コンテンツの場所

コンテンツ-MD5

コンテンツ範囲

コンテンツタイプ

有効期限

最終更新日