要約

  • 103 Early Hintsが示すのは、最終応答に現れる可能性が高いフィールドである。preload のような取り消し可能な準備には使えるが、最終フィールドの代わりにはならず、後から削除や差し替えも起こり得る。
  • 利用側は、外れたときの損失を自分で制限しなければならない。早期ヒントは送信元の真正性、認可、同意、キャッシュ可否を証明せず、不可逆な処理を許可するものでもない。

Early Hintsを理解するには、当たった例より外れた例を見るほうがよい。RFC 8297には、サーバーが二つの103応答で合計三つのリンクを予告し、最終応答では二つを残し、一つを別のリンクへ置き換える例がある。

これは例外処理ではない。仕組みの中心そのものだ。

最終応答が完全に決まっているなら、サーバーはそれをすぐ送ればよい。103が役立つのは、まだ計算や問い合わせが残っている一方、必要になりそうな資源だけは見えているときである。クライアントはその不確実さを引き受ける代わりに、待ち時間を準備時間へ変えられる。

したがって、103を高速な命令として読むと設計が逆転する。予測だから早く出せるのであり、早く出たから決定ではない。

一つの要求に、途中経過と最終結果がある

RFC 9110によれば、一つのHTTP要求には、0個以上の1xx暫定応答が先行し、その後に1個の非1xx最終応答が来る。1xxはフィールド部の終端で終わり、内容もトレーラーも持たない。クライアントは予期していない場合でも複数の1xxを解析できなければならないが、ユーザーエージェントは予期しない1xxを無視してよい。

103はこの暫定領域に置かれる。そこに含まれるフィールドを、サーバーが最終応答でも送る「可能性が高い」と知らせる。通常は繰り返されるものの、後続処理で誤りや不都合が分かれば、最終応答から消えてもよい。

RFC 8297は境界を明記している。早期フィールドはヒントにすぎず、最終応答のフィールドを置き換えない。また性能最適化を除き、その評価が最終応答の処理方法に影響してはならない。フィールドを103自体のメタデータとして扱うことも禁じられる。

このため、実装内部で早期フィールドを「仮の最終ヘッダー」と呼ぶのは危険だ。名前が、あとで確定印を押すだけの状態だと誤解させる。実際には複数の暫定フィールド群が時系列で届き、その後に別格の最終フィールド群が届く。

記録もその構造を保つべきである。どの103が何を予測し、どの処理を開始し、最終応答で何が残ったかを追える形なら、性能と誤予測の両方を検証できる。

書かれていないことは否定ではない

サーバーは、最終応答に入ると予想するフィールドの一部だけを103に載せられる。新しい情報が得られるたびに複数の103を送ってもよく、前に送ったフィールドを毎回繰り返す必要もない。クライアントは受信した組み合わせを予測に使える。

ただし、存在しないフィールドについて「最終応答にも入らないらしい」と推測してはならない。103は正の情報を部分的に流す経路であり、沈黙による否定を表す経路ではない。

この点はセキュリティフィールドや認証要求、キャッシュ指示で特に重要になる。最初の103に見当たらないからといって、最終応答を待たずに制約を緩める根拠にはならない。

早期にすべてを列挙させれば、この問題を消せるようにも見える。しかし、それではサーバーが最終判断を終えるまで待つ必要があり、時間差を利用する目的が失われる。部分性は欠陥ではなく、扱うべき前提である。

preloadが許すのは限定的な先回り

代表例では Link フィールドに preload 関係が入る。Web Linkingの関係型は、ある文脈と対象の関係を表す。対応するクライアントは、最終的な表現を処理する前に対象を取得すると有益かもしれないと判断できる。

関係型は命令動詞ではない。すべての受信者が同じ要求を発行する義務はない。通信量に制約のある端末は無視できる。ブラウザーは対象種別を限定できる。企業環境は別オリジンへの投機取得を止められる。共通なのは意味であり、支出判断ではない。

先行取得は現実の副作用を持つ。帯域を使い、接続を占有し、別のサービスへ接触し、キャッシュ状態を変え、特定のURLへの関心を外部へ示す。通常の規則次第では資格情報も関係する。フィールドが早く来たからといって、オリジン、資格情報、要求モード、サイズ上限などの制約が弱くなるわけではない。

さらに、取得の成功は最終結果の成功を意味しない。最終応答がエラーやリダイレクト、認証要求になることもある。リンクが最終応答から消えることもある。手元に資源が届いた事実は、それを実行、表示、利用する許可を生まない。

安全な原則は単純だ。103は、別の根拠ですでに許されている準備を早められる。103自身が許可を作ってはならない。

最初のヒントがオリジン発とは限らない

RFC 8297は、キャッシュ仲介者が古くなった保存応答のフィールドをもとに103を生成する例を示す。その後、再検証の過程でオリジンサーバーから届いた103と最終応答を転送することもある。

利用者に近い場所で過去の知識を使えるため、これは性能上合理的である。同時に、出所の推定を難しくする。早期リンクを受け取っただけでは、最終応答を作るアプリケーションが今その値を支持しているとは証明できない。

RFC 9110では、プロキシが自ら生成を求めた情報応答を除き、原則として1xxを転送しなければならない。転送規則は信号の到達を支えるが、転送された値を最終的なオリジン判断へ昇格させない。

