ヒントを示すためのHTTPステータスコード

概要

本メモは、クライアントが最終レスポンスを処理するための準備を行うのに役立つヒントを伝達するために使用できる情報的なHTTPステータスコードを導入する。

このメモの状態

本書はインターネット標準トラックの仕様ではなく、検討、実験的実装、および評価のために公開される。

本書はインターネットコミュニティのための実験的プロトコルを定義するものである。本書はインターネット技術タスクフォース（IETF）の成果であり、IETFコミュニティの合意を表すものである。公開レビューを経てインターネット技術運営グループ（IESG）により公開が承認された。IESGにより承認された全ての文書がインターネット標準の候補となるわけではない。詳細は RFC 7841 のセクション2 を参照のこと。

本文書の現在の状態、訂正（errata）、およびフィードバック提供方法に関する情報は https://www.rfc-editor.org/info/rfc8297 で入手できる。

Copyright Notice

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

1. 導入
- 1.1. 表記規約
2. HTTP Status Code 103: Early Hints
3. セキュリティに関する考慮事項
4. IANAに関する考慮事項
5. 参考文献
- 5.1. 規範的参考文献
- 5.2. 情報的参考文献
Appendix A. 謝辞
著者の連絡先

1. 導入

HTTPレスポンスに、例えばウェブブラウザでHTMLをレンダリングする前に取得する必要のある外部リソースへのリンクが含まれることは一般的である。こうしたリンクをクライアントにできるだけ早く提供することは、知覚される待ち時間を最小化するのに役立つ。

“preload” [Preload] リンク関係は、HTTPレスポンスのLinkヘッダーフィールドでそのようなリンクを伝達するために使用できる。しかし、オリジンサーバーがリクエストを受け取った直後に最終レスポンスのヘッダーブロックを即座に生成できるとは限らない。例えば、オリジンサーバーがリクエストを遠隔地で動作する上流のHTTPサーバーに委託することがあるか、あるいはステータスコードがデータベースクエリの結果に依存する場合がある。

ここでのジレンマは、オリジンサーバーがリクエストを受け取ったらできるだけ早くいくつかのヘッダーフィールドを送ることが望ましい場合でも、最終HTTPレスポンスのステータスコードと完全なヘッダーフィールドが確定するまでそれを行えない、という点である。

HTTP/2の[RFC7540]サーバープッシュはリソースの配信を高速化できるが、サーバーが権威を持つリソースに限られるという制約がある。サーバープッシュのもう一つの制限は、クライアントがそのレスポンスをキャッシュしているかどうかにかかわらずレスポンスが送信される点である。最悪の場合にはサーバープッシュより1往復多くなる代償を払うものの、Linkヘッダーフィールドを適時に配信することはより柔軟であり、帯域をあまり消費しない場合もある。

本メモは、最終レスポンスに含まれる可能性が高いヘッダーフィールドを含む情報的なレスポンス（[RFC7231]、Section 6.2）を送信するためのステータスコードを定義する。サーバーは、いくつかのヘッダーフィールドを含む情報的レスポンスを送信してクライアントが最終レスポンスの処理準備を開始できるようにし、その後に最終レスポンスを生成するための時間のかかる処理を行うことができる。情報的レスポンスは、オリジンサーバーがキャッシングの仲介者でHTTP/2サーバープッシュをトリガーするためにも使用できる。

1.1. 表記規約

本書中のキーワード「MUST」「MUST NOT」「REQUIRED」「SHALL」「SHALL NOT」「SHOULD」「SHOULD NOT」「RECOMMENDED」「NOT RECOMMENDED」「MAY」および「OPTIONAL」は、すべて大文字で現れる場合に限り、BCP 14 の[RFC2119]および[RFC8174]に記載されているとおりに解釈されるものとする。

2. HTTP Status Code 103: Early Hints

103 (Early Hints) 情報的ステータスコードは、サーバーが情報的レスポンスに含まれるヘッダーフィールドを最終レスポンスにも含める可能性が高いことをクライアントに示す。

通常、サーバーは103 (Early Hints) レスポンスで送信したヘッダーフィールドを最終レスポンスにも含めるだろう。しかし、最終レスポンスが送信される前にこれらのヘッダーフィールドが正しくないと判明する場合など、そうすることが望ましくないケースもあり得る。

クライアントは最終レスポンスを待つ間に、103 (Early Hints) レスポンスに含まれるヘッダーフィールドを推測的に評価することができる。例えば、クライアントはLinkヘッダーフィールドの値にrelation type "preload" が含まれていることを認識して、対象リソースの取得を開始するかもしれない。ただし、これらのヘッダーフィールドはクライアントへのヒントに過ぎず、最終レスポンスのヘッダーフィールドに取って代わるものではない。

