7. レスポンスヘッダーフィールド (Response Header Fields)
レスポンスヘッダーフィールドは、サーバーがステータス行に配置されているもの以外のレスポンスに関する追加情報を渡すことを可能にします。これらのヘッダーフィールドは、サーバー、ターゲットリソースへのさらなるアクセス、または関連リソースに関する情報を提供します。
各レスポンスヘッダーフィールドには定義された意味がありますが、一般的に、正確なセマンティクスはリクエストメソッドおよび/またはレスポンスステータスコードのセマンティクスによってさらに洗練される可能性があります。
7.1. 制御データ (Control Data)
レスポンスヘッダーフィールドは、ステータスコードを補完する制御データを提供し、キャッシングを指示し、またはクライアントに次の行き先を指示することができます。
7.1.1. 発信日付 (Origination Date)
7.1.1.1. Date
"Date"ヘッダーフィールドは、メッセージが発信された日時を表し、[RFC5322]のセクション3.6.1で定義されている発信日付フィールド（orig-date）と同じセマンティクスを持ちます。フィールド値はHTTP-dateであり、[RFC7231]のセクション7.1.1.1で定義されています。
Date = HTTP-date
例：
Date: Tue, 15 Nov 1994 08:12:31 GMT
Dateヘッダーフィールドが生成される場合、送信者はそのフィールド値をメッセージ生成の日時の最良の利用可能な近似値として生成すべきです(SHOULD)。理論的には、日付はペイロードが生成される直前の瞬間を表すべきです。実際には、日付はメッセージ発信中の任意の時点で生成できます。
オリジンサーバーは、協定世界時(UTC)の現在のインスタンスの合理的な近似値を提供できる時計を持っていない場合、Dateヘッダーフィールドを送信してはなりません(MUST NOT)。オリジンサーバーは、レスポンスが1xx(情報)または5xx(サーバーエラー)クラスのステータスコードである場合、Dateヘッダーフィールドを送信してもよいです(MAY)。オリジンサーバーは、他のすべての場合にDateヘッダーフィールドを送信しなければなりません(MUST)。
時計を持つ受信者は、Dateヘッダーフィールドのないレスポンスメッセージを受信した場合、それを受信した時刻を記録し、メッセージがキャッシュされるか下流に転送される場合は、対応するDateヘッダーフィールドをメッセージのヘッダーセクションに追加しなければなりません(MUST)。
ユーザーエージェントは、リクエストでDateヘッダーフィールドを送信してもよいです(MAY)が、サーバーに有用な情報を伝えると信じられない限り、通常は送信しません。例えば、HTTPのカスタムアプリケーションは、サーバーがユーザーエージェントとサーバーの時計間の差異に基づいてユーザーのリクエストの解釈を調整することが期待される場合、Dateを伝えることがあります。
7.1.1.2. HTTP-date
HTTPアプリケーションは、歴史的に日付/タイムスタンプの表現に3つの異なる形式を許可してきました:
Sun, 06 Nov 1994 08:49:37 GMT ; IMF-fixdate
Sunday, 06-Nov-94 08:49:37 GMT ; 廃止されたRFC 850形式
Sun Nov 6 08:49:37 1994 ; ANSI CのascTime()形式
最初の形式はインターネット標準として推奨され、RFC5322で定義された固定長サブセットを表します。2番目の形式は一般的に使用されていますが、廃止されたRFC 850 [RFC0850]日付形式に基づいており、4桁の年がありません。日付値を解析するHTTP/1.1クライアントとサーバーは、3つの形式すべてを受け入れなければなりません(MUST)(HTTP/1.0との互換性のため)が、ヘッダーフィールドでHTTP-date値を表すためにIMF-fixdate形式のみを生成しなければなりません(MUST)。
注: 2桁の年を使用するrfc850-date形式のタイムスタンプ値の受信者は、将来50年以上先に見えるタイムスタンプを、同じ下2桁を持つ過去の最近の年を表すものとして解釈しなければなりません(MUST)。
HTTP-date値は、時間を協定世界時(UTC)のインスタンスとして表します。最初の2つの形式は、UTCの前身であるグリニッジ標準時の3文字の略語"GMT"によってUTCを示します。asctime形式の値はUTCであると仮定されます。ローカルクロックからHTTP-date値を生成する送信者は、NTP([RFC5905])または類似のプロトコルを使用して、そのクロックをUTCに同期させるべきです(ought to)。
推奨形式:
HTTP-date = IMF-fixdate / obs-date
IMF-fixdate = day-name "," SP date1 SP time-of-day SP GMT
; 固定長/ゾーン/大文字小文字の形式のサブセット
; [RFC5322]のセクション3.3を参照
day-name = %x4D.6F.6E ; "Mon"、大文字小文字を区別
/ %x54.75.65 ; "Tue"、大文字小文字を区別
/ %x57.65.64 ; "Wed"、大文字小文字を区別
/ %x54.68.75 ; "Thu"、大文字小文字を区別
/ %x46.72.69 ; "Fri"、大文字小文字を区別
/ %x53.61.74 ; "Sat"、大文字小文字を区別
/ %x53.75.6E ; "Sun"、大文字小文字を区別
date1 = day SP month SP year
; 例: 02 Jun 1982
day = 2DIGIT
month = %x4A.61.6E ; "Jan"、大文字小文字を区別
/ %x46.65.62 ; "Feb"、大文字小文字を区別
/ %x4D.61.72 ; "Mar"、大文字小文字を区別
/ %x41.70.72 ; "Apr"、大文字小文字を区別
/ %x4D.61.79 ; "May"、大文字小文字を区別
/ %x4A.75.6E ; "Jun"、大文字小文字を区別
/ %x4A.75.6C ; "Jul"、大文字小文字を区別
/ %x41.75.67 ; "Aug"、大文字小文字を区別
/ %x53.65.70 ; "Sep"、大文字小文字を区別
/ %x4F.63.74 ; "Oct"、大文字小文字を区別
/ %x4E.6F.76 ; "Nov"、大文字小文字を区別
/ %x44.65.63 ; "Dec"、大文字小文字を区別
year = 4DIGIT
GMT = %x47.4D.54 ; "GMT"、大文字小文字を区別
time-of-day = hour ":" minute ":" second
; 00:00:00 - 23:59:60 (うるう秒)
hour = 2DIGIT
minute = 2DIGIT
second = 2DIGIT
廃止された形式:
obs-date = rfc850-date / asctime-date
rfc850-date = day-name-l "," SP date2 SP time-of-day SP GMT
date2 = day "-" month "-" 2DIGIT
; 例: 02-Jun-82
day-name-l = %x4D.6F.6E.64.61.79 ; "Monday"、大文字小文字を区別
/ %x54.75.65.73.64.61.79 ; "Tuesday"、大文字小文字を区別
/ %x57.65.64.6E.65.73.64.61.79 ; "Wednesday"、大文字小文字を区別
/ %x54.68.75.72.73.64.61.79 ; "Thursday"、大文字小文字を区別
/ %x46.72.69.64.61.79 ; "Friday"、大文字小文字を区別
/ %x53.61.74.75.72.64.61.79 ; "Saturday"、大文字小文字を区別
/ %x53.75.6E.64.61.79 ; "Sunday"、大文字小文字を区別
asctime-date = day-name SP date3 SP time-of-day SP year
date3 = month SP ( 2DIGIT / ( SP 1DIGIT ))
; 例: Jun 2
HTTP-dateは大文字小文字を区別します。送信者は、文法でSPとして明示的に含まれているもの以外の追加の空白をHTTP-dateで生成してはなりません(MUST NOT)。day-name、day、month、year、time-of-dayのセマンティクスは、対応する名前を持つインターネットメッセージ形式の構成要素に対して定義されたものと同じです([RFC5322]、セクション3.3)。
7.1.2. Location
"Location"ヘッダーフィールドは、一部のレスポンスで、レスポンスに関連する特定のリソースを参照するために使用されます。関係のタイプは、リクエストメソッドとステータスコードのセマンティクスの組み合わせによって定義されます。
Location = URI-reference
フィールド値は単一のURI-referenceで構成されます。相対参照の形式([RFC3986]、セクション4.2)の場合、最終値は有効なリクエストURI([RFC7230]、セクション5.5)に対して解決することによって計算されます。
201(Created)レスポンスの場合、Location値は、リクエストによって作成された主要なリソースを識別するリソースへのURI参照です。3xx(リダイレクト)レスポンスの場合、Location値は、リクエストを自動的にリダイレクトするための優先ターゲットリソースを参照します。
3xx(リダイレクト)レスポンスで提供されたLocation値にフラグメントコンポーネントがない場合、ユーザーエージェントは、値がリクエストターゲットを生成するために使用されたURI参照のフラグメントコンポーネントを継承するかのようにリダイレクトを処理しなければなりません(MUST)(つまり、リダイレクトは元の参照のフラグメント(存在する場合)を継承します)。
Location値のフラグメント識別子が適切でない状況があります。例えば、201(Created)レスポンスのLocationヘッダーフィールドは、作成されたリソースに固有のURIを提供することになっています。
注: 一部の受信者は、有効なURI参照ではないLocationフィールドから回復しようとします。この仕様はそのような処理を義務付けたり定義したりしませんが、堅牢性のためにそれを許可します。絶対パスであるLocationフィールド値は受け入れられますが、有効なリクエストURIに対して相対的に解釈されます。
注: レスポンスのコンテンツネゴシエーションにより、Location値が有効なリクエストURIと異なる場合があります。レスポンスがキャッシュ可能な場合、キャッシュはそのLocation値を使用してレスポンスのより適切なキーを決定できます([RFC7234]のセクション4.1を参照)。
7.1.3. Retry-After
サーバーは"Retry-After"ヘッダーフィールドを送信して、ユーザーエージェントがフォローアップリクエストを行う前にどのくらい待つべきかを示します。503(Service Unavailable)レスポンスと共に送信される場合、Retry-Afterはサービスがクライアントに利用できないと予想される期間を示します。429(Too Many Requests)レスポンスと共に送信される場合、Retry-Afterはユーザーエージェントがフォローアップリクエストを行う前にどのくらい待つべきかを示します。任意の3xx(リダイレクト)レスポンスと共に送信される場合、Retry-Afterは、ユーザーエージェントがリダイレクトされたリクエストを発行する前に待つように求められる最小時間を示します。
このフィールドの値は、HTTP-dateまたはレスポンスを受信した後に遅延する秒数のいずれかです。
Retry-After = HTTP-date / delay-seconds
delay-seconds値は非負の10進整数で、秒単位の時間を表します。
delay-seconds = 1*DIGIT
その使用の2つの例:
Retry-After: Fri, 31 Dec 1999 23:59:59 GMT
Retry-After: 120
後者の例では、遅延は2分です。
7.1.4. Vary
レスポンスの"Vary"ヘッダーフィールドは、メソッドとリクエストターゲット以外に、リクエストメッセージのどの部分がこのレスポンスを選択および表現するためのオリジンサーバーのプロセスに影響を与える可能性があるかを記述します。値は、単一のアスタリスク("*")またはヘッダーフィールド名のリスト(大文字小文字を区別しない)のいずれかで構成されます。
Vary = "*" / 1#field-name
""のVaryフィールド値は、リクエストに関する何でもがレスポンス表現の選択に役割を果たす可能性があることを示し、おそらくメッセージ構文外の要素(例: クライアントのネットワークアドレス)を含みます。受信者は、リクエストをオリジンサーバーに転送せずに、このレスポンスが後続のリクエストに適しているかどうかを判断できません。プロキシは""値を持つVaryフィールドを生成してはなりません(MUST NOT)。
カンマ区切りの名前のリストで構成されるVaryフィールド値は、選択リクエストヘッダーフィールドとして知られる名前付きリクエストヘッダーフィールドが、表現の選択に役割を果たす可能性があることを示します。潜在的な選択リクエストヘッダーフィールドは、この仕様で定義されたものに限定されません。
例えば、以下を含むレスポンス:
Vary: accept-encoding, accept-language
は、オリジンサーバーが、このレスポンスのコンテンツを選択する際に、リクエストのAccept-EncodingおよびAccept-Languageフィールド(またはそれらの欠如)を決定要因として使用した可能性があることを示します。
オリジンサーバーは、2つの目的でフィールドのリストを含むVaryを送信する可能性があります:
-
キャッシュ受信者に、後続のリクエストが元のリクエストとリストされたフィールドに対して同じ値を持っていない限り、このレスポンスを使用して後続のリクエストを満たしてはならないことを通知するため([RFC7234]のセクション4.1)。言い換えれば、Varyは、新しいリクエストを保存されたキャッシュエントリに一致させるために必要なキャッシュキーを拡張します。
-
ユーザーエージェント受信者に、このレスポンスがコンテンツネゴシエーション(セクション3.4)の対象であり、リストされたヘッダーフィールドに追加のパラメータが提供された場合、後続のリクエストで異なる表現が送信される可能性があることを通知するため(プロアクティブネゴシエーション)。
オリジンサーバーは、表現を選択するためのアルゴリズムがメソッドとリクエストターゲット以外のリクエストメッセージの側面に基づいて変化する場合、Varyヘッダーフィールドを送信すべきです(SHOULD)。ただし、変動が交差できない場合、またはオリジンサーバーがキャッシュの透明性を防ぐように意図的に構成されている場合を除きます。例えば、フィールド定義([RFC7235]のセクション4.2)によってユーザー間の再利用が制約されているため、VaryでAuthorizationフィールド名を送信する必要はありません。同様に、オリジンサーバーは、完全にその制御下にある表現を選択するためにリクエストヘッダーフィールドを使用する可能性があり(例: プライベートヘッダーフィールドまたは内部リクエストメタデータを介して)、その場合、Varyでそれを宣伝する必要はありません。
7.2. 検証ヘッダーフィールド (Validator Header Fields)
検証ヘッダーフィールドは、選択された表現(セクション3)に関するメタデータを伝達します。安全なメソッドへのレスポンスでは、検証フィールドは選択された表現を記述します。状態変更メソッドへのレスポンスでは、検証フィールドは、リクエストの処理が成功した結果として以前に選択された表現を置き換えた新しい表現を記述します。
7.2.1. ETag
レスポンスの"ETag"ヘッダーフィールドは、リクエストの処理の終了時に決定された、選択された表現の現在のエンティティタグを提供します。エンティティタグは、時間の経過に伴うリソース状態の変更、同時に複数の表現が有効になるコンテンツネゴシエーション、またはその両方によって、同じリソースの複数の表現を区別するための不透明な検証子です。
ETag = entity-tag
エンティティタグの文法は[RFC7232]のセクション2.3で定義されています:
entity-tag = [ weak ] opaque-tag
weak = %x57.2F ; "W/"、大文字小文字を区別
opaque-tag = DQUOTE *etagc DQUOTE
etagc = %x21 / %x23-7E / obs-text
; 二重引用符を除くVCHAR、プラスobs-text
注: 以前、opaque-tagはquoted-string([RFC2616]、セクション3.11)として定義されていたため、一部の受信者はバックスラッシュのエスケープ解除を実行する可能性があります。したがって、サーバーはエンティティタグでバックスラッシュ文字を避けるべきです(ought to)。
エンティティタグは、弱い検証子または強い検証子のいずれかであり、デフォルトは強い検証子です。オリジンサーバーが表現のエンティティタグを提供し、そのエンティティタグの生成が強い検証子のすべての特性を満たさない場合([RFC7232]のセクション2.1)、オリジンサーバーは、その不透明な値の前に"W/"(大文字小文字を区別)を付けることによって、エンティティタグを弱いものとしてマークしなければなりません(MUST)。
送信者は、トレーラーセクション([RFC7230]のセクション4.1.2)でETagフィールドを送信してもよいです(MAY)が、これはコンテンツエンコーディングがなく、ユーザーエージェントがトレーラーセクションを受信する前にエンティティタグを計算できるレスポンスに対してのみ有用です。ETagがトレーラーセクションで送信される場合、ヘッダーセクションで送信されたETagフィールド値をオーバーライドします。
例:
ETag: "xyzzy"
ETag: W/"xyzzy"
ETag: ""
オリジンサーバーは、変更の検出が合理的かつ一貫して決定できる選択された表現に対してETagを送信すべきです(SHOULD)。条件付きリクエストおよびキャッシュの新鮮さの評価([RFC7234])でのエンティティタグの使用は、不要な転送を大幅に削減し、サービスの可用性とスケーラビリティを大幅に改善できるためです。
7.2.2. Last-Modified
レスポンスの"Last-Modified"ヘッダーフィールドは、リクエストの処理の終了時に決定された、オリジンサーバーが選択された表現が最後に変更されたと信じる日時を示すタイムスタンプを提供します。
Last-Modified = HTTP-date
その使用例:
Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT
オリジンサーバーは、最終変更日が合理的かつ一貫して決定できる選択された表現に対してLast-Modifiedを送信すべきです(SHOULD)。条件付きリクエストおよびキャッシュの新鮮さの評価([RFC7234])でのその使用は、不要な転送を大幅に削減し、サービスの可用性とスケーラビリティを大幅に改善できるためです。表現は通常、リソースインターフェイスの背後にある多くの部分の合計です。最終変更時刻は通常、それらの部分のいずれかが変更された最新の時刻になります。
オリジンサーバーは、レスポンスのDateフィールド値を生成する時刻にできるだけ近い時点で表現のLast-Modified値を取得すべきです(SHOULD)。これにより、受信者は表現の変更時刻を正確に評価できます。特に、レスポンスが生成される時刻の近くで表現が変更される場合に有効です。
時計を持つオリジンサーバー(セクション7.1.1.1で定義)は、サーバーのメッセージ発信時刻(Date)よりも後のLast-Modified日付を送信してはなりません(MUST NOT)。最終変更時刻が、オリジンサーバーの時計によれば将来のある時刻に評価される実装固有のメタデータから派生した場合、オリジンサーバーはその値をメッセージ発信日付で置き換えなければなりません(MUST)。これにより、将来の変更日付がキャッシュ検証に悪影響を与えることを防ぎます。
時計を持たないオリジンサーバーは、これらの値が時計を持つ他のシステムによってリソースに関連付けられていない限り、または値が以前にオリジンサーバーから受信されていない限り(例: バックエンドデータベースから)、レスポンスにLast-Modified値を割り当ててはなりません(MUST NOT)。
7.3. 認証チャレンジ (Authentication Challenges)
認証チャレンジは、クライアントが将来のリクエストで認証資格情報を提供するために利用可能なメカニズムを示します。
7.3.1. WWW-Authenticate
"WWW-Authenticate"ヘッダーフィールドは、ターゲットリソースに適用可能な認証スキームとパラメータを示します。
WWW-Authenticate = 1#challenge
401(Unauthorized)レスポンスを生成するサーバーは、少なくとも1つのチャレンジを含むWWW-Authenticateヘッダーフィールドを送信しなければなりません(MUST)。サーバーは、資格情報(または異なる資格情報)を提供することがレスポンスに影響を与える可能性があることを示すために、他のレスポンスメッセージでWWW-Authenticateヘッダーフィールドを生成してもよいです(MAY)。
レスポンスを転送するプロキシは、そのレスポンスのWWW-Authenticateフィールドを変更してはなりません(MUST NOT)。
ユーザーエージェントは、フィールド値の解析に特別な注意を払うことをお勧めします。複数のチャレンジが含まれている可能性があり、各チャレンジにはカンマ区切りの認証パラメータのリストが含まれている可能性があるためです。さらに、ヘッダーフィールド自体が複数回出現する可能性があります。
詳細については、[RFC7235]のセクション4.1を参照してください。
7.3.2. Proxy-Authenticate
"Proxy-Authenticate"ヘッダーフィールドは、このリクエストターゲットに対してプロキシに適用可能な認証スキームとパラメータを示す少なくとも1つのチャレンジで構成されます。プロキシは、それが生成する各407(Proxy Authentication Required)レスポンスで少なくとも1つのProxy-Authenticateヘッダーフィールドを送信しなければなりません(MUST)。
Proxy-Authenticate = 1#challenge
WWW-Authenticateとは異なり、Proxy-Authenticateヘッダーフィールドは、レスポンスチェーン上の次のアウトバウンドクライアントにのみ適用されます。これは、特定のプロキシを選択したクライアントのみが認証に必要な資格情報を持っている可能性が高いためです。ただし、大企業ネットワーク内のオフィスおよび地域キャッシングプロキシなど、同じ管理ドメイン内で複数のプロキシが使用される場合、ユーザーエージェントによって資格情報が生成され、消費されるまで階層を通過することが一般的です。したがって、このような構成では、各プロキシが同じチャレンジセットを送信するため、Proxy-Authenticateが転送されているように見えます。
詳細については、[RFC7235]のセクション4.3を参照してください。
7.4. レスポンスコンテキスト (Response Context)
以下のレスポンスヘッダーフィールドは、ステータスコードによって暗示されるもの以外のレスポンスに関する追加情報、またはレスポンスを処理するサーバーに関する情報を提供します。
7.4.1. Allow
"Allow"ヘッダーフィールドは、ターゲットリソースによってサポートされているとアドバタイズされたメソッドのセットをリストします。このフィールドの目的は、厳密に、リソースに関連付けられた有効なリクエストメソッドを受信者に通知することです。
Allow = #method
使用例:
Allow: GET, HEAD, PUT
実際に許可されたメソッドのセットは、各リクエスト時にオリジンサーバーによって定義されます。オリジンサーバーは、405(Method Not Allowed)レスポンスでAllowフィールドを生成しなければならず(MUST)、他の任意のレスポンスでそうしてもよいです(MAY)。空のAllowフィールド値は、リソースがメソッドを許可しないことを示します。これは、リソースが構成によって一時的に無効にされている場合に405レスポンスで発生する可能性があります。
プロキシは、Allowヘッダーフィールドを変更してはなりません(MUST NOT)。一般的なメッセージ処理ルールに従ってそれらを処理するために、示されたすべてのメソッドを理解する必要はありません。
7.4.2. Server
"Server"ヘッダーフィールドには、リクエストを処理するためにオリジンサーバーが使用するソフトウェアに関する情報が含まれます。これは、報告された相互運用性の問題の範囲を特定したり、特定のサーバーの制限を回避または調整するためにリクエストを調整したり、サーバーまたはオペレーティングシステムの使用に関する分析のために、クライアントによって使用されることがよくあります。オリジンサーバーは、任意のレスポンスでServerフィールドを生成してもよいです(MAY)。
Server = product *( RWS ( product / comment ) )
Serverフィールド値は、1つ以上の製品識別子で構成され、それぞれの後に0個以上のコメント([RFC7230]のセクション3.2)が続き、これらが一緒になってオリジンサーバーソフトウェアとその重要なサブプロダクトを識別します。慣例により、製品識別子は、オリジンサーバーソフトウェアの識別における重要性の降順でリストされます。各製品識別子は、[RFC7230]のセクション5.5.3で定義されているように、名前とオプションのバージョンで構成されます。
例:
Server: CERN/3.0 libwww/2.17
オリジンサーバーは、不必要に細かい詳細を含むServerフィールドを生成すべきではなく(SHOULD NOT)、第三者によるサブプロダクトの追加を制限すべきです(SHOULD)。過度に長く詳細なServerフィールド値は、レスポンスレイテンシを増加させ、攻撃者が既知のセキュリティホールを見つけて悪用することを(わずかに)容易にする可能性のある内部実装の詳細を明らかにする可能性があります。