HTTP 413 Content Too Large: Bedeutung und Behebung

Was dieser Fehler bedeutet und wie du ihn erkennst

• Ein Browser, API-Client, Upload-Tool oder Monitoring-Check empfängt HTTP 413 Content Too Large.
• Der Fehler tritt beim Übermitteln einer großen Datei, eines Formulars, eines JSON-Dokuments, eines Multipart-Requests oder eines anderen Request-Bodys auf.
• Eine kleinere Version desselben Requests kann erfolgreich sein, während der größere Request fehlschlägt.
• Die Response kann von einem Proxy, CDN, WAF, Webserver oder einer Anwendung stammen und je nach Ebene unterschiedliche Header oder einen unterschiedlichen Response-Text enthalten.
• Die übrige Website kann weiterhin verfügbar sein, und nicht verwandte URLs oder Request-Typen können weiterhin funktionieren.
• DNS-Auflösung und TLS können weiterhin fehlerfrei sein, da 413 eine Response auf HTTP-Ebene ist.

Hauptursachen nach Wahrscheinlichkeit

1. Der Request überschreitet ein Upload- oder Body-Size-Limit. Die Anwendung oder der Webserver kann eine maximale Größe für Request-Bodies, Dateien, Formulare oder Multipart-Requests erzwingen.
2. Eine zwischengeschaltete Komponente hat ein niedrigeres Limit. Ein Reverse Proxy, CDN, Load Balancer oder WAF kann den Request ablehnen, bevor die Origin-Anwendung ihn empfängt.
3. Der Request wird über einen strengeren Endpunkt geleitet. Für verschiedene URLs, Methoden, virtuelle Hosts oder Umgebungen können unterschiedliche Größenrichtlinien gelten.
4. Die Konfigurationslimits stimmen nicht überein. Der Proxy kann einen Request zulassen, den die Anwendung ablehnt, oder die Anwendung kann einen Request zulassen, den der Proxy blockiert.
5. Der Request ist unbeabsichtigt größer als erwartet. Multipart-Overhead, ein übergroßes codiertes Feld, eine angehängte Datei oder ein Client-Retry mit duplizierten Daten können die Body-Größe erhöhen.
6. Der Endpunkt lehnt große Inhalte absichtlich ab. Manche APIs oder Upload-Routen haben ein Produkt- oder Sicherheitslimit, das nicht entfernt werden sollte, ohne die vorgesehene Richtlinie zu bestätigen.

So behebst du den Fehler

Für Besucher und API-Nutzer

1. Bestätigen Sie die genaue URL und wiederholen Sie den Request einmal, ohne die Seite wiederholt zu aktualisieren.
2. Wenn Sie eine Datei hochladen, versuchen Sie es mit einer kleineren Datei oder reduzieren Sie die Dateigröße mithilfe eines freigegebenen Formats oder Komprimierungsverfahrens.
3. Vergleichen Sie bei einem API-Request den fehlschlagenden Payload mit einem minimalen gültigen Payload. Prüfen Sie auf unerwartet große Felder, eingebettete Daten, duplizierte Inhalte oder eine fehlerhafte Multipart-Erstellung.
4. Bestätigen Sie, dass der Request die vorgesehene Methode und den vorgesehenen Content-Type verwendet. Entfernen Sie nicht Authentifizierung oder Sicherheitskontrollen, nur um den Fehler zu umgehen.
5. Wenn kleinere Requests funktionieren, der erforderliche Request jedoch nicht, senden Sie dem Website-Betreiber die URL, Methode, ungefähre Request-Größe, den Zeitstempel, Response-Header und eine bereinigte Beschreibung des Payloads. Teilen Sie keine Passwörter, Cookies, Tokens oder API-Secrets.

Für Website-Betreiber und Entwickler

1. Erfassen Sie den fehlschlagenden Request. Notieren Sie URL, HTTP-Methode, Content-Type, ungefähre Body-Größe, Status, Response-Header und ob der Request über einen Proxy, ein CDN, einen Load Balancer oder einen WAF geleitet wird. Redigieren Sie Zugangsdaten und personenbezogene Daten.
2. Reproduzieren Sie den Fehler durch einen Größenvergleich. Testen Sie einen minimalen gültigen Request und schrittweise größere Requests oder vergleichen Sie einen erfolgreichen Upload mit dem fehlschlagenden. So lässt sich das effektive Limit bestimmen, ohne die Konfiguration vorschnell zu ändern.
3. Identifizieren Sie die erzeugende Ebene. Vergleichen Sie Response-Body, Header, Access-Logs, Proxy-Logs, WAF-Ereignisse und Anwendungs-Logs für denselben Zeitstempel und Request. Wenn der Request in den Anwendungs-Logs fehlt, kann eine vorgelagerte Komponente ihn zuerst abgelehnt haben.
4. Vergleichen Sie die Limits entlang des Pfads. Prüfen Sie die relevanten Limits für Request-Bodies, Uploads, Multipart-Requests, Proxys, CDNs, WAFs und Anwendungen. Das effektive Limit wird durch die erste Komponente bestimmt, die den Request ablehnt.
5. Wählen Sie die engste Korrektur. Wenn der Request akzeptiert werden sollte, passen Sie nach Bestätigung der Berechtigung sowie der Auswirkungen auf Arbeitsspeicher, Speicherplatz, Timeouts und Sicherheit nur die relevante Route oder Komponente an. Wenn das Limit beabsichtigt ist, behalten Sie es bei und ändern Sie den Client-Workflow oder dokumentieren Sie das unterstützte Maximum.
6. Testen Sie das ursprüngliche Request-Muster erneut. Verwenden Sie dieselbe Methode, URL, denselben Content-Type und eine repräsentative Payload-Größe. Bestätigen Sie, dass ein akzeptierter Request die Anwendung erreicht und dass fehlerhafte oder deutlich übergroße Requests weiterhin wie vorgesehen behandelt werden.
7. Prüfen Sie angrenzendes Verhalten. Testen Sie einen kleineren Request, eine nicht verwandte Route, das Authentifizierungsverhalten sowie alle anderen Proxy- oder Anwendungsebenen, die von der Konfigurationsänderung betroffen sind. Halten Sie die Änderung versionskontrolliert fest und dokumentieren Sie das endgültige Limit sowie den Grund dafür.

Vorbeugung und Überprüfung der Lösung

• Dokumentieren Sie die unterstützten maximalen Request-, Datei- und Multipart-Größen für jede Upload- oder API-Route.
• Halten Sie die Limits von Anwendung, Webserver, Proxy, CDN und WAF sichtbar und nach Möglichkeit versionskontrolliert.
• Testen Sie Grenzwerte und repräsentative große Requests vor dem Release in einer Nicht-Produktionsumgebung.
• Überwachen Sie 413-Responses nach Route, Methode, Client und Deployment, damit ein unerwarteter Anstieg von einem beabsichtigten Limit unterschieden werden kann.
• Stellen Sie sicher, dass Clients die Datei- und Payload-Größe vor der Übertragung validieren und eine klare Alternative anbieten, wenn ein Request zu groß ist.
• Bewahren Sie ausreichend bereinigte Proxy- und Anwendungs-Logs auf, um feststellen zu können, welche Ebene einen Request abgelehnt hat, ohne Secrets oder unnötige personenbezogene Daten zu protokollieren.

Häufig gestellte Fragen