Come generare e pubblicare file SXG utilizzando nginx e le sfide del precaricamento delle sottorisorse.
In qualità di distributore Signed HTTP Exchange (SXG), puoi inviare file SXG per conto dei creatori dei contenuti originali. I browser web che supportano SXG mostreranno questi file SXG come se fossero stati pubblicati dai creator dei contenuti originali. In questo modo puoi implementare il precaricamento tra siti senza violare la privacy. Questa guida illustra come distribuire correttamente SXG.
Supporto cross-browser
Attualmente Chrome è l'unico browser che supporta SXG. Per informazioni più aggiornate, consulta la sezione Consenso e standardizzazione di Scambi HTTP con firma dell'origine.
Recupera file SXG
Nell'intestazione della richiesta Accept, specifica 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, nella barra viene visualizzato l'indirizzo del publisher dei contenuti originali.
Precarica risorse secondarie
La maggior parte delle pagine web è costituita da più risorse secondarie, ad esempio CSS, JavaScript, caratteri e immagini. I contenuti di SXG non possono essere modificati senza la chiave privata del creatore dei contenuti. Questo causa problemi quando il browser tenta di risolvere le sottorisorse.
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 questa operazione non deve essere eseguita nella fase di precaricamento per preservare la privacy.
Se la risorsa viene recuperata durante la fase di precaricamento, il creator dei contenuti (website.test) potrà rilevare il distributore di contenuti (distributor.test) che la richiede.
Se il distributore vuole pubblicare app.js.sxg dal proprio servizio e prova a modificare https://website.test/app.js affinché sia la versione del distributore di quella sottorisorsa (ad esempio https://distributor.test/website.test/app.js.sxg), causerà una mancata corrispondenza della firma e lo SXG non sarà più valido.
Per risolvere questo problema, in Chrome ora è disponibile una funzionalità sperimentale di precaricamento delle sottorisorse SXG.
Puoi abilitarlo all'indirizzo: about://flags/#enable-sxg-subresource-prefetching.
Per utilizzare il precaricamento delle sottorisorse, devono essere soddisfatte le seguenti condizioni:
- Il publisher 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=". Questo specifica la sottorisorsa che può essere sostituita con l'hash di integrità specifico di SXG. - Il distributore deve collegare un'intestazione della risposta quando gestisce l'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 diapp.jse corrisponde alla risorsa secondaria.
Il primo è relativamente facile perché nginx-sxg-module può calcolare gli hash di integrità e incorporarli nelle intestazioni dei link dalle risposte upstream. La seconda, invece, è più difficile perché il distributore di contenuti deve essere a conoscenza delle sottorisorse specificate in SXG.
Se non esistono sottorisorse diverse da https://website.test/app.js, tutto quello che devi aggiungere alla configurazione nginx è:
add_header link <https://distributor.test/website.test/app.js.sxg>;rel="alter...
Questi casi, però, sono rari perché i siti web tipici sono costituiti da molte sottorisorse. Inoltre, il distributore deve allegare l'intestazione del link di ancoraggio corretta quando si pubblica un file SXG. Al momento non esiste un modo semplice per risolvere il problema, quindi continua a seguirci per non perderti gli aggiornamenti.
Invia feedback
I tecnici di Chromium sono lieti di ricevere il tuo feedback in merito alla 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à di grande aiuto per il processo di standardizzazione e contribuirà inoltre a risolvere i problemi di implementazione. Grazie!