Il protocollo HTTP definisce oltre 40 codici di stato del server, 9 dei quali servono apposta per i reindirizzamenti URL. Ogni codice di stato del reindirizzamento inizia con il numero 3 (HTTP 3xx) e ha un proprio metodo per gestire i reindirizzamenti. Mentre alcuni di essi sono simili, tutti si occupano dei redirect in modo diverso.
Capire come funziona ogni codice di stato del reindirizzamento HTTP è fondamentale per diagnosticare o correggere gli errori di configurazione del sito web.
In questa guida, tratteremo in modo approfondito i codici di stato HTTP 307 Temporary Redirect e 307 Internal Redirect, includendo il loro significato e la loro differenza rispetto agli altri codici di stato 3xx redirect.
Cominciamo!
Come Funziona il Redirect HTTP 3xx
Prima di vedere nel dettaglio le risposte 307 Temporary Redirect e 307 Internal Redirect, cerchiamo di capire come funziona il reindirizzamento HTTP.
I codici di stato HTTP sono risposte dal server al browser. Ogni codice di stato è un numero a tre cifre, dove la prima cifra definisce il tipo di risposta. I codici di stato HTTP 3xx implicano un reindirizzamento. Essi indicano al browser di reindirizzare ad un nuovo URL, che è definito nell’intestazione Location della risposta del server.
Quando il vostro browser incontra una richiesta di reindirizzamento dal server, deve capire la natura di questa richiesta. I vari codici di stato del reindirizzamento HTTP 3xx gestiscono queste richieste. Conoscerli tutti ci aiuterà a capire meglio il 307 Temporary Redirect e il 307 Internal Redirect.
I Vari Redirect HTTP 3xx
Esistono diversi tipi di codici di stato di reindirizzamento HTTP 3xx. La specifica HTTP originale non includeva 307 Temporary Redirect e 308 Permanent Redirect, in quanto questi ruoli dovevano essere ricoperti da 301 Moved Permanently e 302 Found.
Tuttavia, la maggior parte dei client ha cambiato il metodo di richiesta HTTP da POST a GET per le risposte di reindirizzamento 301 e 302, nonostante le specifiche HTTP non consentano ai client di farlo. Questo comportamento ha reso necessaria l’introduzione dei più severi codici di stato 307 Temporary Redirect e 308 Permanent Redirect nell’aggiornamento HTTP/1.1.
La risposta 307 Internal Redirect è una variante del codice di stato 307 Temporary Redirect. Non è definita dallo standard HTTP ed è solo un’implementazione locale del browser. Ne parleremo più avanti in dettaglio.
Mentre i codici di stato di reindirizzamento come 301 e 308 sono memorizzati nella cache di default, altri come 302 e 307 non lo sono. Tuttavia, è possibile rendere tutte le risposte di reindirizzamento memorizzabili in cache (o meno) aggiungendo un campo di intestazione della risposta Cache-Control o Expires.
Usare 302 vs 303 vs 307 per i Reindirizzamenti Temporanei
Come si vede nel grafico sopra, per i reindirizzamenti temporanei si hanno tre opzioni: 302, 303 o 307. Tuttavia, la maggior parte dei clienti tratta il codice di stato 302 come una risposta 303 e cambia il metodo di richiesta HTTP in GET. Questo non è l’ideale dal punto di vista della sicurezza.
“RFC 1945 e RFC 2068 specificano che il cliente non è autorizzato a modificare il metodo sulla richiesta reindirizzata. Tuttavia, la maggior parte delle implementazioni di user agent esistenti trattano il 302 come se fosse una risposta 303, eseguendo un GET sul valore del campo Location indipendentemente dal metodo di richiesta originale. I codici di stato 303 e 307 sono stati aggiunti per i server che desiderano rendere inequivocabilmente chiaro quale tipo di reazione ci si aspetta dal client. ”
– HTTP/1.1. Definizioni dei codici di stato, W3.org
Quindi, per i reindirizzamenti temporanei in cui è necessario mantenere il metodo di richiesta HTTP, usate la più rigorosa risposta 307 Temporary Redirect.
Ad esempio, reindirizzare /register-form.html a signup-form.html, o da /login.php a /signin.php.
Per i casi in cui è necessario modificare il metodo di reindirizzamento della richiesta in GET, utilizzate invece la risposta 303 See Other.
Ad es. reindirizzare una richiesta POST dalla pagina /register.php per caricare una pagina /success.html tramite richiesta GET.
A meno che il vostro target di riferimento non utilizzi client legacy, evitate di utilizzare la risposta di reindirizzamento 302 Found.
Capire il 307 Internal Redirect per i Siti Solo HTTPS
Se avete un sito solo HTTPS (cosa che dovreste avere), quando provate a visitarlo in modo insicuro tramite il normale http://, il vostro browser si reindirizzerà automaticamente alla sua versione sicura https://. Di solito, questo accade con una reindirizzamento dal server 301 Moved Permanently.
Ad esempio, se visitate il sito http://citibank.com e caricate DevTools in Chrome e selezionando la scheda Network, potrete visualizzare tutte le richieste effettuate tra il browser e il server.
La prima risposta è 301 Moved Permanently, che reindirizza il browser alla versione HTTPS del sito.
Se scaviamo più a fondo nei campi Headers della prima richiesta, possiamo vedere che l’header di risposta Location definisce quale sia l’URL sicuro per il reindirizzamento.
Il problema di questo approccio è che i malintenzionati possono dirottare la connessione di rete per reindirizzare il browser verso un URL personalizzato. Attacchi Man-in-the-Middle (MITM) come questo sono abbastanza comuni. Una popolare serie televisiva l’ha addirittura parodiato in uno dei suoi episodi.
Inoltre, un malintenzionato può lanciare un attacco MITM senza modificare l’URL visualizzato nella barra degli indirizzi del browser. Ad esempio, all’utente può essere servita una pagina di phishing che assomiglia esattamente al sito originale.
E poiché tutto sembra uguale, compreso l’URL nella barra degli indirizzi, la maggior parte degli utenti sarà felice di digitare le proprie credenziali. Potete immaginare perché questo può essere un male.
Reindirizzamenti Sicuri con il 307 Internal Redirect
Ora proviamo lo stesso esempio con Kinsta. Visitando il sito https://kinsta.com si accede alle richieste di rete come mostrato nell’immagine qui sotto.
La prima richiesta da parte del sito è come l’esempio precedente, ma questa volta porta ad una risposta 307 Internal Redirect. Facendo clic su di essa si ottengono maggiori dettagli su questa risposta.
Nota: se provate a visitare il sito direttamente con https://, non si vedrà questa intestazione in quanto il browser non ha bisogno di eseguire alcun reindirizzamento.
Notate l’header della risposta Non-Authoritative-Reason: HSTS. Si tratta dell’intestazione di risposta Strict Transport Security (HSTS) di HTTP, nota anche come header di risposta Strict-Transport-Security.
Cos’è l’HSTS (Strict Transport Security)?
L’IETF ha ratificato l’HTTP Strict Transport Security (HSTS) nel 2012 per costringere i browser a utilizzare connessioni sicure quando un sito funziona rigorosamente su HTTPS.
Questo è simile a Chrome o Firefox che dice: “Non proverò nemmeno a richiedere questo sito o una qualsiasi delle sue risorse attraverso il protocollo HTTP insicuro. Lo cambierò invece in HTTPS e proverò di nuovo”.
Potete seguire la guida di Kinsta su come abilitare HSTS per renderlo operativo sul vostro sito web WordPress.
Analizziamo meglio l’header della seconda richiesta per capire meglio.
Qui si può vedere dell’header di risposta strict-transport-security: max age=31536000.
L’attributo max-age dell’header di risposta strict-transport-security definisce per quanto tempo il browser deve seguire questo schema. Nell’esempio precedente, questo valore è impostato a 3153600 secondi (cioè 1 anno).
Una volta che un sito restituisce questo header di risposta, il browser non tenterà nemmeno di effettuare una normale richiesta HTTP. Al contrario, farà un 307 Internal Redirectsu HTTPS e riproverà.
Ogni volta che questo processo si ripete, le intestazioni di risposta vengono resettate. In questo modo il browser non sarà in grado di effettuare una richiesta insicura per un periodo di tempo indeterminato.
Se il vostro sito è ospitato su Kinsta, potete creare un ticket di supporto per far aggiungere l’intestazione HSTS al vostro sito WordPress. Poiché l’aggiunta dell’header HSTS garantisce vantaggi in termini di prestazioni, vi consigliamo di abilitare HSTS per il vostro sito.
Cos’È una Lista di Precaricamento HSTS?
C’è un evidente problema di sicurezza anche con l’HSTS. La prima richiesta HTTP che si invia con il browser è insicura, ripetendo così il problema che abbiamo osservato in precedenza con Citibank.
Inoltre, l’header di risposta HSTS può essere inviato solo tramite HTTPS, per cui la richiesta iniziale non può nemmeno essere restituita.
Per affrontare questo problema, HSTS supporta un attributo di precaricamento nell’intestazione della risposta. L’idea è quella di avere un elenco di siti che fanno sì che HSTS sia precaricato nel browser stesso, bypassando completamente questo problema di sicurezza.
Aggiungendo il vostro sito all’elenco di precaricamento HSTS del browser, saprà che il vostro sito applica una rigorosa politica HSTS, anche se sta visitando il vostro sito per la prima volta. Il browser utilizzerà quindi la risposta 307 Internal Redirect per reindirizzare il vostro sito al suo schema sicuro https:// prima di richiedere qualsiasi altra cosa.
Si noti che, a differenza del 307 Temporary Redirect, la risposta de l307 Internal Redirect è una “falsa intestazione” impostata dal browser stesso. Non proviene dal server, dall’host web (ad es. Kinsta) o dal CMS (ad es. WordPress).
Aggiungere un sito a una lista di precaricamento HSTS ha molti vantaggi:
- Il server web non vede mai richieste HTTP insicure. Questo riduce il carico del server e rende il sito più sicuro.
- Il browser si occupa del reindirizzamento da HTTP a HTTPS, rendendo il sito più veloce e sicuro.
Requisiti della Lista di precaricamento HSTS
Se desiderate aggiungere il vostro sito alla lista di precaricamento HSTS di un browser, è necessario verificare le seguenti condizioni:
- Fate installare un certificato SSL/TLS valido per il vostro dominio.
- Applicate l’HTTPS reindirizzando tutto il traffico HTTP verso l’HTTPS.
- Tutti i sottodomini devono essere serviti su HTTPS, in particolare il sottodominio www se esiste un record DNS per quel sottodominio.
- L’attributo max-age deve essere impostato per almeno 31536000 secondi (1 anno).
- Le direttive includeSubdomains e preload devono essere specificate.
- Se state realizzando un reindirizzamento aggiuntivo, dovete includere l’intestazione HSTS, non la pagina verso la quale viene reindirizzato.
Aggiungere il Vostro Sito alla Lista di Precaricamento HSTS
Ci sono due modi per aggiungere il vostro sito alla lista di precaricamento HSTS.
- Inviando il vostro sito a un elenco di liste di precaricamento HSTS. Ad esempio, la master list di hstspreload.org è mantenuta dal progetto open source Chromium ed è utilizzata dalla maggior parte dei principali browser (Firefox, Chrome, Safari, IE 11 e Edge).
- Aggiungendo il seguente campo di intestazione al vostro sito:
Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
Con il secondo metodo, la prima visita al vostro sito da parte del browser non sarà completamente sicura. Le visite successive, invece, saranno completamente sicure.
È possibile utilizzare uno strumento online gratuito come gli header di sicurezza per verificare se il vostro sito applica l’HSTS. Se siete preoccupati per il supporto del browser per HSTS, potete stare tranquilli sapendo che HSTS è supportato da quasi tutti i browser in uso oggi.
Redirect HTTP 307 e SEO
Dato che una risposta 307 Temporary Redirect mostra che la risorsa si è spostata temporaneamente su un nuovo URL, i motori di ricerca non aggiornano il loro indice per includere questo nuovo URL. Il “link-juice” dell’URL originale non viene passato al nuovo URL.
Accade l’opposto che con i reindirizzamenti 301 Moved Permanently, in cui i motori di ricerca aggiornano il loro indice per includere il nuovo URL e trasmettono il “link-juice” dall’URL originale al nuovo URL.
Con una risposta 307 Internal Redirect, tutto avviene a livello di browser. Non dovrebbe quindi esserci alcun effetto diretto sulla SEO del vostro sito. Tuttavia, l’aggiunta del vostro sito a una lista di precaricamento HSTS lo rende più veloce e più sicuro, il che può aiutarlo a posizionarsi più in alto nei risultati di ricerca.
Fate attenzione a non reindirizzare inavvertitamente utenti e bot in un loop di reindirizzamento infinito, causando l’errore ‘too many redirects‘.
Sommario
Il reindirizzamento URL consente di assegnare più di un indirizzo URL a una pagina web. Il modo migliore per gestire i reindirizzamenti URL è a livello di server con le risposte HTTP di reindirizzamento 3xx. Se il vostro sito non è disponibile per manutenzione o non è disponibile per altri motivi, potete reindirizzarlo temporaneamente a un altro URL con una risposta 307 Temporary Redirect.
Detto questo, qualsiasi reindirizzamento aggiunge ritardo al tempo di caricamento delle pagine. Quindi, utilizzate i reindirizzamenti tenendo sempre presente l’esperienza dell’utente finale.
