Cos'e HTTP 308 Permanent Redirect
Il codice HTTP 308 Permanent Redirect, definito nella RFC 7538, indica che la risorsa e stata spostata definitivamente al nuovo URL e che il client deve preservare il metodo HTTP originale nella nuova richiesta. E la versione "metodo-safe" del 301.
Il gap colmato dal 308
Storicamente i quattro redirect erano:
- 301 Moved Permanently: ambiguo sul metodo, browser convertono POST -> GET.
- 302 Found: stessa ambiguita del 301 ma temporaneo.
- 303 See Other: forza GET, temporaneo.
- 307 Temporary Redirect: preserva metodo, temporaneo.
Mancava un'equivalente permanente del 307. Il 308 colma questo gap: redirect permanente che preserva strettamente metodo e body.
308 vs 301: confronto
| Aspetto | 301 | 308 |
|---|---|---|
| Permanenza | Si | Si |
| Preserva metodo | De facto no (POST -> GET) | Si, garantito |
| SEO ranking transfer | Si | Si |
| Browser cache | Aggressiva | Aggressiva |
| Supporto browser | Universale | Moderno (post 2014) |
Quando usare il 308
- Migrazione permanente API: spostare endpoint senza forzare client a riconvertire POST in GET.
- Restructuring URL in API REST dove i metodi devono essere preservati.
- Mirror permanenti: redirect di servizi terzi mantenendo il payload originale.
- Versioning API: passaggio definitivo da /v1 a /v2 mantenendo POST/PUT/DELETE intatti.
308 in API REST
POST /api/v1/users HTTP/1.1
Content-Type: application/json
{"name": "Mario", "email": "m@example.com"}
HTTP/1.1 308 Permanent Redirect
Location: /api/v2/users
Il client continua come POST verso /api/v2/users con lo stesso body. Tutti i futuri request vengono diretti automaticamente al nuovo endpoint senza modifiche al codice client.
Esempio Nginx
location /api/v1/ {
rewrite ^/api/v1/(.*)$ /api/v2/$1 permanent;
# Oppure esplicito 308:
return 308 /api/v2/$uri;
}
Attenzione: il modificatore permanent di Nginx genera 301, non 308. Per il 308 usa return 308 esplicito.
Esempio Apache
Apache 2.4+ supporta 308 esplicito tramite RedirectMatch o RewriteRule con codice:
RewriteRule ^/api/v1/(.*)$ /api/v2/$1 [R=308,L]
Compatibilità browser
- Chrome: dalla versione 34 (2014).
- Firefox: dalla versione 14 (2012).
- Safari: dalla versione 7 (2013).
- Edge: tutte le versioni Chromium-based.
- IE11: non supportato. Cade in fallback su 302-like.
Per applicazioni pubbliche con utenti su IE11, valutare 301 come fallback più sicuro.
SEO impact
Google ha confermato di trattare 301 e 308 in modo equivalente per il trasferimento del ranking. Da maggio 2016 entrambi consolidano segnali SEO sulla pagina di destinazione. Bing e altri motori si sono allineati progressivamente.
Differenza pratica per scrivere API public
Per un sito web tradizionale (utenti che navigano via GET) il 308 e equivalente al 301. La differenza emerge in:
- API REST consumate da client che fanno POST/PUT/DELETE.
- Form HTML submit con action su URL redirezionato.
- Webhook che inviano POST a endpoint da deprecare.
In tutti questi casi il 308 e più sicuro perché elimina il rischio che il client perda dati nella conversione del metodo.
Diagnostica con curl
curl -X POST -d "key=value" -i -L'https://example.com/old-endpoint
Con -L curl segue il redirect mantenendo POST. Con -v visualizzi la sequenza completa.
Best practice
- Per redirect HTTP -> HTTPS o www handling: 301 (universale).
- Per API REST permanenti: 308 (sicuro su POST/PUT).
- Per migrazioni dominio con utenti su browser moderni: 308.
- Per compatibilità massima legacy: 301 con possibile perdita di body in POST.
308 e migrazioni progressive
Durante una migrazione di endpoint, puoi adottare strategia a fasi: prima introduci il nuovo endpoint /api/v2/, poi configuri 308 su /api/v1/ verso /api/v2/, monitori errori. Dopo grace period (es. 6 mesi), rimuovi 308 e ritorni 410 Gone. Client si adattano gradualmente senza rotture brusche.
Compatibilità con webhook
I client che inviano webhook devono gestire 308 mantenendo POST. La maggior parte dei librerie HTTP moderne (axios, requests Python, RestClient Ruby) lo fa correttamente. Per client homemade o legacy, testare prima di rebrand.
308 in microservizi
In architetture a microservizi, quando uno service viene rimpiazzato da uno nuovo, l'API gateway puo emettere 308 verso il nuovo target permanente. I client (interni e esterni) si redirigono mantenendo il metodo. Riduce drastically i breaking change.
Test fallback per IE
Se servi pubblico con possibile Internet Explorer, monitora analytics: percentuale IE bassa? Usa 308 in sicurezza. Percentuale rilevante? Configurare fallback: 308 per UA moderni, 301 per IE detectato via User-Agent sniffing.
Best practice per documentazione
OpenAPI/Swagger 3.x supporta documentare i redirect: includi una nota per ogni endpoint deprecato che indica il successor. Strumenti di code generation (openapi-generator) produrranno SDK con redirect-following abilitato.
308 e crawl budget
Per siti grandi, il crawl budget di Googlebot e limitato. Catene lunghe di 308 (A -> B -> C -> D) consumano budget senza valore. Best practice: redirect diretti A -> D, evitando intermediate hops. Tool come Screaming Frog evidenziano catene lunghe.
308 in Kubernetes ingress
Ingress controllers come Nginx-Ingress e Traefik possono emettere 308 nativamente per redirect HTTP -> HTTPS, www handling, ecc. Configurazione tipica via annotation: nginx.ingress.kubernetes.io/ssl-redirect: "true" con codice configurabile.
SDK considerations
Quando rilasci un SDK pubblico (Python, JS, Go), considera che vecchie versioni client useranno endpoint vecchi a lungo. 308 ti permette di garantire backward compatibility: rinominate endpoint, mantieni 308 per anni come safety net.
Misurare l'impatto SEO
Google Search Console mostra le redirect chain nella sezione URL Inspection. Verifica che 308 vengano correttamente classificate come "Permanent redirect (308)" e che il ranking si stia trasferendo (impressions su nuova URL crescono, su vecchia decrescono).
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.