nginx を使用して SXG ファイルを取得して提供する方法と、サブリソースのプリフェッチの課題。
Signed HTTP Exchange(SXG)ディストリビュータは、元のコンテンツの作成者に代わって SXG ファイルを配信できます。SXG をサポートするウェブブラウザは、そのような SXG ファイルが元のコンテンツの作成者から提供されたかのように表示されます。これにより、プライバシーを侵害することなく、クロスサイト プリロードを実装できます。このガイドでは、SXG を適切に配信する方法について説明します。
クロスブラウザ サポート
現在、SXG をサポートしているブラウザは Chrome のみです。最新の情報については、送信元で署名された HTTP 交換のコンセンサスと標準化のセクションをご覧ください。
SXG ファイルを取得する
Accept
リクエスト ヘッダーで、サーバーがリクエストとともに SXG ファイルを返すように指定します。
Accept: application/signed-exchange;v=b3,*/*;q=0.8
このガイドでは、SXG ファイルが /var/www/sxg
にあることを前提としています。
シンプルな SXG ファイルを提供する
単一の SXG ファイルを配布するには、次のヘッダーを添付します。
Content-Type: application/signed-exchange;v=v3
X-Content-Type-Options: nosniff
nginx
を構成します。
http {
...
types {
application/signed-exchange;v=b3 sxg;
}
add_header X-Content-Type-Options nosniff;
location / {
more_set_headers "Content-Type: application/signed-exchange;v=b3";
alias /var/www/sxg/;
try_files $uri.sxg $uri =404;
autoindex off;
}
...
新しい構成を nginx
に読み込みます。
sudo systemctl restart nginx.service
nginx
は SXG ファイルの配信を開始します。
Chrome がサーバーにアクセスすると、元のコンテンツ配信元のアドレスがバーに表示されます。
サブリソースのプリフェッチ
ほとんどのウェブページは、CSS、JavaScript、フォント、画像などの複数のサブリソースで構成されます。SXG のコンテンツは、コンテンツ作成者の秘密鍵がないと変更できません。これにより、ブラウザがサブリソースを解決しようとしたときに問題が発生します。
たとえば、https://website.test/index.html
の index.html.sxg
に https://website.test/app.js
へのリンクがあるとします。ユーザーのブラウザが https://distributor.test/example.com/index.html.sxg
から SXG ファイルを受け取ると、https://website.test/app.js
へのリンクが検索されます。ブラウザは実際のアクセス時に https://website.test/app.js
を直接取得できますが、プライバシー保護のためプリロード フェーズで取得しないでください。プリロード フェーズでリソースを取得した場合、コンテンツ作成者(website.test
)は、どのコンテンツ配信会社(distributor.test
)がリソースをリクエストしているかを検出できます。
ディストリビューターが独自のサービスから app.js.sxg
を提供する場合に、https://website.test/app.js
をそのサブリソースのディストリビューターのバージョン(https://distributor.test/website.test/app.js.sxg
など)に変更しようとすると、署名の不一致が発生し、SXG が無効になります。
この問題を解決するため、Chrome には試験運用版の SXG サブリソース プリフェッチ機能が用意されています。
about://flags/#enable-sxg-subresource-prefetching
で有効にできます。サブリソースのプリフェッチを使用するには、次の条件を満たす必要があります。
- ニュース メディアは、レスポンス ヘッダー エントリ(
link: <https://website.test/app.js>;rel="preload";as="script",<https://website.test/app.js>;rel="allowed-alt-sxg";header-integrity="sha256-h6GuCtTXe2nITIHHpJM+xCxcKrYDpOFcIXjihE4asxk="
など)を SXG に埋め込む必要があります。これにより、SXG の特定の整合性ハッシュで代用できるサブリソースを指定します。 - ディストリビューターは SXG の配信時にレスポンス ヘッダー(
link: <https://distributor.test/website.test/app.js.sxg>;rel="alternate";type="application/signed-exchange;v=b3";anchor="https://website.test/app.js"
など)を添付する必要があります。これにより、app.js
のパスが指定され、サブリソースに対応します。
1 つ目は、nginx-sxg-module
で整合性ハッシュを計算してアップストリーム レスポンスのリンクヘッダーに埋め込むことができるため、比較的簡単です。2 つ目は、コンテンツ配信者が SXG 内の指定されたサブリソースを認識している必要があるため、より困難です。
https://website.test/app.js
以外にサブリソースがない場合、nginx config に以下のみを追加します。
add_header link <https://distributor.test/website.test/app.js.sxg>;rel="alter...
しかし、一般的なウェブサイトは多数のサブリソースで構成されているため、そのようなケースはまれです。また、ディストリビューターは SXG ファイルを配信するときに、適切なアンカーリンク ヘッダーを添付する必要があります。現在のところ、この問題を簡単に解決する方法はありません。今後の最新情報をお待ちください。
フィードバックを送信
Chromium のエンジニアは、SXG の配布について webpackage-dev@chromium.org でフィードバックをお寄せください。 また、仕様に関するディスカッションに参加したり、チームにバグを報告したりすることもできます。 皆様からのフィードバックは、標準化プロセスや実装の問題の解決に大いに役立ちます。 ありがとうございました