413 Request Entity Too Large: cause e soluzioni

Cosa significa 413 Payload Too Large

RFC 9110 definisce il nome attuale come 413 Content Too Large, anche se sia 413 Payload Too Large sia il più vecchio 413 Request Entity Too Large si riferiscono allo stesso codice di stato e compaiono ancora su server, framework, e pagine di errore. Qualunque sia la dicitura, il significato è identico: la richiesta stessa era sintatticamente corretta, ma il suo corpo ha superato un limite di dimensione prima che il server accettasse di elaborarla. Questo succede più spesso sui caricamenti di file, ma può succedere su qualunque richiesta con un corpo grande, incluso un payload API bulk.

Come appare l'errore

I browser di solito mostrano qualunque pagina di errore semplice il server di origine o l'edge abbiano rimandato indietro; non esiste un'interfaccia dedicata del browser per questo come per un fallimento di connessione. È comune vederlo fallire silenziosamente in un modulo, con la risposta visibile solo nella scheda di rete, specialmente per un caricamento di file costruito con JavaScript. Dalla riga di comando, la risposta lo conferma direttamente:

curl -i -X POST -F "[email protected]" https://example.com/upload
HTTP/1.1 413 Request Entity Too Large
Content-Type: text/html

I log di accesso ed errore del server sono il posto più affidabile per confermare la dimensione esatta coinvolta e quale livello l'ha rifiutata, dato che una richiesta può essere bloccata alla CDN, al web server, o all'applicazione, e ciascuno la registra in modo diverso.

Cosa causa un 413

• client_max_body_size di nginx. Il valore predefinito è 1 MB, abbastanza piccolo che quasi qualunque caricamento di file reale lo fa scattare finché non viene esplicitamente alzato:

  client_max_body_size 20M;

• LimitRequestBody di Apache. Impostato per directory o globalmente, e, come nginx, per impostazione predefinita ha una dimensione che molte applicazioni superano senza che nessuno l'abbia cambiata di proposito.
• upload_max_filesize e post_max_size di PHP. Due impostazioni separate in php.ini che devono essere entrambe abbastanza grandi per il caricamento; post_max_size deve essere almeno grande quanto upload_max_filesize o la seconda impostazione limita silenziosamente la prima.
• maxAllowedContentLength di IIS. Impostato in web.config sotto requestLimits, con un valore predefinito di circa 30 MB, e separato dall'impostazione maxRequestLength propria di ASP.NET, che usa unità diverse e deve essere alzata insieme ad essa.
• Il limite di caricamento basato sul piano di Cloudflare. I piani Free e Pro limitano la dimensione del corpo della richiesta a 100 MB indipendentemente da ciò che il server di origine altrimenti accetterebbe, e questo limite non può essere alzato dalla configurazione stessa dell'origine; deve essere affrontato dal lato Cloudflare o aggirato con un percorso di caricamento diretto che bypassa il proxy.
• Limiti di payload del gateway API. I gateway API gestiti tipicamente limitano i corpi delle richieste ben al di sotto di quanto permetterebbe un tradizionale web server, spesso a pochi megabyte, il che coglie di sorpresa i team che migrano una funzione di caricamento esistente dietro un nuovo gateway.

Come capire di chi è la colpa

Questo quasi mai è colpa di un visitatore nel senso di aver fatto qualcosa di sbagliato; il file che sta caricando è semplicemente più grande di un limite che esiste da qualche parte nella catena, e la correzione appartiene a chiunque possieda quel livello. Se lo stesso file si carica bene su un ambiente e fallisce su un altro, confronta ogni livello nel percorso della richiesta, dato che nginx, PHP, e una CDN possono avere ciascuno un limite diverso e il più piccolo vince. Eseguire un controllo HTTP con un corpo di richiesta vicino al tuo limite previsto, inviato da fuori la tua rete, conferma qual è effettivamente il tetto massimo end to end invece di affidarsi a un singolo file di configurazione.

Come correggere un errore 413

Se sei un visitatore

