413 Content Too Large

Verwendung

Trifft die Fehlermeldung 413 Content Too Large ein, sendet der Client einen Anfragerumpf, der für den Server zu groß ist. Ein häufiges Beispiel ist der Versuch eines Clients, eine Datei mit akzeptablem Typ und Format zu senden, die jedoch die Größenbeschränkung überschreitet. Bilder etwa liegen oft in unnötig hoher Auflösung vor und sind deutlich kleiner, ohne dass der beabsichtigte Verwendungszweck darunter leidet. Statt die Verantwortung für das Ändern der Bilddateien zu übernehmen, verweigert der Server die Übertragung und verlässt sich darauf, dass der Client die nötige Verarbeitung vornimmt.

In solchen Situationen prüft ein Client vor dem Start des PUT mithilfe des Headers Expect: 100-continue, ob die Dateigröße zulässig ist. Der Server bestätigt dies, und daraufhin wird der Nachrichtenrumpf gesendet oder zurückgehalten.

Der Server sendet optional einen Retry-After-Header in der Antwort. Ist dieser vorhanden, versucht der Client die Anfrage nach einem angegebenen Zeitraum oder zu einer angegebenen Uhrzeit und einem angegebenen Datum erneut. Hat der Client beispielsweise sein Upload-Kontingent für die Woche überschritten oder sind große Uploads während der Hauptlastzeiten nicht erlaubt, schlägt der Server einen erneuten Versuch zu einem günstigeren Zeitpunkt vor.

Tritt die Situation auf, weil dem Server der Speicherplatz ausgegangen ist, sendet der Server stattdessen 507.

Der Server fügt den Header Connection: close hinzu, um die Verbindung zu beenden und den Client daran zu hindern, den Nachrichtenrumpf zu senden.

Hinweis

WAFs und CDN-Firewalls (Cloudflare, AWS WAF) erzwingen Größenbeschränkungen für den Rumpf unabhängig vom Ursprungsserver. Prüfen Sie die WAF-/Firewall-Protokolle, wenn das Limit des Ursprungsservers über der Nutzlast liegt. Optionen zur Verringerung der Nutzlastgröße: Komprimierung mit Content-Encoding: gzip, Paginierung für große Ergebnismengen, Multipart- oder fortsetzbare Uploads für große Dateien.

SEO-Auswirkung

Suchmaschinen wie Google indexieren keine URL mit dem Antwortstatus 413. Zuvor indexierte URLs werden aus den Suchergebnissen entfernt.

Beispiel

Der Client versucht, eine Datei zu senden, und der Server antwortet mit 413 Content Too Large, weil gerade starker Datenverkehr herrscht. Der Server lehnt die Anfrage ab, schließt die Verbindung und schlägt dem Client einen erneuten Versuch nach 30 Minuten vor.

Anfrage

PUT /docs HTTP/1.1
Host: example.com
Content-Type: application/pdf
Content-Length: 10000

Antwort

HTTP/1.1 413 Content Too Large
Retry-After: 1800
Connection: close
Content-Type: text/html
Content-Length: 188

<html>
  <head>
    <title>File Too Large</title>
  </head>
  <body>
   <p>Too much server traffic to accept the transfer
   at this time. Try again after 30 minutes.</p>
  </body>
</html>

Behebung

Der Fehler stammt von derjenigen Schicht im Stack, die zuerst eine Größenbeschränkung durchsetzt: Webserver, Reverse-Proxy, CDN oder Anwendungsframework. Ermitteln Sie die Schicht, die den 413 zurückgibt, und passen Sie das Limit dort an.

nginx: Setzen Sie client_max_body_size im http-, server- oder location-Block. Ein Wert von 0 deaktiviert die Prüfung vollständig (in der Produktion nicht empfohlen). Starten Sie nginx nach der Änderung des Werts neu.

Apache: Setzen Sie LimitRequestBody in httpd.conf oder .htaccess. Der Wert wird in Bytes angegeben, 10 MB entsprechen also 10485760. Laden Sie Apache neu, damit die Änderung wirksam wird.

IIS: Bearbeiten Sie das Attribut maxAllowedContentLength in der Datei web.config unter system.webServer > security > requestFiltering > requestLimits.

PHP: Passen Sie sowohl upload_max_filesize als auch post_max_size in der php.ini an. Der Wert von post_max_size muss gleich groß wie oder größer als upload_max_filesize sein.

Node.js / Express: Setzen Sie die Option limit in body-parser oder in der integrierten JSON-/URL-kodierten Middleware von Express, z. B. express.json({ limit: ‘50mb’ }).

Cloudflare: Die Free- und Pro-Tarife begrenzen Uploads auf 100 MB, Business auf 200 MB, Enterprise auf 500 MB. Uploads, die diese Grenzen überschreiten, liefern 413 zurück, bevor sie den Ursprungsserver erreichen. Umgehen Sie für große Datei-Uploads hinter Cloudflare den Proxy oder setzen Sie Chunked-Upload-Strategien ein.

Komprimieren oder zerlegen Sie auf der Clientseite große Nutzlasten vor dem Senden. Implementieren Sie für Datei-Uploads Multipart- oder fortsetzbare Upload-Protokolle, um innerhalb der Servergrenzen zu bleiben. Nutzen Sie den Mechanismus Expect: 100-continue, um vor der Übertragung des vollständigen Rumpfs zu prüfen, ob der Server die Nutzlastgröße akzeptiert.

Code-Referenzen

.NET

HttpStatusCode.RequestEntityTooLarge

Rust

http::StatusCode::PAYLOAD_TOO_LARGE

Rails

:payload_too_large
:request_entity_too_large

http.StatusRequestEntityTooLarge

Symfony

Response::HTTP_REQUEST_ENTITY_TOO_LARGE

Python3.5+

http.HTTPStatus.REQUEST_ENTITY_TOO_LARGE

Java

java.net.HttpURLConnection.HTTP_ENTITY_TOO_LARGE

Apache HttpComponents Core

org.apache.hc.core5.http.HttpStatus.SC_REQUEST_TOO_LONG

Angular

@angular/common/http/HttpStatusCode.PayloadTooLarge