{"id":32369,"date":"2026-01-19T09:00:00","date_gmt":"2026-01-19T08:00:00","guid":{"rendered":"https:\/\/www.serverplan.com\/blog\/?p=32369"},"modified":"2026-01-18T16:21:00","modified_gmt":"2026-01-18T15:21:00","slug":"codice-stato-http-204","status":"publish","type":"post","link":"https:\/\/www.serverplan.com\/blog\/codice-stato-http-204\/","title":{"rendered":"204 (No Content): cos’\u00e8 questo status code HTTP?"},"content":{"rendered":"\n

Lo status code HTTP<\/a> 204 (No Content) \u00e8 una condizione da valutare con attenzione. Conosciamo gi\u00e0 una serie di condizioni problematiche legate ai codici numerici <\/strong>che descrivono lo status di un portale: tutti quelli che rientrano nell’area 4XX si configurano come errori della pagina web (come il classico errore 404<\/a> o il 410 gone<\/a>). <\/p>\n\n\n\n

\"204<\/figure>\n\n\n\n

Mentre la famiglia dei 5XX riguarda errori del server: conosciamo bene i vari errori 502 bad gateway<\/a> e 503<\/a>. Ma sappiamo anche che il prefisso 2XX si configura come il recupero della pagina web andata a buon fine: perch\u00e9 ci dobbiamo preoccupare anche del codice status 204 No Content<\/strong>? Meglio approfondire l’argomento.<\/p>\n\n\n\n

Cos’\u00e8 il codice status 204 No Content?<\/h2>\n\n\n\n

\n\n\n\n

Noi sappiamo, come anticipato, che gli status code che rientrano sotto la voce del 2XX vengono considerate azioni andate a buon fine: la pagina esiste, l’infrastruttura IT funziona<\/strong>, il browser termina il lavoro. Questo \u00e8 chiaro con il codice 200. <\/p>\n\n\n\n

Il codice HTTP 204 No Content – che rientra nello standard HTTP\/1.1 delineato in RFC 7231, Sezione 6.3.5.<\/a> – \u00e8 una risposta che il server invia quando ha processato con successo <\/strong>la richiesta, ma non ha nulla da restituire. In pratica, ti sta comunicando: “ok, tutto \u00e8 andato bene ma non ho niente da mostrarti”<\/em>. Il codice di stato 204 (nessun contenuto) indica che il server<\/a> ha soddisfatto correttamente la richiesta e che, in modo intenzionale, non ci sono contenuti aggiuntivi da inviare nel corpo della risposta.<\/p>\n\n\n\n

Da leggere: come gestire il file robots.txt<\/a><\/strong><\/p>\n\n\n\n

Come funziona questo status code?<\/h2>\n\n\n\n

Dal punto di vista dell’utente, si tratta di un passaggio che non prevede il cambio della schermata: forse ti sar\u00e0 capitato di inviare una richiesta al browser, aver aspettato il caricamento della risorsa<\/strong> ma non aver percepito alcun passaggio da una pagina web a un’altra. L’applicazione, quindi il browser, invia richiesta al server.<\/p>\n\n\n\n

Il server la elabora e prepara la risposta<\/strong>: se quest’ultima non prevede alcun cambiamento – non ha contenuto nel body – il server stesso preferisce lo status code 204. Tutto \u00e8 andato bene ma non c’\u00e8 altro da comunicare. <\/p>\n\n\n\n

Il client rimane sulla stessa pagina e l’utente non percepisce variazioni. Quindi, \u00e8 importante ricordare che non si tratta di un errore o di una scelta che puoi fare in autonomia<\/strong>: \u00e8 il server a decidere di puntare sull’HTTP 204.<\/p>\n\n\n\n

Quando utilizzare un codice di stato 204?<\/h2>\n\n\n\n

Il codice di stato 204 (No Content) si usa quando una richiesta va a buon fine ma non c\u2019\u00e8 niente da restituire al client. Succede spesso nelle API: fai un\u2019azione, il server la esegue<\/strong> correttamente, fine del processo. <\/p>\n\n\n\n

Se aggiorni il profilo di un utente con una richiesta PUT<\/strong> e non ti serve ricevere indietro i dati aggiornati, il 204 \u00e8 la risposta adeguata: tutto ok, non c\u2019\u00e8 altro da leggere perch\u00e9 il client magari ha gi\u00e0 tutto. Alcuni esempi?<\/p>\n\n\n\n

DELETE \/api\/tasks\/123\n\u2192 204 No Content (task cancellato, non serve altro)\n\nGET \/api\/tasks\/123  \n\u2192 200 OK + { \"id\": 123, \"title\": \"...\" } (ecco i dati)\n\nPUT \/api\/tasks\/123\n\u2192 204 No Content (aggiornato, il client ha gi\u00e0 i dati)\noppure\n\u2192 200 OK + { \"id\": 123, \"title\": \"...\" } (aggiornato + ecco la versione finale)<\/code><\/pre>\n\n\n\n
Stesso discorso quando elimini una risorsa con DELETE<\/strong>: l\u2019elemento \u00e8 stato cancellato, non ha senso mandare un messaggio di conferma o un JSON vuoto. Il server conferma che l’operazione \u00e8 andata a buon fine. Anche il POST per azioni ha un senso quando premi un pulsante salva preferenze o segna come letto. <\/em><\/p>\n\n\n\n
L’azione \u00e8 completata, ma non serve una risposta con dati. In pratica, ogni volta che il client deve solo sapere che l\u2019operazione \u00e8 riuscita, e non deve usare nessun dato di risposta per aggiornare l\u2019interfaccia o lo stato, il 204 No Content \u00e8 la scelta giusta. Perch\u00e9 \u00e8 chiaro, lineare, senza rumore inutile.<\/p>\n\n\n\n
Qual \u00e8 la differenza tra codice 200 e 204?<\/h2>\n\n\n\n
La differenza tra questi status code HTTP<\/strong>: in entrambi i casi l’azione va a buon fine ma nel 200 OK – lo status pi\u00f9 comune per GET requests<\/code> dove chiedi dei dati, li ricevi – la richiesta \u00e8 riuscita ti sto restituendo dei dati. Quindi, il body della risposta contiene qualcosa, probabilmente del codice HTML ma non per forza. <\/p>\n\n\n\n
Nel 204 No Content la richiesta \u00e8 riuscita ma non c’\u00e8 niente. Il body \u00e8 vuoto ed \u00e8 pi\u00f9 efficiente quando non servono dati di ritorno<\/strong>: risparmi banda e segnala al client che non c’\u00e8 errore<\/strong>, non devi aspettarti nulla.<\/p>\n\n\n\n
Da leggere: come funziona l\u2019FTP e a cosa serve<\/a><\/strong><\/p>\n\n\n\n
Alcuni vantaggi concreti di status 204<\/h2>\n\n\n\n
L’uso di uno status code corretto, al momento giusto, \u00e8 gi\u00e0 di per s\u00e9 un vantaggio in termini di coerenza strutturale. Poi, con il 204 abbiamo un risparmio di banda<\/strong> che pu\u00f2 essere pi\u00f9 o meno importante perch\u00e9 non invii un body. Per\u00f2 se stavi per mandare un JSON tipo {\"success\": true}<\/code> di 17 bytes, il risparmio \u00e8 minimo. <\/p>\n\n\n\n
<\/div>
Hosting gestito: veloce, affidabile, performante<\/p>