Come distribuire SXG (Signed HTTP Exchange) utilizzando nginx

Come ottenere e pubblicare file SXG utilizzando nginx e sfide del precaricamento delle sottorisorse.

Hiroki Kumazaki

In qualità di distributore di Signed HTTP Exchange (SXG), puoi inviare file SXG per conto degli autori dei contenuti originali. I browser web che supportano SXG visualizzano questi file SXG come se fossero stati pubblicati dagli autori dei contenuti originali. In questo modo puoi implementare il precaricamento tra siti senza violare la privacy. Questa guida ti mostra come distribuire correttamente SXG.

Supporto cross-browser

Chrome è attualmente l'unico browser che supporta SXG. Vedi la sezione Consenso e Per informazioni più aggiornate, consulta la sezione sulla standardizzazione delle piattaforme di scambio HTTP con firma dall'origine.

Scarica file SXG

Specifica nell'intestazione della richiesta Accept che il server deve restituire un file SXG insieme alla richiesta:

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

Questa guida presuppone che tu abbia inserito i file SXG in /var/www/sxg.

Pubblica un file SXG semplice

Allega le seguenti intestazioni per distribuire un singolo file SXG:

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

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

Carica la nuova configurazione in nginx:

sudo systemctl restart nginx.service

nginx inizierà a pubblicare file SXG. Quando Chrome accede al tuo server, l'indirizzo del publisher di contenuti originale viene visualizzato nella barra.

Precarica risorse secondarie

La maggior parte delle pagine web è composta da più risorse secondarie, come CSS, JavaScript, caratteri e immagini. I contenuti di SXG non possono essere modificati senza la chiave privata del creator dei contenuti. Questo causa problemi quando il browser tenta di risolvere le risorse secondarie.

Ad esempio, supponiamo che index.html.sxg di https://website.test/index.html abbia un link a https://website.test/app.js. Quando il browser di un utente riceve il file SXG da https://distributor.test/example.com/index.html.sxg, trova il link a https://website.test/app.js. Il browser può recuperare https://website.test/app.js direttamente all'accesso effettivo, ma non deve essere eseguito nella fase di precaricamento per preservare la privacy. Se la risorsa è stata recuperata durante la fase di precaricamento, il creator di contenuti (website.test) potrebbe essere in grado di rilevare quale distributore di contenuti (distributor.test) richiede la risorsa.

Se il distributore vuole pubblicare app.js.sxg dal proprio servizio e tenta di modificare https://website.test/app.js in modo che sia la versione del distributore di quella risorsa secondaria (ad esempio https://distributor.test/website.test/app.js.sxg), la firma non corrisponde e l'SXG non è valido.

Per risolvere il problema, è disponibile una funzionalità sperimentale di precaricamento delle sottorisorse SXG in Chrome. Puoi abilitarlo all'indirizzo: about://flags/#enable-sxg-subresource-prefetching. Per utilizzare il precaricamento delle sottorisorse, devono essere soddisfatte le seguenti condizioni:

• L'editore deve incorporare una voce di intestazione della risposta in SXG, ad esempio: link: <https://website.test/app.js>;rel="preload";as="script",<https://website.test/app.js>;rel="allowed-alt-sxg";header-integrity="sha256-h6GuCtTXe2nITIHHpJM+xCxcKrYDpOFcIXjihE4asxk=". Specifica la risorsa secondaria che può essere sostituita con l'hash di integrità specifico di SXG.
• Il distributore deve collegare un'intestazione della risposta durante la pubblicazione dell'SXG, ad esempio: link: <https://distributor.test/website.test/app.js.sxg>;rel="alternate";type="application/signed-exchange;v=b3";anchor="https://website.test/app.js". Specifica il percorso di app.js e corrisponde alla risorsa secondaria.

Il primo è relativamente facile perché nginx-sxg-module può calcolare hash di integrità e incorporarli nelle intestazioni dei link delle risposte upstream. Il secondo, però, è più difficile perché il distributore di contenuti deve conoscere le sottorisorse specificate nell'SXG.

Se non esistono risorse secondarie diverse da https://website.test/app.js, tutto ciò che devi aggiungere alla configurazione nginx è:

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

Tuttavia, questi casi sono rari perché i siti web tipici sono costituiti da molte risorse secondarie. Inoltre, il distributore deve allegare l'intestazione del link di ancoraggio corretta quando pubblica un file SXG. Al momento, non è facile risolvere questo problema, quindi continua a seguirci per non perderti gli aggiornamenti.

Invia feedback

I tecnici di Chromium sono interessati a ricevere il tuo feedback sulla distribuzione di SXG all'indirizzo webpackage-dev@chromium.org. Puoi anche partecipare alla discussione sulle specifiche o segnalare un bug al team. Il tuo feedback sarà molto utile per il processo di standardizzazione e per la risoluzione dei problemi di implementazione. Grazie.