 |
Quando si comunica tramite il protocollo HTTP (HyperText Transfer Protocol), i server rispondono con status code per indicare l'esito della richiesta effettuata da un client (come un browser).
Questi codici sono suddivisi in cinque famiglie, ciascuna con un significato preciso.
🔵 1xx – Informativi
Questa famiglia di codici indica che la richiesta è stata ricevuta e il processo è in corso. Sono raramente visibili lato utente, ma possono essere utili nel dialogo tra client e server.
100 Continue
Descrizione: Il server ha ricevuto l'inizio della richiesta e il client può continuare con l'invio del corpo della richiesta.
Esempio: Un client sta caricando un file grande e invia un'intestazione Expect: 100-continue. Il server risponde con 100 Continue per confermare che può procedere con l'invio del contenuto.
101 Switching Protocols
Descrizione: Il server accetta di cambiare protocollo come richiesto dal client.
Esempio: Un client chiede di passare da HTTP a WebSocket, e il server conferma con questo codice.
🟢 2xx – Successo
🔹 200 OK
Descrizione: La richiesta è stata elaborata correttamente dal server e viene restituita una risposta con eventuali dati.
Esempio: Un client invia una richiesta GET /api/users/123 per ottenere i dati dell’utente con ID 123.
Il server risponde:
HTTP/1.1 200 OK
Content-Type: application/json
{
"id": 123,
"name": "Marco Rossi",
"email": "marco@example.com"
}
Questo status code è anche usato per risposte PUT, POST o DELETE quando non è necessario specificare un altro codice.
🔹 201 Created
Descrizione: Una nuova risorsa è stata creata con successo. L’intestazione Location può indicare l’URL della nuova risorsa.
Esempio: Un’applicazione client invia una richiesta POST /api/articles con il corpo della richiesta:
{
"title": "Guida agli HTTP status code",
"author": "Alice Bianchi"
}Il server crea l’articolo e risponde:
HTTP/1.1 201 Created
Location: /api/articles/457
Content-Type: application/json
{
"id": 457,
"title": "Guida agli HTTP status code",
"author": "Alice Bianchi"
}
🔹 202 Accepted
Descrizione: La richiesta è stata ricevuta e accettata, ma non ancora completata.
Esempio: Un utente invia un POST a /api/reports/generate per generare un report.
Il server risponde:
HTTP/1.1 202 Accepted
Content-Type: application/json
{
"message": "La generazione del report è stata avviata.",
"reportId": "rep-9021"
}
Il client può poi verificare lo stato del report con un’altra richiesta (GET /api/reports/status/rep-9021).
🔹 204 No Content
Descrizione: La richiesta è andata a buon fine, ma non c'è nulla da restituire nel corpo della risposta.
Esempio: Un client invia una richiesta DELETE /api/comments/55 per cancellare un commento.
Il server risponde:
HTTP/1.1 204 No Content
Non viene restituito alcun corpo perché l’operazione è stata completata e non ci sono dati aggiuntivi.
🔹 206 Partial Content
Descrizione: Il server restituisce solo una parte della risorsa, di solito in risposta a una richiesta con intestazione Range.
Esempio: Un client richiede i primi 500 byte di un video:
GET /video.mp4
Range: bytes=0-499
>Il server risponde:
>HTTP/1.1 206 Partial Content
Content-Range: bytes 0-499/10000
Content-Type: video/mp4
Questo è tipico nei download progressivi, come player video o resumable downloads.
🟡 3xx – Redirezioni
Indicano che il client deve compiere ulteriori azioni per completare la richiesta. Solitamente vengono utilizzati per reindirizzamenti di URL.
I codici 3xx sono essenziali per la gestione delle transizioni, ottimizzazione SEO, gestione dei contenuti cache e navigazione sicura nei flussi delle applicazioni web.
〽️ 300 Multiple Choices
Descrizione: La risorsa richiesta ha più rappresentazioni valide e il server fornisce un elenco di opzioni tra cui scegliere.
Esempio: Una richiesta a /video potrebbe restituire sia /video.mp4 che /video.webm. Il server risponde con un elenco e codice 300.
〽️ 301 Moved Permanently
Descrizione: La risorsa richiesta è stata spostata in modo permanente a una nuova URL.
Esempio: Un sito sposta i contenuti da http://example.com a https://www.example.com. Le richieste a http://example.com ricevono 301 e l'header Location: https://www.example.com.
〽️ 302 Found
Descrizione: La risorsa richiesta risiede temporaneamente in una nuova posizione.
Esempio: L'accesso a /dashboard da utente non autenticato causa redirect a /login con codice 302, ma la posizione non è definitiva.
〽️ 303 See Other
Descrizione: Il client deve eseguire una richiesta GET a un'altra URL per ottenere la risorsa.
Esempio: Dopo aver inviato un ordine tramite POST a /order, il server risponde 303 See Other con Location: /order/confirmation.
〽️ 304 Not Modified
Descrizione: Indica che la versione cache della risorsa è ancora valida; nessun dato verrà ritrasmesso.
Esempio: Il browser richiede /style.css con l'header If-Modified-Since: [data]. Se il file non è cambiato, il server restituisce 304.
〽️ 305 Use Proxy (Deprecato)
Descrizione: Indica che la risorsa richiesta è disponibile solo tramite un proxy specifico.
Esempio: Oggi non è più usato per motivi di sicurezza.
〽️ 306 (Unused)
Descrizione: Riservato; non è più utilizzato.
Esempio: Non ha applicazione pratica attuale.
〽️ 307 Temporary Redirect
Descrizione: Reindirizzamento temporaneo in cui il metodo HTTP originale deve essere preservato.
Esempio: POST a /pay restituisce 307 verso /maintenance, e il client ripete la POST.
〽️ 308 Permanent Redirect
Descrizione: Come 301, ma forza il client a mantenere il metodo HTTP originale.
Esempio: Un'API depreca /v1/data in favore di /v2/data e risponde con 308 per tutte le chiamate a /v1/data.
🟠 4xx – Errori del Client
Indicano che la richiesta inviata dal client presenta un errore. Potrebbe trattarsi di un errore sintattico, di autorizzazione o di mancata disponibilità della risorsa.
I codici 4xx sono fondamentali per gestire con precisione gli errori lato client, proteggere le risorse e restituire feedback chiari per migliorare l’esperienza utente e la sicurezza.
🔸 400 Bad Request
Descrizione: La sintassi della richiesta è errata o non interpretabile.
Esempio: Un'app invia un JSON malformato a /api/login:
POST /api/login
Content-Type: application/json
{ username: "mario" password: "pwd" }Risposta:
HTTP/1.1 400 Bad Request🔸 401 Unauthorized
Descrizione: La richiesta richiede un'autenticazione utente, ma non è stata fornita o è fallita.
Esempio: Una richiesta a /api/profile senza token di accesso restituisce:
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer🔸 403 Forbidden
Descrizione: Il server ha compreso la richiesta ma si rifiuta di autorizzarla.
Esempio: Un utente non amministratore accede a /admin/settings.
🔸 404 Not Found
Descrizione: La risorsa richiesta non è stata trovata sul server.
Esempio: L'utente accede a /api/products/9999, ma l'ID non esiste nel database.
🔸 405 Method Not Allowed
Descrizione: Il metodo HTTP usato non è consentito per l'endpoint.
Esempio: Si invia una richiesta POST a un endpoint che accetta solo GET.
🔸 406 Not Acceptable
Descrizione: Il server non è in grado di restituire una risposta che soddisfi le intestazioni Accept della richiesta.
Esempio: Il client invia:
Accept: application/xmlma il server può restituire solo JSON → 406.
🔸 409 Conflict
Descrizione: C'è un conflitto con lo stato attuale della risorsa. Esempio: Due utenti modificano simultaneamente un profilo e inviano aggiornamenti incoerenti.
🔸 410 Gone
Descrizione: La risorsa non è più disponibile e non tornerà. Esempio: Una pagina è stata rimossa in modo permanente, e il server vuole segnalare che non verrà ripristinata.
🔸 415 Unsupported Media Type
Descrizione: Il tipo di contenuto della richiesta non è supportato dal server.
Esempio: L'app invia una richiesta con Content-Type: text/csv a un endpoint che accetta solo JSON.
🔸 422 Unprocessable Entity
Descrizione: I dati della richiesta sono ben formati ma semanticamente errati. Esempio: L'utente invia un modulo con un campo email mancante:
POST /register
{
"username": "giulia"
}Risposta:
HTTP/1.1 422 Unprocessable Entity🔸 429 Too Many Requests
Descrizione: Il client ha effettuato troppe richieste in un tempo troppo breve (rate limiting).
Esempio: Un bot invia centinaia di richieste a /api/search in pochi secondi oppure quando c'è un loop infinito di redirect (magari perchè ci sono stati errori nel configurare i codici 3xx creando redirect che puntano ad altre redirect).
🔴 5xx – Errori del Server
I codici 5xx indicano problemi lato server e aiutano i client e gli sviluppatori a distinguere tra errori di rete, malfunzionamenti temporanei e funzionalità non disponibili.
500 Internal Server Error
Descrizione: Errore generico del server. Qualcosa è andato storto, ma non è specificato.
Esempio: Un'applicazione lancia un'eccezione non gestita durante l'elaborazione di una richiesta a /checkout.
501 Not Implemented
Descrizione: Il server non supporta la funzionalità richiesta.
Esempio: Il client invia una richiesta con metodo PATCH, ma il server non lo ha implementato.
502 Bad Gateway
Descrizione: Il server agisce come gateway/proxy e riceve una risposta non valida dal server upstream.
Esempio: Un reverse proxy invia una richiesta a un backend spento o non configurato correttamente.
503 Service Unavailable
Descrizione: Il server è temporaneamente non disponibile, spesso per manutenzione o sovraccarico.
Esempio: Durante l’aggiornamento di un sito, tutte le richieste restituiscono 503.
504 Gateway Timeout
Descrizione: Il server agisce come gateway e non riceve risposta in tempo dal server upstream.
Esempio: Un server API remoto è lento o non risponde entro il timeout previsto dal gateway.
505 HTTP Version Not Supported
Descrizione: Il server non supporta la versione HTTP usata nella richiesta.
Esempio: Il client utilizza HTTP/0.9 o una versione sconosciuta.
🎯 Tabelle riassuntive
📋 Riepilogo
| Famiglia | Codice | Descrizione |
|---|---|---|
| 1xx | Informational | Richieste ricevute, il server continua l'elaborazione |
| 2xx | Success | La richiesta è stata completata con successo |
| 3xx | Redirection | Il client deve compiere ulteriori azioni (es. redirect) |
| 4xx | Client Error | Errori nella richiesta imputabili al client |
| 5xx | Server Error | Errori del server durante l'elaborazione della richiesta |
⚙️ Uso tipico
| Famiglia | Codice | Uso tipico |
|---|---|---|
| 1xx | Informational | Utilizzati in protocolli avanzati, es. `100 Continue` |
| 2xx | Success | Confermare azioni riuscite: login, creazione risorsa, salvataggio |
| 3xx | Redirection | Gestione dei reindirizzamenti e caching (es. `301`, `302`, `304`) |
| 4xx | Client Error | Gestione degli errori lato utente: 404, 401, 422, 429 |
| 5xx | Server Error | Indicazione di errori interni del server o malfunzionamenti |
Conclusione
Comprendere gli HTTP status code è fondamentale per sviluppare, testare e mantenere applicazioni web. Offrono una comunicazione chiara tra client e server e aiutano a identificare velocemente problemi o confermare il successo di una richiesta.
Follow me #techelopment
Official site: www.techelopment.it
facebook: Techelopment
instagram: @techelopment
X: techelopment
Bluesky: @techelopment
telegram: @techelopment_channel
whatsapp: Techelopment
youtube: @techelopment
