.htaccess - mod_headers

mod_headers

以下は、mod_headers モジュールのディレクティブの一覧です。mod_headers は、HTTP リクエストのヘッダと、HTTP レスポンスのヘッダを追加、削除、変更できます。

HTTP ヘッダのカテゴリには、一般ヘッダ、リクエスト (要求) ヘッダ、レスポンス (応答) ヘッダ、要素ヘッダの 4 種類があります。一般ヘッダと要素ヘッダは、リクエストとレスポンスの両方に付きますが、リクエストヘッダはリクエストのみ、レスポンスヘッダはレスポンスのみに付きます。

HTTP ヘッダ一覧
カテゴリREQRESフィールド名一覧
一般ヘッダCache-Control, Connection, Date, Pragma, Trailer, Transfer-Encoding, Upgrade, Via, Warning
要素ヘッダAllow, Content-Encoding, Content-Language, Content-Length, Content-Location, Content-MD5, Content-Range, Content-Type, Expires, Last-Modified
要求ヘッダ×Accept, Accept-Charset, Accept-Encoding, Accept-Language, Authorization, Expect, From, Host, If-Match, If-Modified-Since, If-None-Match, If-Range, If-Unmodified-Since, Max-Forwards, Proxy-Authorization, Range, Referer, TE, User-Agent
応答ヘッダ×Accept-Ranges, Age, ETag, Location, Proxy-Authenticate, Retry-After, Server, Vary, WWW-Authenticate
一般ヘッダのフィールド名一覧
フィールド名HTTP/1.0HTTP/1.1説明
Cache-Control×キャッシュのコントロールに必要な指示や情報を表します。HTTP/1.0 では Pragma: no-cache が使用されます。
Connection[2]close[2] RFC 1945 では未定義
IETF の HTTP 1.0 ドラフト (draft-fielding-http-spec-01.txt) では定義されています。HTTP 1.1 では下位互換を保つために定義されています。
接続の持続性の情報を表します。1 回の TCP 接続で複数のコンテンツを要求することで通信パフォーマンスが向上します。Keep-Alive の場合、接続が持続します。Close の場合、レスポンス後の接続は解除されます。
DateHTTP メッセージを生成した日時を表します。RFC822形式、RFC850形式、ANSI C形式などを受け入れる必要があります。曜日と秒数は省略可能です。日付は 0 パディングでも問題ありません。年は 2 桁でも 4 桁でも問題ありませんが、4桁が推奨されています。時間帯は GMT (グリニッジ標準時) が一般的です。
Pragma関連するクライアント、プロキシ、サーバに様々な特殊情報を認識させることができます。例えば、no-cache を指定した場合は、無条件で再読み込みを行うなどです。
Trailer×送信するデータを任意の長さに分割し、全体のサイズを記述したヘッダを付加するエンコード方式 (チャンク方式) における、ヘッダの一覧を表します。
Transfer-Encoding×転送に使用されるエンコード方式を表します。HTTP/1.1 ではチャンク方式 (chunked) のみ定義されています。
Upgrade×HTTP の他に使用を推奨するプロトコルを表します。現在では HTTP/1.1 が最新ですが、将来的に HTTP/2.0 などがこのフィールド名で指定される可能性があります。
Via×メッセージがどのプロキシを経由して転送されたかを表します。このフィールドは、ネットワーク上でリクエストがループしていないかを検知するために使われます。
Warning×レスポンスに関する追加情報を表します。HTTP/1.1 では 7 つの Warning コードとメッセージが定義されています。
110 Response is Stale
111 Revalidation Failed
112 Disconnected Operation
113 Heuristic Expiration
199 Miscellaneous Warning
214 Transformation Applied
299 Miscellaneous Persistent Warning
要素ヘッダのフィールド名一覧
フィールド名HTTP/1.0HTTP/1.1説明
Allow要求する URL で指定したリソースに対して使用可能なメソッドの一覧を表します。サーバが受け入れられないメソッドを受けると、ステータスコード 405 Method Not Allowed レスポンスと、受け入れ可能なメソッドの一覧を Allowヘッダ で返します。
Content-Encodingコンテンツのエンコード方式 (Content Coding 方式) を表します。HTTP/1.1 では gzipcompressdeflateidentity (エンコードなし) が定義されています。
Content-Language×コンテンツの使用言語コードを表します。
Content-Lengthコンテンツの長さを Byte 単位で表します。Transfer-Encoding フィールドでチャンク方式 (chunked) が指定されている場合、このフィールドは使用されません。
Content-Location×コンテンツに対応する URI を表します。Location フィールドとは異なり、このフィールドはメッセージボディで返されるリソースの URI を表します。
Content-MD5×コンテンツに関するチェックデータ (128 bit の MD5 Digest を BASE64 エンコードしたもの) を表します。コンテンツが通信途中に改変されていないかを検知するために用いられます。ただし、改変されたメッセージで MD5 を求めた場合は検知できません。
Content-Range×コンテンツの一部分だけをリクエストするレンジリクエストに対するレスポンスを表します。例えば、コンテンツ全体が 1000 Byte あり、その中の 0 Byte ~ 500 Byte の部分だけを送信していることを伝えます。
Content-TypeコンテンツのMIME タイプ(Content-Type)を表します。
Expiresコンテンツの有効期限を表します。有効期限を過ぎたコンテンツはキャッシュから削除されます。
Last-Modifiedコンテンツの最終更新日時を表します。CGI で動的なデータを扱う場合は、そのデータの最終更新日時になることもあります。
要求ヘッダのフィールド名一覧
フィールド名HTTP/1.0HTTP/1.1説明
Accept×ユーザエージェントが処理できるメディアタイプと、相対的な優先度を表します。mod_negotiation モジュールも参照して下さい。
Accept-Charset×ユーザエージェントが処理できる文字セットと、相対的な優先度を表します。
Accept-Encoding×ユーザエージェントが処理できるエンコード方式と、相対的な優先度を表します。
Accept-Language×ユーザエージェントが処理できる自然言語のセットと、相対的な優先度を表します。
Authorization認証が必要なコンテンツに対するユーザエージェントの認証情報 (credentials値) を表します。関連する情報は AuthName ディレクティブを参照して下さい。
Expect×クライアントの要求に対して、サーバが受け入れ可能か確認する情報を表します。サーバが要求に対して受け入れられない場合は、HTTP ステータスコード 417 Expectation Failed を返します。HTTP/1.1 では 100-continue しか定義されていません。
Fromユーザエージェントを使用しているユーザのメールアドレスを表します。検索エンジンがロボットで探索する場合に、探索に関する問い合わせ先のメールアドレスを通知する際などに利用されます。ただし、セキュリティ上の観点から実装されている例は多くありません。
Host×リクエスト先のサーバ名とポート番号を表します。サーバが 1 つの IP アドレスで複数の URL を持つ仮想ホストをサポートしている場合、このフィールドで指定したサーバ名からどのサーバにアクセスするかを決定します。HTTP/1.1 で唯一の必須ヘッダフィールドです。
If-Match×サーバ上のリソースを特定するための ETag を表します。サーバは指定した ETag にマッチした場合のみ、リクエストを受け付けます。ETag がマッチしない場合、HTTP ステータスコード 412 Precondition Failed を返します。ただし、このフィールドを使用する場合は、弱い ETag を使用できません。
If-Modified-Sinceサーバ上のリソースを特定するための最終更新日時を表します。サーバは指定した最終更新日時より、リソースの最終更新日時が新しい場合のみ、リクエストを受け付けます。指定した最終更新日時から、リソースが更新されていなければ HTTP ステータスコード 304 Not Modified を返します。
If-None-Match×If-Match フィールドの逆の処理を行います。
If-Range×クライアントがリソースの一部を保持しており、それ以外の残りを最新の場合のみレンジリクエストにより取得します。残りのリソースが最新であるかは、ETag、または最終更新日時を使用して確認します。ETag、または最終更新日時がマッチしない場合は、リソース全体を返します。このフィールドは、Range フィールドと組み合わせて使用します。
If-Unmodified-Since×If-Modified-Since フィールドの逆の処理を行います。
Max-Forwards×HTTP メソッドの TRACE、または OPTIONS において、プロキシサーバの最大ホップ数を表します。プロキシサーバは、この値を -1 して、次のプロキシサーバに転送します。この値が 0 になると、プロキシサーバは最後の受信者としてレスポンスを返します。HTTP メソッドについては <Limit> ディレクティブを参照して下さい。
Proxy-Authorization×プロキシサーバとクライアント間で認証が必要であることを表します。Authorization フィールドがサーバとクライアント間であることに対して、このフィールドはプロキシサーバとクライアント間となります。
Range×リソースの一部分だけを取得する "レンジリクエスト" を行うときの指定範囲を表します。Range フィールド付きのリクエストを受け取ったサーバは、リクエストを処理するとき、HTTP ステータスコード 206 Partial Content レスポンスを返します。Range フィールドを処理できない場合は、HTTP ステータスコード 200 OK として、リソース全体を返します。
Refererリクエストの発生元のリソースの URI を表します。
TE×ユーザエージェントが処理できる拡張転送コーディング方式 (Transfer Coding方式)と、相対的な優先度を表します。拡張転送コーディングの指定以外に、チャンク方式で転送する際の trailer フィールドを解釈可能かどうかをサーバに確認することもできます。
User-Agentリクエストを生成したユーザーエージェントの種別、バージョン情報、プラットフォームなどの情報を表します。フォーマットは特に規定はありません。また、プロキシ経由のリクエストには、プロキシサーバの名前なども付け加えられる可能性があります。
要求ヘッダのフィールド名一覧
フィールド名HTTP/1.0HTTP/1.1説明
Accept-Ranges×リソースの一部だけ指定して取得できる "レンジリクエスト" を受け付けられるかどうかを表します。受付可能な場合は bytes、受付不可能な場合は none を表します。
Age×エンティティが生成されてからの予測経過時間を秒数で表します。レスポンスを返したサーバがキャッシュサーバーの場合、キャッシュしたレスポンスが再検証されたときから検証した時間になります。プロキシがレスポンスを生成するときには、このフィールドは必須となります。
ETag×リソースを一意に識別するための文字列を表します。ETag は、ファイル識別子、サイズ、更新時刻などの情報から計算されます。ETag は、"強い ETag""弱い ETag" があります。強い ETag は、リソースが 1 Byte も変わらず、また Content-Language などのヘッダも変わっていないことを示します。弱い ETag は、2つのリソースは基本的に同じで実用的にはキャッシュされたものを代用できることを示します。ただし、1 Byte も変わらず同じであることは保証されず、部分リクエストのバリデーションには使えません。
Locationリソースが移動した場合など、ブラウザが要求した URL とは別の飛ばしたい URL を表します。基本的に、HTTP ステータス 3xx Redirection に対して、リダイレクト先の URL を指定します。
Proxy-Authenticate×プロキシサーバとクライアント間の認証情報を表します。
Retry-After×クライアントがどれくらい後にリクエストを再試行すべきかを秒数で表します。HTTP ステータスコード 503 Service Unavailable、または 3xx Redirect に対して使われます。
ServerHTTPサーバーのソフトウェアが何かを表します。
Vary×Accept、Accept-Charset、Accept-Language など、サーバ主導型ネゴシエーション (Server Drivenネゴシエーション) で使用されたヘッダ情報を表します。このフィールドは、キャッシュの有効性を判断するために使用されます。例えば、レスポンスに Accept-Language が含まれている場合、クライアント側には Accept-Language: ja のコンテンツがキャッシュされている可能性があることを示します。そのため、Accept-Language: en で要求すると別のコンテンツが返却される可能性があることを通知できます。
WWW-Authenticate×認証が必要であることを表します。認証が必要なリソースが Basic 認証、または Digest 認証であるかを示します。また、指定した認証が必要なリソースを識別するための文字列である "realm" も付与されます。

