GoogleのDavid Benjamin氏から「Client Hint Reliability」という提案仕様が出されている。なおW3C WICG側でも議論行われている (URL)
まず、Client Hintについて説明してから、Client Hint Reliabilityの説明を行う。
HTTP Client Hint
「HTTP Client Hint」という仕組みが、広く使われるようになっています。
HTTP Client Hintは、Webページを表示するにあたりヒントをクライアントからサーバに送ります。例えば、 DPR 解像度 をCH-DPRリクエストヘッダに付加して送信したりできます。
その他に、最近で言えばChromeがUserAgentヘッダの情報量を少なくし、代わりにより詳細なユーザエージェント情報を要求するのにHTTP Client Hintが利用されています。
asnokaze.hatenablog.com
このHTTP Client Hintでは、Accept-CHレスポンスヘッダでサーバがほしいと思うClient Hintのみを要求することで、不用意なクライアント情報の送信を抑制することが出来ます。
User Agent Client Hints の流れを簡単に以下に示す
Client Hint Reliability
上記で説明したように、Client Hintの仕組みでは、最初のリクエストにはサーバが必要とする情報がついてない場合があります。この問題に対応するのが「Client Hint Reliability」です。
「Client Hint Reliability」では、下記の独立した2つのアプローチを提案している。
- Critical-CH: 必要な情報をつけて送り直してもらう
- ACCEPT_CH: 事前に、必要な情報を通知する
Critical-CH
新しくCritical-CHレスポンスヘッダを定義します。
Critical-CHヘッダは、必要なClient Hintsが無いのでリトライするようにクライアントに指示することができます。
例えば、下記のように使用する
HTTP/1.1 200 OK
Content-Type: text/html
Accept-CH: Sec-CH-Example, Sec-CH-Example-2
Vary: Sec-CH-Example
Critical-CH: Sec-CH-Exampleサーバは受け取ったリクエストヘッダにsec-ch-exampleがなかった場合、Critical-CH: Sec-CH-Exampleを含むレスポンスを返して、クライアントにこのClient Hintsを付加してリクエストをリトライするよう伝えることが出来ます。
ACCEPT_CH拡張フレーム
Critical-CHでは1RTT分のやり取りが発生してしまいました。それを回避する方法が、HTTP/2拡張フレームとして新しく定義するACCEPT_CHフレームを使う方法です。
フレーム定義は下記のとおりです。
内容は下記のとおりです
これは、Accept-CHヘッダ相当の情報を拡張フレームに詰めて送信できるということです。拡張フレームにすることで何が嬉しいかというと、クライアントからのリクエストを待たずしてAccept-CHヘッダ相当の情報を送信可能になる点です。
TLS1.3ではハンドシェイク後にサーバの方が先にHTTP/2のフレームを送信できます。また、TLS ALPSを利用することで、TLSハンドシェイク中にAccept-CH情報をクライアントに渡す方法も検討されています。
TLS ALPSを使うことで、最初のHTTPリクエストでサーバが必要なClient Hintsを付けることが出来るようになります。
TLS ALPSの紹介は下記を参照
asnokaze.hatenablog.com