パフォーマンス最適化を除き、103 (Early Hints) レスポンスのヘッダーフィールドの評価は最終レスポンスの処理方法に影響を与えてはならない。クライアントは103 (Early Hints) レスポンスのヘッダーフィールドを、それらが情報的レスポンス自体に適用されるかのように解釈してはならない（例えば、103 レスポンスに関するメタデータとして解釈するなど）。

サーバーは、最終レスポンスに見つかることが予想されるヘッダーフィールドの一部のみを示すために103 (Early Hints) レスポンスを使用してもよい。クライアントは、103 (Early Hints) レスポンスにヘッダーフィールドが存在しないことをもって、そのヘッダーフィールドが最終レスポンスに含まれる可能性が低いと推測すべきではない。

以下の例は、103 (Early Hints) レスポンスを含む典型的なメッセージ交換を示している。

クライアントからのリクエスト：

  GET / HTTP/1.1
  Host: example.com

サーバーからのレスポンス：

  HTTP/1.1 103 Early Hints
  Link: </style.css>; rel=preload; as=style
  Link: </script.js>; rel=preload; as=script

  HTTP/1.1 200 OK
  Date: Fri, 26 May 2017 10:02:11 GMT
  Content-Length: 1234
  Content-Type: text/html; charset=utf-8
  Link: </style.css>; rel=preload; as=style
  Link: </script.js>; rel=preload; as=script

  <!doctype html>
  [... rest of the response body is omitted from the example ...]

任意の情報的レスポンスと同様に、サーバーは最終レスポンスを送る前に複数の103 (Early Hints) レスポンスを送出することがある。例えば、キャッシング仲介者が古いキャッシュレスポンスのヘッダーフィールドに基づいて103レスポンスを生成し、それからオリジンサーバーからの再検証要求に対して送られた103レスポンスと最終レスポンスを転送する場合などである。

サーバーは、処理中に新しい情報が利用可能になると追加のヘッダーフィールドを含む複数の103 (Early Hints) レスポンスを送出してもよい。既に送出したフィールドを繰り返す必要はないが、除外する必要もない。クライアントは、複数の103 (Early Hints) レスポンスで受け取ったヘッダーフィールドの任意の組み合わせを、最終レスポンスで予想されるヘッダーフィールドの一覧を予測するために考慮できる。

以下の例は、サーバーが送出する一連のレスポンスを示す。例ではサーバーが2つの103 (Early Hints) レスポンスを使用して、最終レスポンスに3つのLinkヘッダーフィールドが送られる可能性があることをクライアントに通知している。3つのうち2つは最終レスポンスに含まれている。残りの1つは別の値を含むLinkヘッダーフィールドに置き換えられている。

  HTTP/1.1 103 Early Hints
  Link: </main.css>; rel=preload; as=style

  HTTP/1.1 103 Early Hints
  Link: </style.css>; rel=preload; as=style
  Link: </script.js>; rel=preload; as=script

  HTTP/1.1 200 OK
  Date: Fri, 26 May 2017 10:02:11 GMT
  Content-Length: 1234
  Content-Type: text/html; charset=utf-8
  Link: </main.css>; rel=preload; as=style
  Link: </newstyle.css>; rel=preload; as=style
  Link: </script.js>; rel=preload; as=script

  <!doctype html>
  [... rest of the response body is omitted from the example ...]

3. セキュリティに関する考慮事項

情報的レスポンスはExpectヘッダーフィールドを含まないリクエストへの応答として使われることが稀であるため、一部のクライアントは103 (Early Hints) レスポンスの取り扱いに問題を抱える可能性がある（[RFC7231]、Section 5.1.1）。

特に、情報的レスポンスを誤って最終レスポンスとして扱うHTTP/1.1クライアントは、同一接続上で後続のリクエストに対して受信するすべてのレスポンスを最終レスポンスの一部と見なす可能性がある。そのような挙動は、クライアントが異なるオリジンへのリクエストを単一の持続接続に多重化している場合に、クロスオリジン情報漏えいの脆弱性を生じさせるかもしれない。

したがって、サーバーは情報的レスポンスを正しく処理できることが分かっているクライアントでない限り、HTTP/1.1 上で103 (Early Hints) レスポンスを送信することを控える場合がある。

HTTP/2クライアントは、レスポンスヘッダーフィールドの処理がレスポンス本文の終了判定方法に影響を与えないため、フレーミング誤りの影響を受けにくい。