mod_header のディレクティブはサーバ設定のどこにでも書くことができます。影響する範囲を <FilesMatch> などの設定用セクションで限定できます。ただし、設定用セクション内に記述されたディレクティブは、設定ファイル内に記述されたディレクティブより後に処理されます。以下の例では、2 つのディレクティブが設定ファイル内に書かれているため、appendunset の順で処理されます。

# append, unset の順で処理される例
Header append MirrorID "mirror 12"
Header unset MirrorID
append, unset の順で処理される例

上記の例では、上から順番に処理されるため、最終的に MirrorID は unset が処理を行います。そのため、応答ヘッダには MirrorID は現れません。しかし、設定用セクションを使用した場合、処理順が変わります。

# unset, append の順で処理される例
<FilesMatch "\.(html)$">
  Header append MirrorID "mirror 12"
</FilesMatch>
Header unset MirrorID
unset, append の順で処理される例

上記の例では、設定ファイル内に書かれた unset、設定用セクションに書かれた append の順で処理されるため、最終的に応答ヘッダには "MirrorID: mirror 12" が現れます。

Header ディレクティブ

Header ディレクティブは、HTTP 応答ヘッダを置換、追加、削除できます。ヘッダはコンテンツハンドラや、出力フィルタが実行された直後に実行され、出力されるヘッダを変更できます。以下は、本ディレクティブの構文になります。

