このページは Cloud Translation API によって翻訳されました。

nginx を使用して Signed HTTP Exchange（SXG）を配布する方法

nginx を使用して SXG ファイルを取得して提供する方法と、サブリソースのプリフェッチの課題。

Hiroki Kumazaki

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）がリソースをリクエストしているかを検出できます。

Distributor.test/index.html.sxg 内の app.js へのリンクは、website.test/app.js を指しています。

ディストリビューターが独自のサービスから app.js.sxg を提供する場合に、https://website.test/app.js をそのサブリソースのディストリビューターのバージョン（https://distributor.test/website.test/app.js.sxg など）に変更しようとすると、署名の不一致が発生し、SXG が無効になります。

Distributor.test/index.html.sxg 内の app.js への参照を Distributor.test/app.js にリンクしようとすると、署名の不一致が生じます。

この問題を解決するため、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 でフィードバックをお寄せください。また、仕様に関するディスカッションに参加したり、チームにバグを報告したりすることもできます。皆様からのフィードバックは、標準化プロセスや実装の問題の解決に大いに役立ちます。ありがとうございました