413 Request Entity Too Large: oorzaken en oplossingen

Wat 413 Payload Too Large betekent

RFC 9110 definieert de huidige naam als 413 Content Too Large, al verwijzen zowel het oudere 413 Payload Too Large als 413 Request Entity Too Large naar dezelfde statuscode en komen ze nog steeds voor bij servers, frameworks, en foutpagina's. Wat de bewoording ook is, de betekenis is identiek: het verzoek zelf was syntactisch prima, maar de body ervan overschreed een groottelimiet voordat de server hem accepteerde voor verwerking. Dit gebeurt het vaakst bij bestandsuploads, maar het kan bij elk verzoek met een grote body gebeuren, ook een bulk-API-payload.

Hoe de fout verschijnt

Browsers tonen meestal de eenvoudige foutpagina die de origin-server of edge teruggeeft; er is geen speciale browser-UI hiervoor zoals bij een verbindingsstoring. Het komt vaak voor dat dit stilzwijgend faalt in een formulier, waarbij het antwoord alleen zichtbaar is in het netwerktabblad, vooral bij een bestandsupload gebouwd met JavaScript. Vanaf de commandoregel bevestigt het antwoord dit rechtstreeks:

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

Toegangs- en foutlogs van de server zijn de betrouwbaarste plek om de exacte betrokken grootte te bevestigen en te zien welke laag de weigering deed, aangezien een verzoek geblokkeerd kan worden bij de CDN, de webserver, of de applicatie, en elk logt dit anders.

Wat een 413 veroorzaakt

• De client_max_body_size van nginx. De standaardwaarde is 1 MB, wat klein genoeg is dat bijna elke echte bestandsupload dit raakt totdat het expliciet wordt verhoogd:

  client_max_body_size 20M;

• De LimitRequestBody van Apache. Ingesteld per directory of globaal, en, net als bij nginx, standaard op een grootte die veel applicaties overschrijden zonder dat iemand het opzettelijk heeft gewijzigd.
• De upload_max_filesize en post_max_size van PHP. Twee aparte instellingen in php.ini die allebei groot genoeg moeten zijn voor de upload; post_max_size moet minstens even groot zijn als upload_max_filesize, anders begrenst de tweede instelling de eerste stilzwijgend.
• De maxAllowedContentLength van IIS. Ingesteld in web.config onder requestLimits, standaard ongeveer 30 MB, en los van de eigen instelling maxRequestLength van ASP.NET, die andere eenheden gebruikt en er samen mee verhoogd moet worden.
• De op het abonnement gebaseerde uploadlimiet van Cloudflare. Gratis en Pro-abonnementen begrenzen de requestbody op 100 MB ongeacht wat de origin-server anders zou accepteren, en deze limiet kan niet worden verhoogd vanuit de eigen configuratie van de origin; dit moet aan de kant van Cloudflare worden aangepakt of omzeild met een directe uploadroute die de proxy overslaat.
• Payloadlimieten van een API-gateway. Beheerde API-gateways begrenzen requestbody's vaak ruim onder wat een traditionele webserver zou toestaan, vaak in de lage enkelcijferige megabytes, wat teams treft die een bestaande uploadfunctie migreren achter een nieuwe gateway.

Hoe u vaststelt wiens fout het is

Dit is bijna nooit de fout van een bezoeker in de zin dat hij iets verkeerd doet; het bestand dat hij uploadt is simpelweg groter dan een limiet die ergens in de keten bestaat, en de oplossing hoort bij wie die laag beheert. Uploadt hetzelfde bestand prima op de ene omgeving en faalt het op een andere, vergelijk dan elke laag in het verzoekpad, aangezien nginx, PHP, en een CDN elk een andere limiet kunnen hebben en de kleinste wint. Een HTTP-controle uitvoeren met een requestbody dicht bij uw beoogde limiet, verstuurd van buiten uw netwerk, bevestigt wat het effectieve plafond daadwerkelijk end-to-end is in plaats van te vertrouwen op één enkel configuratiebestand.

Hoe u een 413-fout oplost

Bent u de bezoeker

1. Comprimeer het bestand voordat u het uploadt, vooral afbeeldingen en video's, die vaak drastisch kleiner worden zonder zichtbaar kwaliteitsverlies bij gangbare groottes.
2. Splits een grote upload in kleinere delen als de site chunked of hervatbare uploads ondersteunt, in plaats van één heel groot verzoek te versturen.
3. Controleer de opgegeven uploadlimiet van de site als die gepubliceerd is, aangezien sommige 413's precies werken zoals bedoeld en de oplossing simpelweg een kleiner bestand is.