# Header ディレクティブの構文
Header [condition] 
       set|append|add|unset|echo header [value] 
       [early|env=[!]variable]
Header ディレクティブの構文

オプションの conditiononsuccessalways のどちらかを指定できます。これは内部ヘッダテーブルのどれを操作するかを決定します。onsuccess は 2xx ステータスコード、always は全てのステータスコード (2xx を含む) の意味になります。

Header ディレクティブの 2 番目の引数となる setappendaddunsetecho を、以下の表で説明します。

Header ディレクティブの 2 番目の引数一覧
引数名説明
set応答ヘッダを設定します。同じ名前のヘッダが存在する場合はそれを置き換えます。value にはフォーマット文字列を指定することもできます。
append応答ヘッダの既に存在する同じ名前のヘッダに追加します。新しい値が既存のヘッダに追加されるときには、既存のヘッダの後にコンマで区切られて追加されます。これはヘッダに複数の値を指定するときの HTTP の標準の方法です。
addヘッダが既に存在しているときでさえも、応答ヘッダを既存のヘッダに追加します。これにより、2 つ以上のヘッダの名前が同じになることがあります。その結果、想定できないことが起こる可能性がありますので、一般的には append の使用が推奨されます。
unsetもし指定された名前の応答ヘッダが存在していれば、削除されます。同じ名前のヘッダが複数あるときは、すべて削除されます。unset を指定する場合は value は設定できません。
echo指定されたものと同じ名前のリクエストヘッダを応答ヘッダでそのまま返します。header には正規表現も指定できます。echo を指定する場合は value は設定できません。

