HTTPヘッダフィールドの一覧

ウィキペディア小見出し辞書

HTTPヘッダフィールドの一覧

出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2022/06/07 20:16 UTC 版)

「Hypertext Transfer Protocol」の記事における「HTTPヘッダフィールドの一覧」の解説

リクエストヘッダヘッダ概要HTTP/0.9HTTP/1.0HTTP/1.1Accept クライアントの受け入れ可能コンテンツタイプを示す ○ ○ Accept-Charset クライアントの受け入れ可能文字セットを示す ○ ○ Accept-Encoding クライアントの受け入れ可能文字エンコーディングを示す ○ ○ Accept-Language クライアントの受け入れ可能言語を示す ○ ○ Authorization クライアントの認証情報を示す ○ ○ Cookie クライアントの状態管理情報をサーバに返す Cookie2 HTTP/1.1のSet-Cookie2ヘッダの受け入れ可能をサーバに知らせる Expect クライアントがサーバに期待する動作を示す ○ From リクエスト発行者個人の情報を示す。一般的に電子メールアドレスを使用する ○ ○ Host 要求しているオブジェクトがあるホストを示す ○ If-Match if文を用い条件が真の場合のみリクエストを処理するようサーバに要求する ○ If-None-Match If-Matchの逆で条件が真でない場合のみリクエストを処理する要求 ○ If-Range 条件が真の場合のみ指定したオブジェクトの範囲を返すようサーバに要求する ○ If-Modified-Since 指定日時以降にオブジェクトが変更されている場合のみリクエストを処理するよう要求する ○ ○ If-Unmodified-Since If-Modified-Sinceの逆で真でないときのみ実行する ○ Max-Forwards リクエストの中間システム経由数を最大いくつまでかを指定する ○ Proxy-Authorization クライアントがプロキシサーバに対して自身の認証を行う ○ Range オブジェクト全体でなくリソースの一部を要求する ○ Referer リクエストの出所を示す。一般的にはユーザの辿ったWebページのURLが用いられる ○ ○ TE レスポンスの受け入れ可能転送エンコーディングを示す ○ User-Agent クライアントのWebブラウザなどの情報を示す ○ ○ レスポンスヘッダヘッダ概要HTTP/0.9HTTP/1.0HTTP/1.1Accept-Ranges オブジェクトの一部に対するリクエストをサーバが受け入れ可能か示す ○ Age オブジェクトの経過時間を秒単位で返す ○ ETag オブジェクトのエンティティタグ値を示す ○ Location オブジェクトの場所を示す ○ ○ Proxy-Authenticate プロキシサーバがクライアントに認証を要求するときに用いる ○ Retry-After リクエストの再試行をいつ行うかをクライアントに通知する ○ ○ Server サーバのベンダー名、バージョン番号を示す ○ ○ Set-Cookie2 サーバがクライアントにCookieを送信するときに用いる Vary サーバがレスポンス内容を決定する際にリクエストURI以外に用いたヘッダのリストを示す ○ WWW-Authenticate クライアントに対してリクエストの再発行を要求する。認証情報も含まれる ○ ○ 一般ヘッダヘッダ概要HTTP/0.9HTTP/1.0HTTP/1.1Cache-Control メッセージの経由する中間キャッシュの動作を指示する ○ Connection 当該の接続に対するオプションを指示する ○ Date メッセージの作成日時を示す ○ ○ Pragma メッセージに関する追加情報を示す ○ ○ Trailer メッセージボディの後に追加のヘッダーが表れることを示す ○ Transfer-Encoding クライアントの転送を目的としたオブジェクトのエンコーディングを示す ○ Upgrade 通信相手に別のプロトコルにアップデートするよう要求する ○ Via プロキシサーバなど中継地点を示す。 ○ Warning メッセージに関する追加情報を示す。通常はキャッシュの問題を警告するときに使われる ○ エンティティヘッダヘッダ概要HTTP/0.9HTTP/1.0HTTP/1.1Allow オブジェクトがサポートするHTTPメソッドを示す ○ ○ Content-Encoding オブジェクトのエンコーディングを示す ○ ○ Content-Language オブジェクトの言語（人間の言語）を示す ○ ○ Content-Length オブジェクトのサイズをバイト単位で示す ○ ○ Content-Location オブジェクトの場所を示す ○ Content-MD5 オブジェクトのメッセージダイジェストを運ぶ △ Content-Range メッセージボディで運ばれるオブジェクトの範囲を示す ○ Content-Type オブジェクトのタイプを示す ○ ○ Expires オブジェクトの有効期限の日時を示す ○ ○ Last-Modified オブジェクトが最後に変更された日時を示す ○ ○ Accept サーバのレスポンスに含まれるメッセージボディで受け入れることが出来るコンテンツタイプと各コンテンツタイプの相対的な優先度を指定するリクエストヘッダ。指定できるコンテンツタイプはIANAによって定義されている。 Accept: text/plain; q=0.5, text/html,text/x-dvi; q=0.8, text/x-c 上記のようにAcceptヘッダには行をわけて複数のコンテンツタイプを指定できる。上記の例はいずれの4のコンテンツタイプのいずれも受け入れ可能であることを示す。0.5や0.8といった数字は品質係数で0〜1の範囲の数値である。数値の指定がなければ1.0となる。text/plain; q=0.5 text/html text/x-dvi; q=0.8 text/x-c Accept-Charset レスポンスで返されるメッセージボディの文字コードを指定するリクエストヘッダ。Acceptと同じく複数指定でき品質係数も設定できる。定義済み文字セットはIANAが管理している。 Accept-Charset: UTF-8, *; q=0.8 この例だとクライアントはUTF-8を優先的に希望しているが他の文字セットとの相対優先度0.8で受け入れている。ただしサーバからのレスポンスのHTTPヘッダそのものの文字コードは常にISO-8859-1である。 Accept-Encoding クライアントが受信できるメッセージボディのエンコーディングを指定する。 Accept-Encoding: gzip, deflate この例ではクライアントはgzip、またはzlibフォーマットに対応している。ただし必ずしもここで指定されたエンコーディングでメッセージボディが返ってくるとは限らない。 Accept-Encodingで指定可能なエンコーディングは、IANAがHTTP Content Coding Registryとして管理されている。 Accept-Language レスポンスの言語（人間の言語）に対する優先度を指定する。言語の指定にはIETF言語タグを用いる。書き方は他のAccept-群と変わらず。 Accept-Language: en-gb, en; q=0.8 上記の例はまずイギリス英語を要求し、利用できない場合はその他の英語を要求する。 Accept-Ranges Acceptで始まる他のヘッダフィールドと違いレスポンスヘッダである。現在の仕様では2つの指定方法しかない。 Age リソースの推定経過時間を表示するレスポンスヘッダ。キャッシュサーバーはAgeヘッダの値からキャッシュしたリソースが有効かどうかを判定する。 Allow Authentication-info ユーザ認証のやりとりの最後で用いられる、成功したレスポンスのサーバが含めることの出来るレスポンスヘッダ。 Authorization サーバに対するクライアント自身の認証を行うことが出来る。 Cache-Control キャッシングの動作を指定するためのマスターヘッダ。 Connection 接続に対するオプションを指定する。その値には以下が使用される。keep-alive 持続的接続を行う。 close 持続的接続を行わない。 upgrade 他のプロトコルへのアップグレードを希望する。 Content-Encoding Content-Language リソースの表現に用いられる言語の明示に使われる。言語の指定はAccept-Languageヘッダと同じ。 Content-Length Content-Location Content-MD5 メッセージボディが変更されず宛先に届いたことの保証に用いる。MD5によるハッシュ値をヘッダー値に記載する。ただし悪意の改ざんに対しては当然MD5も改ざんされるのであまり機能はしない。どちらかといえば偶発的な変化が生じていないことの保証をしている。RFC 7231で廃止された。 Content-Range ダウンロードの再開に用いられる。 Content-Type 「メディアタイプ」も参照 メッセージボディに含まれるオブジェクトタイプを示す。次の例はリソースがテキストファイル、文字セットはISO-8859-4を使用していることを示している。 Content-Type: text/plain; Charset=ISO-8859-4 Cookie 詳細は「HTTP cookie」を参照 クライアントがHTTP状態管理を望む場合にサーバから受け取ったクッキーを以後のリクエストに次の例のようなヘッダを付加する。 Cookie: $Version="1"; NAME="VALUE"; $Path="/shopping"; $domain="www.shop.com"+ $Port="80" $VersionはHTTPのバージョン、NAMEはクッキーの名前である。$から始まるクッキー名は使用が禁止されている。 Cookie2 基本的にCookieヘッダとCookie2ヘッダは別物である。 Date サーバがメッセージを生成した日時を示す。リソースの更新日時を示すLast-Modifiedヘッダとは別である。 HTTP/1.1では次のような形式を用いる。これはRFC 7231の7.1.1.1. Date/Time Formatsで定義されている。HTTP/1.1の以前の版であるRFC 2616では、日時の形式の定義にRFC 1123を参照していた（内容は同等である）。 Date: Sun, 06, Nov 1994 08:49:37 GMT HTTP仕様ではレスポンスにDateヘッダを含めることを求めている。ただしレスポンスのステータスがサーバエラーの場合にはDateヘッダは返らない。 ETag 主にキャッシングのパフォーマンスを向上する目的で使われる。 Expect サーバに対して特定の動作の期待を知らせる。用途としてはクライアントがサーバに対して100 Continueステータスを返すことを期待する場合に使われる。 Expect: 100-continue サーバが期待に応じられない場合は417 Expectation Failedを返す。クライアントがいくつかのプロキシ経由で通信している場合、各プロキシサーバはExpectヘッダの一切の修正を許されない。 Expires オブジェクトの有効期限を示す。このヘッダで指定された日時までキャッシュはレスポンスのコピーを保持し、リクエストに対するレスポンスとして返すことができる。サーバがオブジェクトのキャッシュを望まない場合にはExpiresヘッダに過去の日時を設定することが多い。仕様では1年以上先の日時は設定できない。 Expires: Thu, 28 Aug 2010 16:00:00 GMT Cache-Controlヘッダのmax-ageディレクティブはExpiresヘッダより優先されるため注意が必要である。 From リクエストを発行したユーザを特定することが出来る。1990年代では電子メールアドレスを設定することが多かったが、迷惑メールの問題もあり現在では殆ど使われていない。 From: user@example.com Host 主にレンタルサーバのサポートを目的としてHTTP/1.1で導入された。現在ではHostヘッダを利用できない場合、レンタルサーバのWebサイトとまともな通信ができないと言ってよい（詳細はHTTP#歴史を参照）。 If-Match ETagが一致した場合のみ、メソッドを実行するようにサーバに要求する。例えばウィキペディアを編集する際、記事のソースを取得し、書き換える際の間に別のユーザが既に編集していないかを判断するときなどに用いられる。「if文」も参照 利用者：AがHTTPの記事を取得。ETagは1234。 利用者：BがHTTPの記事を取得。ETagは1234。 利用者：AがHTTPのETagを再度取得。先ほど取得したETag: 1234と現在のETag: 1234が一致。 利用者：AがHTTPの記事を編集。ETagは1256になる。 利用者：BがHTTPのETagを再度取得。先ほど取得したETagと現在のETagはマッチせず。 サーバは利用者：Bの書き込みを拒否。 If-Modified-Since 指定日時以降にオブジェクトが変更されている場合のみ、メソッドを実行するようにサーバに要求する。通信量の削減に効果がある。 If-None-Match If-Matchの逆で、ETagが一致しない場合のみの実行を要求する。 If-Range クライアントがキャッシュにオブジェクトの一部分を持っている場合にパフォーマンスを向上できる。 If-Unmodified-Since If-Modified-Sinceの逆で、指定時刻以降に変更がない場合のみの実行を要求する。 Last-Modified レスポンスでオブジェクトの最終更新日時を示す。リクエスト時のIf-Modified-Sinceヘッダと組み合わせることで、効率的な通信が可能になる。 Location サーバがクライアントにリダイレクト先URLを知らせる際に用いられる。一般的にステータスコードが3xx代のレスポンスと共に使われるが201 Createdのレスポンスでも使うことができる。Content-Locationヘッダと名前が似ているが全く関係のない別のヘッダであるため注意。 Max-Forwards プロキシサーバなどを経由する際の最大ホップ数を指定する。二重ループなどでサーバから応答が得られない場合の問題解決の際、OPTIONメソッドやTRACEメソッドと共に用いられる。