1. Comprimi il file prima di caricarlo, specialmente immagini e video, che spesso si riducono drasticamente senza perdita di qualità visibile alle dimensioni tipiche.
2. Dividi un caricamento grande in pezzi più piccoli se il sito supporta caricamenti a blocchi o ripristinabili, invece di inviare una richiesta molto grande.
3. Controlla il limite di caricamento dichiarato dal sito se ne è pubblicato uno, dato che alcuni 413 funzionano come previsto e la correzione è semplicemente un file più piccolo.

Se gestisci il sito

1. Alza il limite di ogni livello insieme, non solo uno. Una singola richiesta tipicamente passa attraverso una CDN, un web server, e un runtime applicativo, e il limite più piccolo configurato ovunque in quella catena determina il tetto effettivo.
2. Imposta esplicitamente nginx e Apache invece di affidarti ai valori predefiniti:

   # nginx
   client_max_body_size 20M;
   
   # Apache
   LimitRequestBody 20971520

3. Fai corrispondere le due impostazioni di PHP. Alza sia upload_max_filesize sia post_max_size, e assicurati che la seconda sia uguale o maggiore della prima.
4. Aggiorna insieme requestLimits di IIS e maxRequestLength di ASP.NET in web.config, dato che misurano la stessa cosa in unità diverse ed entrambe devono essere alzate.
5. Aggira il limite del piano di Cloudflare per file davvero grandi caricando direttamente nello storage con un URL firmato, bypassando del tutto il percorso di richiesta in proxy, invece di provare ad alzare un limite che quel livello di piano non espone.
6. Controlla il limite di payload del gateway API stesso separatamente dal servizio backend se ce n'è uno davanti alla tua applicazione; può rifiutare una richiesta prima che le tue stesse impostazioni applicative, più generose, abbiano mai la possibilità di applicarsi.

Come prevenire che un 413 blocchi utenti reali

Un limite impostato troppo basso è facile da perdere finché qualcuno con un file grande non lo colpisce, e a quel punto sembra una funzione di caricamento rotta piuttosto che un mismatch di configurazione. Un controllo HTTP pianificato che invia una richiesta vicino al tuo limite di dimensione previsto, con un'asserzione sul codice di stato atteso, conferma che l'intera catena la accetti ancora dopo qualunque cambiamento alla CDN, al web server, o alla configurazione applicativa. Combinato con il monitoraggio da più postazioni, coglie anche un limite a livello di CDN che si applica solo su certi nodi edge.

Errori correlati

Vedi 400 Bad Request, che alcuni server restituiscono invece di 413 per la stessa condizione di corpo sovradimensionato, la panoramica 4xx per la famiglia più ampia, e 406 Not Acceptable altrove in questo lotto.

Domande frequenti

413 Payload Too Large è la stessa cosa di 413 Request Entity Too Large?

Sì. RFC 9110 ha rinominato il testo di stato in 413 Content Too Large, ma entrambi i nomi più vecchi si riferiscono allo stesso identico codice di stato e significato, e tutte e tre le formulazioni compaiono ancora in circolazione a seconda della versione del software server.

Perché il mio caricamento fallisce anche se ho alzato client_max_body_size di nginx?

Un altro livello nella catena, comunemente post_max_size di PHP, un limite fisso del piano di una CDN, o un gateway API, probabilmente sta imponendo un limite più piccolo indipendentemente. Ogni livello tra il client e l'applicazione deve permettere quella dimensione, non solo quello che hai cambiato.

Posso alzare il limite di 100 MB di Cloudflare sul piano gratuito o pro?

Non dalla configurazione stessa del server di origine; quel tetto è fisso per livello di piano. La soluzione abituale è caricare i file grandi direttamente nello storage usando un URL firmato che bypassa il percorso di richiesta in proxy.

Il 413 conta come un blocco di sicurezza?

Tipicamente no. Di solito è un semplice limite di risorse piuttosto che una regola difensiva, anche se alcuni WAF usano corpi insolitamente grandi come uno dei diversi segnali quando decidono se bloccare una richiesta.

Qual è un limite di caricamento predefinito ragionevole se non ne ho impostato uno?

Non esiste un numero universale; dipende interamente da ciò che la tua applicazione ha legittimamente bisogno di accettare. Impostalo deliberatamente in base al file legittimo più grande che ti aspetti invece di lasciare il valore predefinito di ogni livello.