上記の引数の後にはヘッダ名 (header) が続きます。構文には表現されていませんが、ヘッダ名の最後には : を含めることもできます。無くても問題ありません。setappendaddunsetecho は、大文字小文字は区別されません。ただし、echoheader は大文字小文字を区別するため、正規表現で表すときには注意が必要です。

# Header ディレクティブを使ってオリジナルのヘッダを追加する例
Header add MyHeader "Hello."
Header ディレクティブを使ってオリジナルのヘッダを追加する例
# 実行結果
% curl -I https://murashun.jp/index.html                                                                                            
HTTP/1.1 200 OK
MyHeader: Hello.
Header ディレクティブを使ってオリジナルのヘッダを追加する例

addappendset では value を 3 番目の引数として指定します。value に空白がある場合は " で囲む必要があります。value は文字だけの文字列、フォーマット指示子を含む文字列、もしくは両方を組み合わせた文字列を指定できます。value は以下のフォーマット指示子をサポートします。

Header ディレクティブの 3 番目の引数 (value) のフォーマット指示子一覧
フォーマット説明
%%パーセント記号を表します。(% を % でエスケープしている)
%tリクエストを受け取った時刻を、Universal Coordinated Time での始まりの時刻 (Jan. 1, 1970) から経過した時間をマイクロ秒として表します。値の最初には t= が付加されます。
%Dリクエストを受け取った時刻と、ヘッダを送り出した時間との差をマイクロ秒として表します。これは、リクエストが存在していた期間を表します。値の最初には D= が付加されます。
%{FOOBAR}e環境変数 FOOBAR の値です。
%{FOOBAR}smod_ssl が有効な場合、SSL 環境変数 FOOBAR の内容