CDN、ゲートウェイ、アプリケーションが連なる運用では、どの層が103を合成できるか、どのキャッシュ状態を使うか、許容する古さはどれほどか、オリジンの新しい情報とどう照合するかを明文化したい。クライアントから完全な作成者履歴が見えないなら、その曖昧さの下でも安全な効果だけを許す必要がある。

観測上も、すべてを「サーバーのヒント」と一括りにすべきではない。エッジの古い予測とアプリケーションの変更を区別できなければ、改善すべき場所を誤る。

暫定を最終と誤ると、メッセージの境界が壊れる

RFC 8297のセキュリティ上の警告はHTTP/1.1で具体的である。情報応答を最終応答と誤認するクライアントは、同じ持続接続上で後続要求への応答まで前の最終応答の一部として扱うおそれがある。複数オリジンの要求を同一接続へ多重化していれば、オリジン間の情報漏えいにつながり得る。

つまり「暫定」は説明文ではなく、メッセージ完全性を支える状態である。RFC 9112では、クライアントは受信した応答を、まだ最終非1xx応答を受け取っていない最初の未完了要求へ対応付ける。同じ要求に複数の応答メッセージがあるのは、最終応答の前に1xxがある場合だ。この状態管理を誤れば、どのバイトがどの要求に属するかが崩れる。

そのためRFC 8297は、クライアントが情報応答を正しく扱えると分からない場合、サーバーがHTTP/1.1で103を控える選択肢に触れている。HTTP/2では暫定応答がストリーム上のフィールドブロックとして表現され、情報ステータスを持つブロックでストリームを終了できないため、この種のフレーミング障害は起きにくいとされる。HTTP/3も複数の暫定応答を最終応答の前に置き、暫定応答に内容やトレーラーを認めない。

新しい転送形式は構造上の混同を減らす。しかし、意味上の過剰解釈までは防げない。すべてのフレームを正しく読んだHTTP/3クライアントでも、予測を同意として扱えば統治上の失敗になる。

キャッシュは過去の証拠であって、現在の裁定者ではない

キャッシュが早く動けるのは、以前の応答を覚えているからだ。その記憶は高確率で正しくても、現在の応答そのものではない。昨日必要だったスクリプトが今日は不要かもしれず、再検証の結果が別の状態になる可能性もある。

RFC 9111は、鮮度、検証、保存、再利用の判断を区別する。103を見て取得した資源がキャッシュに入っても、それだけで最終応答のキャッシュ可能性や鮮度は決まらない。温まった資源を最終表現が必ず参照する保証もない。

指標は少なくとも、ヒント送信、受信、関係型認識、取得開始、最終フィールドでの確認、実際の利用を分けたい。一つの「103成功率」にまとめると、破棄したバイト、重複取得、接続圧力、プライバシー露出、オリジン負荷が見えなくなる。

利害も分かれる。サイトは表示高速化を得る一方、不要通信の費用は利用者が負う。エッジはキャッシュ利用率を上げたいが、古い予測による追加要求はオリジンへ届く。受信者が投機予算を持つことは、最適化の費用を一方的に外部化しないための制度である。

小さな共通仕様が、異なる採用を可能にする

IANAのHTTPステータスコード登録簿は103をEarly Hintsとして掲載し、RFC 8297を参照する。同RFCは2017年にIETFの実験プロトコルとして公表された。コミュニティの合意、公開レビュー、IESGの承認を経ているが、Internet Standards Trackの仕様ではない。全環境への導入義務として扱うべきではない。

共通部分は意図的に小さい。暫定コード、通常のHTTPフィールド、最終応答より前という順序、そして最終フィールドを置き換えないという境界である。その上で端末、ブラウザー、企業、仲介者は異なる支出判断を持てる。

この構成は、Lu Hengが示す「最小の初期仕様、将来判断のローカル化、情報に基づく自発的採用」に沿う。サーバーは自分の計算進度を知る。仲介者はキャッシュの古さと命中率を知る。クライアントは通信費、端末資源、資格情報、利用者の状況を知る。結果を観測できる場所に将来判断を残すほうがよい。

要求ごとに中央承認機関へ問い合わせれば、103が稼ぐはずの時間を失う。必要なのは無規則な自由ではなく、あらかじめ定めたローカル方針である。認識する関係型、許すオリジン、最大通信量、資格情報の扱い、絶対に投機しない効果を明示する。

「仮応答」ではなく、投機台帳を作る

責任ある実装は、各103を順番どおり残し、最終応答と別に扱う。どのフィールドがどの取得を始め、どのHTTP版と経路で届き、どの方針が適用されたかを追跡する。

次に、外れたときの損失で処理を分類する。公開かつサイズが限定され、取り消しや破棄ができる取得には予算を与えられる。状態変更、価値移転、秘密開示、同意成立、アクセス権変更は、通常の認証・認可と最終証拠を待つ。

最終応答が来たら、予測を消して上書きするのではなく照合する。繰り返されたもの、消えたもの、変わったもの、継続する準備、取り消す準備を記録する。結果処理には最終フィールドを使い、早期履歴は性能とリスクの説明に使う。

そして、何もしない選択を残す。あるプロトコル版や仲介者で問題が起きたとき、103への反応だけを止め、最終応答の通常処理を維持できることが重要だ。

Early Hintsは未来を確定する仕組みではない。不確実なまま役立つ範囲を明示する仕組みである。早く共有し、損失を局所化し、最後まで事実を集めた応答に最終権限を残す。この節度があるからこそ、速度と分散した判断を両立できる。

出典