HTTP 307 Temporary Redirect: vs 302

Cos'e HTTP 307 Temporary Redirect

Il codice HTTP 307 Temporary Redirect indica che la risorsa risiede temporaneamente a un'URL diverso, ma con un vincolo importante: il client deve preservare il metodo HTTP originale. Se la richiesta era POST, anche il redirect e POST. Se PUT, rimane PUT.

Il problema risolto dal 307

Storicamente il 302 era ambiguo: la RFC originale diceva di preservare il metodo, ma i browser convertivano POST in GET. Per risolvere l'ambiguita sono stati introdotti due codici nuovi:

• 303 See Other: forza GET (formalizza il comportamento de facto del 302).
• 307 Temporary Redirect: preserva strettamente il metodo (intento originale del 302).

307 vs 302: confronto pratico

Quando usare il 307

• API che ricevono POST e devono temporaneamente spostarlo su altro server.
• Load balancing: redirect runtime a un nodo specifico mantenendo body e metodo.
• Migrazione progressiva: spostare endpoint senza forzare client a ripetere logica.
• Manutenzione mirror: deviare temporaneamente le scritture su un secondario.

Esempio: redirect POST

POST /api/v1/orders HTTP/1.1
Content-Type: application/json
Content-Length: 123

{"product": "ABC", "qty": 1}

HTTP/1.1 307 Temporary Redirect
Location: https://api2.example.com/v1/orders

Il client rifa POST verso il nuovo URL mantenendo lo stesso body. Con un 302, alcuni client trasformerebbero in GET perdendo i dati.

Implementazione Nginx

location /api/heavy/ {
    if ($http_x_overload = "1") {
        return 307 https://backup.example.com$request_uri;
    }
    proxy_pass http://upstream;
}

Implementazione Express.js

app.all('/api/v1/*', (req, res, next) => {
    if (shouldRedirectToV2()) {
        return res.redirect(307, '/api/v2' + req.path);
    }
    next();
});

HSTS preload e 307

I browser moderni emettono un 307 interno quando applicano HSTS: prima ancora di fare la richiesta HTTP, il browser nota che il dominio e in HSTS preload list e converte la URL in HTTPS internamente. In DevTools puoi vedere "307 Internal Redirect" generato dal browser.

307 vs 308

Il 307 e temporaneo, il 308 e permanente. Entrambi preservano il metodo. La tabella completa:

Compatibilità

Tutti i browser moderni supportano correttamente il 307 dal 2010. Le librerie HTTP (Python requests, Go net/http, axios) lo gestiscono nativamente. Per client legacy molto vecchi potrebbe esserci comportamento incerto: testa sempre la tua catena.

Cache e SEO

Le risposte 307 non sono cacheable per default. Dal punto di vista SEO sono trattate come temporanee: non trasferiscono ranking. Per cambi permanenti di endpoint pubblici, scegli 308 o 301.

Diagnostica

curl -X POST -d "test=1" -i -L'https://example.com/api/endpoint

Aggiungi -v per vedere la sequenza completa di redirect. Con --post301, --post302, --post303 puoi forzare comportamenti specifici per testing.

HSTS preload e 307 interno

Quando un dominio e in HSTS preload list di Chrome/Firefox, il browser converte internamente le URL HTTP in HTTPS prima ancora di fare la richiesta. In DevTools vedi "307 Internal Redirect" che NON e una vera risposta del server: e il browser che si redirige da solo. Importante distinguere questa pseudo-302 dai veri 307 emessi dal server.

307 in load balancer geografici

Alcuni LB globali usano 307 per redirezionare temporaneamente client al nodo regionale più vicino. La temporaneita e importante: domani il routing potrebbe cambiare (es. failover). Il 307 preserva POST/PUT/DELETE, vitale per API che ricevono webhook con body.

307 vs 302: bug famosi

Webhook providers (Stripe, GitHub, Slack) usano POST per inviare payload. Se il tuo endpoint risponde 302 invece di 307, il webhook potrebbe convertirsi in GET e perdere il body. Sempre usare 307 per redirezionare endpoint che ricevono webhook.

Browser compliance

Tutti i browser moderni rispettano 307 correttamente. Versioni vintage di IE potevano avere comportamenti scorretti. Per API public che servono client legacy, considerare di aggiungere logging quando si emette 307 e verificare il behavior reale via analytics.

Test con curl

curl -X POST -d "test=1" -i -L --post307 https://example.com/api/endpoint

L'opzione --post307 forza curl a mantenere POST dopo redirect 307, comportamento standard. Senza essa, versioni vecchie di curl convertivano in GET.

Casi d'uso webhook providers

Stripe, GitHub, Slack inviano webhook via POST. Se il tuo endpoint riceve un 307 redirect, il client webhook deve mantenere POST. La maggior parte dei moderni client webhook lo fa correttamente, ma alcuni vecchi convertono in GET. In tal caso, perde i body del webhook.

307 in CDN failover

Durante manutenzione di un nodo CDN, il sistema puo emettere 307 verso il nodo backup. La temporaneita evita che browser cachano il backup come permanente. Combinato con DNS TTL bassi, manutenzione zero-downtime.

Test fetch API

const res = await fetch('/api/redirect-test', {
    method: 'POST',
    body: 'test',
    redirect: 'follow'
});

Default redirect: 'follow' segue automaticamente. Con redirect: 'manual' puoi ispezionare la risposta 307 prima di seguire.

Sequence diagrams

Per debugging redirect complessi, usa Wireshark o Chrome DevTools Network panel. Visualizzano la sequenza completa: request iniziale, risposta 307, request al nuovo target con stesso metodo, risposta finale. Utile per individuare hop che corrompono il metodo.

Hai bisogno di aiuto?

Se il tuo sito mostra errori HTTP, il team di G Tech Group puo aiutarti. Contattaci tramite il modulo di contatto.