以下の例では、リクエストを受け付けた時刻 (%t)、リクエストを処理した時間 (%D)を応答レスポンスに MyHeader というヘッダ名で追加します。このヘッダはクライアントがサーバの負荷を直観的に知るためや、クライアントとサーバ間のボトルネックを調べるために使うことができます。

# Header ディレクティブを使ってオリジナルのヘッダを追加する例
Header add MyHeader "%t %D"
サーバの応答時間を調べる例
# 実行結果
% curl -I https://murashun.jp/index.html
HTTP/1.1 200 OK
Date: Sat, 05 Sep 2015 01:28:07 GMT
MyHeader: t=1441416487862010 D=1053
サーバの応答時間を調べる例

以下の例では、SetEnv ディレクティブを使用して環境変数を設定している例です。

# Header ディレクティブを使ってオリジナルのヘッダを追加する例
SetEnv SPECIAL_PATH /foo/bin
Header add MyHeader "%{SPECIAL_PATH}e"
環境変数を設定する例
# 実行結果
% curl -I https://murashun.jp/index.html                                                                                            
HTTP/1.1 200 OK
MyHeader: /foo/bin
環境変数を設定する例

RequestHeader ディレクティブ

RequestHeader ディレクティブは、HTTP 要求ヘッダを置換、追加、削除できます。ヘッダはコンテンツハンドラが実行される直前に実行され、入力されるヘッダを変更することが可能になっています。以下は、本ディレクティブの構文になります。

# Header ディレクティブの構文
RequestHeader set|append|add|unset header [value]
              [early|env=[!]variable]
Header ディレクティブの構文
RequestHeader ディレクティブの 2 番目の引数一覧
引数名説明
set要求ヘッダを設定します。同じ名前のヘッダが存在する場合はそれを置き換えます。
append要求ヘッダの既に存在する同じ名前のヘッダに追加します。新しい値が既存のヘッダに追加されるときには、既存のヘッダの後にコンマで区切られて追加されます。これはヘッダに複数の値を指定するときの HTTP の標準の方法です。
addヘッダが既に存在しているときでさえも、要求ヘッダを既存のヘッダに追加します。これにより、2 つ以上のヘッダの名前が同じになることがあります。その結果、想定できないことが起こる可能性がありますので、一般的には append の使用が推奨されます
unsetもし指定された名前の要求ヘッダが存在していれば、削除されます。同じ名前のヘッダが複数あるときは、すべて削除されます。unset を指定する場合は value は設定できません。

本ディレクティブの引数である headervalue については、Header ディレクティブと同じですので、 詳細はそちらを参照して下さい。

関連記事

Category:
プログラミング
公開日:
更新日:
Pageviews:
21
Shares:
0
Tag:
.htaccess
Apache
HTTP
Server