Cara mendistribusikan Signed HTTP Exchanges (SXG) menggunakan nginx

Cara mendapatkan dan menayangkan file SXG menggunakan nginx, dan tantangan pengambilan data subresource.

Hiroki Kumazaki

Sebagai distributor Signed HTTP Exchange (SXG), Anda dapat mengirimkan file SXG atas nama kreator konten asli. Browser web yang mendukung SXG akan menampilkan file SXG seolah-olah dikirim dari kreator konten asli. Hal ini memungkinkan Anda menerapkan pramuat lintas situs tanpa melanggar privasi. Panduan ini menunjukkan cara mendistribusikan SXG dengan benar.

Dukungan lintas browser

Saat ini Chrome adalah satu-satunya browser yang mendukung SXG. Lihat bagian Konsensus & Standardisasi di Pertukaran HTTP yang Ditandatangani Asal untuk mengetahui informasi terbaru.

Mendapatkan file SXG

Dalam header permintaan Accept, tentukan bahwa Anda ingin server menampilkan file SXG beserta permintaannya:

Accept: application/signed-exchange;v=b3,*/*;q=0.8

Panduan ini mengasumsikan bahwa Anda menempatkan file SXG di /var/www/sxg.

Menyajikan file SXG sederhana

Lampirkan header berikut untuk mendistribusikan satu file SXG:

Content-Type: application/signed-exchange;v=v3
X-Content-Type-Options: nosniff

Konfigurasi 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;
    }
    ...

Muat konfigurasi baru ke nginx:

sudo systemctl restart nginx.service

nginx akan mulai menyajikan file SXG. Saat Chrome mengakses server Anda, alamat penayang konten asli akan muncul di kolom.

Pengambilan subresource

Sebagian besar halaman web terdiri dari beberapa subresource, seperti CSS, JavaScript, font, dan gambar. Konten SXG tidak dapat diubah tanpa kunci pribadi kreator konten. Hal ini menyebabkan masalah saat browser mencoba menyelesaikan subresource.

Misalnya, index.html.sxg dari https://website.test/index.html memiliki link ke https://website.test/app.js. Saat browser pengguna menerima file SXG dari https://distributor.test/example.com/index.html.sxg, browser akan menemukan link ke https://website.test/app.js. Browser dapat mengambil https://website.test/app.js langsung pada akses sebenarnya, tetapi sebaiknya tidak dilakukan dalam fase pramuat untuk menjaga privasi. Jika resource diambil selama fase pramuat, kreator konten (website.test) akan dapat mendeteksi distributor konten (distributor.test) mana yang meminta resource.

Jika distributor ingin menyalurkan app.js.sxg dari layanannya sendiri dan mencoba memodifikasi https://website.test/app.js menjadi versi distributor dari subresource tersebut (seperti https://distributor.test/website.test/app.js.sxg), hal ini akan menyebabkan ketidakcocokan tanda tangan dan membuat SXG menjadi tidak valid.

Untuk mengatasi masalah ini, kini tersedia fitur pengambilan data subresource SXG eksperimental di Chrome. Anda dapat mengaktifkannya di: about://flags/#enable-sxg-subresource-prefetching. Untuk menggunakan pengambilan data subresource, kondisi berikut harus dipenuhi:

• Penayang harus menyematkan entri header respons di SXG, seperti: link: <https://website.test/app.js>;rel="preload";as="script",<https://website.test/app.js>;rel="allowed-alt-sxg";header-integrity="sha256-h6GuCtTXe2nITIHHpJM+xCxcKrYDpOFcIXjihE4asxk=". Fungsi ini menentukan subresource yang dapat diganti dengan hash integritas spesifik SXG.
• Distributor harus melampirkan header respons saat menayangkan SXG, seperti: link: <https://distributor.test/website.test/app.js.sxg>;rel="alternate";type="application/signed-exchange;v=b3";anchor="https://website.test/app.js". Ini menentukan jalur app.js dan sesuai dengan subresource.

Yang pertama relatif mudah karena nginx-sxg-module dapat menghitung hash integritas dan menyematkannya ke header link dari respons upstream. Namun, yang kedua lebih sulit karena distributor konten harus mengetahui subresource yang ditentukan dalam SXG.

Jika tidak ada subresource selain https://website.test/app.js, yang perlu Anda tambahkan dalam konfigurasi nginx adalah:

add_header link <https://distributor.test/website.test/app.js.sxg>;rel="alter...

Namun, kasus seperti ini jarang terjadi karena situs biasanya terdiri dari banyak subresource. Selain itu, distributor harus melampirkan header link anchor yang tepat saat menyajikan file SXG. Saat ini, tidak ada cara mudah untuk menyelesaikan masalah ini, jadi nantikan kabar terbarunya.

Kirim masukan

Engineer Chromium ingin mendengar masukan Anda tentang pendistribusian SXG di [e-mail]. Anda juga dapat bergabung dalam diskusi spesifikasi, atau melaporkan bug kepada tim. Masukan Anda akan sangat membantu proses standardisasi dan membantu mengatasi masalah implementasi. Terima kasih.