要約

  • 103に入るのは、最終応答にも現れる可能性が高いフィールドであり、確定済みのコピーではない。ブラウザはpreloadを始められるが、最終応答の処理を置き換えることはできない。
  • オリジンやキャッシュは候補を示し、クライアントは費用を認めるか判断する。ナビゲーションは最終応答が決め、候補資源はDNS、TLS、ポリシー、完全性、再利用の各条件を別に満たす。

ナビゲーション要求がアプリケーションに届いた。画面の骨格はいつも同じだが、セッション照合が終わるまで、結果が本文かログインへのリダイレクトかは分からない。エッジには、前回の応答でscreen.cssが重要だった記録がある。待てば確実だが一往復を失う。先に取得すれば速いかもしれないが、存在しないページのために通信するかもしれない。

RFC 8297は、この不確実性を隠さずに利用する。サーバーは103 Early HintsとLinkフィールドを送り、処理を続け、後から最終応答を送る。クライアントはrel=preloadを理解すれば、待ち時間中に対象の取得を始められる。

ここで重要なのはEarlyよりHintsである。サーバーは「後でも現れそうだ」と述べるだけで、要求の成功も、資源の採用も、最終フィールドの一致も約束しない。早い情報は行動の選択肢を作るが、未来を決定しない。

中間応答は要求を終わらせない

RFC 9110では、1xxは最終処理前の情報応答である。一つの要求に複数の中間応答が届き、その後に最終応答が一つ届き得る。1xxはフィールド部で終わり、内容もトレーラーも持たない。ユーザーエージェントは予期しない1xxを無視してよい。

RFC 8297はさらに、103の評価を性能最適化に限定する。最終応答の扱いを、それ以外の形で変えてはならない。後から302が来ればリダイレクトであり、500が来れば失敗である。先にCSSを取得した事実は、状態コードを書き換えない。

103にないフィールドも否定材料にならない。早い時点で判明した一部だけを送れるためだ。複数の103で候補が増え、最終応答で一部が残り、一部が別のLinkに変わることも許される。変更を許さなければ、確定まで送れず、早期性を失う。

短い時間の中に四つの決定主体がいる

最終状態と完全なフィールドはオリジンが所有する。一方、ヒントはキャッシュ中間者からも出せる。RFC 8297は、古い応答のフィールドから中間者が103を作り、再検証中に送り、その後オリジンの応答を転送する例を示す。

投機はブラウザが所有する。無視、キャッシュ利用、バイト上限、低いスケジュール順位、リダイレクト後の破棄を選べる。Linkは候補関係を表すが、クライアントのキューを遠隔操作しない。

ナビゲーション結果は最終応答が所有する。さらに、対象資源にも独立した結果がある。DNS、接続、TLS証明書、資格情報、応答状態、メディア型、完全性、キャッシュ規則がそろって初めて利用可能になる。

RFC 8288が定義するLinkは、文脈、関係型、対象、属性から成る。これは関係についての記述であり、対象の認証でも取得成功の保証でもない。

Web実装は信号を狭く扱う

HTML Standardは、ナビゲーション中のEarly Hintsを規定する。現在のアルゴリズムは最初の早期ヒントを扱い、その後に別オリジンへのリダイレクトがあれば破棄する。

この段階で扱うpreload属性はas、crossorigin、integrity、typeに限られる。Document生成後でなければ意味を持てない属性もある。早期Linkは最終応答や文書内Linkより先に処理されるが、先着順は権限順ではない。

早期のContent Security Policyは投機要求を制限できる。最終ポリシーがさらに厳しければ、すでに取得した応答を文書が利用できない場合がある。通信済みという事実から利用許可は生まれない。

Fetch Standardも、103を処理した後で最終応答を待ち続ける。最適化は要求の中にあり、要求を置き換えない。

古いキャッシュは経験であって現在ではない

昨日のLinkは今日もよい予測かもしれない。配備、個人化、経路変更の後には外れるかもしれない。そのため、発生源を残す必要がある。

アプリケーション生成、エッジ規則、古いキャッシュメタデータを区別し、103と最終フィールドを別に保存する。複数層が異なる候補を出したなら、重複や不一致そのものが運用証拠である。「サーバーがpreloadした」という一行に潰してはならない。

中間者は予測を早く届ける。クライアントは賭けの価格を決める。オリジンは答えを完成させる。役割は連続していても、権限は継承されない。

意味は仮でも、費用は取り消せない

使われないヒントでもDNS、接続、帯域、無線電力、混雑窓、オリジン負荷を消費する。別オリジンなら、最終ページが決まる前に関心を伝える。後のリダイレクトで送信済みパケットは戻らない。

したがって103件数ではなく、利用された早期作業を測る。ヒント受信、開始前倒し、ネットワークまたはキャッシュ応答、最終フィールドとの照合、ポリシー通過、文書での実利用を一つの鎖にする。短縮時間と、未使用バイト・要求・接続を並べる。

互換性も観測が必要だ。RFC 8297は、HTTP/1.1クライアントが103を最終応答と誤認すると、持続接続上の後続メッセージを誤って区切り、オリジン間の情報漏えいにつながり得ると警告する。既知の対応がなければHTTP/1.1で送らない判断もある。HTTP/2はこのフレーミング危険を減らすが、ヒントの妥当性を保証しない。

IANAレジストリは103をEarly Hintsとして一意にする。中間者の通過、ブラウザの行動、資源の再利用、利用者の改善までは証明しない。

Lu Hengの最小初期仕様・ローカルな将来判断・自発的採用は、この薄い仕組みに合う。共通なのは「暫定フィールドであり最終応答が続く」という意味だけで、採用と資源配分は実装側に残る。Running Codeを優先する原則に従えば、設定ではなくワイヤ、クライアント行動、結果を確認する。

103を切っても完全で正しいページが届くことが安全条件である。切ると壊れるなら、任意のヒントが設計を支配し始めている。