Beheert u de site

1. Verhoog de limiet van elke laag samen, niet slechts één. Eén verzoek loopt doorgaans door een CDN, een webserver, en een applicatieruntime, en de kleinste geconfigureerde limiet waar dan ook in die keten bepaalt het daadwerkelijke plafond.
2. Stel nginx en Apache expliciet in in plaats van te vertrouwen op standaardwaarden:

   # nginx
   client_max_body_size 20M;
   
   # Apache
   LimitRequestBody 20971520

3. Stem de twee instellingen van PHP op elkaar af. Verhoog zowel upload_max_filesize als post_max_size, en zorg dat de tweede gelijk aan of groter is dan de eerste.
4. Werk de requestLimits van IIS en de maxRequestLength van ASP.NET samen bij in web.config, aangezien ze hetzelfde meten in andere eenheden en beide verhoogd moeten worden.
5. Omzeil de abonnementslimiet van Cloudflare voor echt grote bestanden door rechtstreeks naar opslag te uploaden met een ondertekende URL, waarbij het geproxyde verzoekpad volledig wordt overgeslagen, in plaats van te proberen een limiet te verhogen die die abonnementslaag niet blootstelt.
6. Controleer de eigen payloadlimiet van de API-gateway los van de backend-dienst als er een voor uw applicatie staat; die kan een verzoek weigeren voordat uw eigen, ruimere, applicatie-instellingen ooit de kans krijgen om toe te passen.

Hoe u voorkomt dat een 413 echte gebruikers blokkeert

Een te laag ingestelde limiet is makkelijk te missen totdat iemand met een groot bestand hem raakt, en tegen die tijd ziet het eruit als een kapotte uploadfunctie in plaats van een mismatch in configuratie. Een geplande HTTP-controle die een verzoek verstuurt dichtbij uw beoogde groottelimiet, met een assertie op de verwachte statuscode, bevestigt dat de hele keten dit nog steeds accepteert na elke wijziging aan de CDN, webserver, of applicatieconfiguratie. In combinatie met monitoring vanaf meerdere locaties vangt dit ook een limiet op CDN-niveau op die alleen bij bepaalde edge-knooppunten geldt.

Gerelateerde fouten

Zie 400 Bad Request, wat sommige servers in plaats van 413 teruggeven bij dezelfde te-grote-body-conditie, het 4xx-overzicht voor de bredere familie, en 406 Not Acceptable elders in deze reeks.

Veelgestelde vragen

Is 413 Payload Too Large hetzelfde als 413 Request Entity Too Large?

Ja. RFC 9110 hernoemde de statustekst naar 413 Content Too Large, maar beide oudere namen verwijzen naar dezelfde statuscode en betekenis, en alle drie de bewoordingen komen nog steeds voor afhankelijk van de versie van de serversoftware.

Waarom mislukt mijn upload nog steeds terwijl ik client_max_body_size van nginx heb verhoogd?

Waarschijnlijk handhaaft een andere laag in de keten, vaak post_max_size van PHP, een vaste abonnementslimiet van een CDN, of een API-gateway, onafhankelijk een kleinere limiet. Elke laag tussen de client en de applicatie moet de grootte toestaan, niet alleen degene die u wijzigde.

Kan ik de limiet van 100 MB van Cloudflare op het gratis of pro-abonnement verhogen?

Niet vanuit de eigen configuratie van de origin-server; dat plafond ligt vast aan de abonnementslaag. De gebruikelijke omweg is grote bestanden rechtstreeks naar opslag uploaden met een ondertekende URL die het geproxyde verzoekpad omzeilt.

Telt 413 als een beveiligingsblokkade?

Meestal niet. Het is doorgaans een eenvoudige resourcelimiet in plaats van een defensieve regel, al gebruiken sommige WAF's ongewoon grote body's wel als een van de signalen bij het beslissen of een verzoek geblokkeerd moet worden.

Wat is een redelijke standaard uploadlimiet als ik er nog geen heb ingesteld?

Er is geen universeel getal; het hangt volledig af van wat uw applicatie legitiem moet kunnen accepteren. Stel het bewust in op basis van uw grootste verwachte legitieme bestand in plaats van de standaardwaarde van elke laag te laten staan.