HTTP 414 URI Too Long: Bedeutung und Behebung

Was dieser Fehler bedeutet und wie du ihn erkennst

• Ein Browser, API-Client, Crawler, Monitoring-Tool oder Checker erhält eine HTTP-Antwort 414 URI Too Long.
• Die fehlerhafte Adresse enthält einen ungewöhnlich langen Pfad, Query-String, wiederholte Parameter oder stark kodierte Daten.
• Das Problem kann einen einzelnen Link, eine Route, eine Redirect-Kette oder einen Request-Typ betreffen, während kürzere URLs weiterhin funktionieren.
• Ein Redirect kann die URL bei jedem Hop verlängern, bis ein zwischengeschaltetes System oder der Origin die Anfrage ablehnt.
• Response-Header können auf einen Webserver, Reverse Proxy, ein CDN, eine WAF oder eine Caching-Schicht statt auf die Anwendung selbst hinweisen.
• DNS-Auflösung und TLS-Aushandlung können erfolgreich sein, weil der Request einen HTTP-fähigen Endpunkt erreicht hat.

Hauptursachen nach Wahrscheinlichkeit

Wahrscheinlichste Ursachen

1. Ein zu langer Query-String. Ein Such-, Filter-, Tracking-, Paginierungs- oder State-Parameter kann mehr Daten serialisieren, als der Endpunkt akzeptiert.
2. Ein Fehler bei der URL-Erzeugung. Client- oder serverseitiger Code kann denselben Parameter wiederholt anhängen, eine kodierte URL duplizieren oder Daten in die URI schreiben, die dort nicht enthalten sein sollten.
3. Eine wachsende Redirect-Kette. Ein Redirect-Ziel kann wiederholt Return-URLs, Tracking-Parameter oder kodierte Kopien der ursprünglichen Adresse hinzufügen.
4. Ein Limit bei Proxy, CDN, WAF oder Webserver. Der Request kann abgelehnt werden, bevor er die Anwendung erreicht. Außerdem können verschiedene Schichten unterschiedliche URI-Limits haben.
5. Unerwartete Request-Erzeugung. Falsche Kodierung, eine versehentlich in einen anderen Parameter eingebettete absolute URL oder eine fehlerhafte Integration kann ein ungewöhnlich langes Request-Target erzeugen.
6. Bewusste Request-Validierung oder Schutz vor Missbrauch. Eine Komponente kann ungewöhnlich große Request-Targets ablehnen, um Ressourcenverbrauch zu begrenzen oder verdächtigen Traffic zu blockieren.

So behebst du den Fehler

Für Besucher und API-Nutzer

1. Prüfen Sie die genaue Adresse. Achten Sie auf wiederholte Query-Parameter, eine kopierte URL mit Tracking-Daten, einen unvollständigen Redirect oder einen unerwartet langen kodierten Wert.
2. Öffnen Sie die Basisroute ohne optionale Parameter, sofern dies sicher möglich ist. Wenn die kürzere Adresse funktioniert, fügen Sie Filter oder Parameter in kleinen Gruppen wieder hinzu, um den Auslöser zu finden.
3. Vermeiden Sie wiederholtes Neuladen. Erneute Versuche verkürzen eine zu lange URI nicht und können die Last erhöhen, wenn ein Redirect oder eine Client-Schleife beteiligt ist.
4. Verwenden Sie die dokumentierte Request-Struktur. Wenn eine API das Senden eines großen Filters oder Payloads im Request-Body unterstützt, nutzen Sie diese Methode nur wie dokumentiert. Ändern Sie einen Request nicht allein zum Umgehen des Fehlers von GET zu POST.
5. Kontaktieren Sie den Betreiber der Website oder API mit der bereinigten URL oder dem Request-Muster, Zeitstempel, Client-Details und der 414-Antwort. Entfernen Sie Cookies, Authorization-Header, API-Keys und andere Geheimnisse.

Für Entwickler

1. Erfassen Sie den Request genau. Protokollieren Sie HTTP-Methode, Host, Pfad, Länge des Query-Strings, Redirect-Verlauf, finalen Status und relevante Response-Header. Schwärzen Sie Zugangsdaten und personenbezogene Daten.
2. Reproduzieren Sie den kleinsten fehlschlagenden Request. Entfernen Sie optionale Parameter einzeln oder kürzen Sie deren Werte, bis sich die Antwort ändert. So lässt sich ein URI-Größenproblem von Routing- oder Authentifizierungsfehlern unterscheiden.
3. Untersuchen Sie die URL-Erzeugung. Prüfen Sie Suchfilter, Paginierung, Tracking-Parameter, Return-URLs, verschachtelte Kodierung und Schleifen, die die aktuelle URL wiederholt anhängen.
4. Überprüfen Sie Redirects. Vergleichen Sie jeden Location-Wert in der Kette und stellen Sie sicher, dass nicht fortlaufend die vorherige URL oder duplizierte Parameter hinzugefügt werden.
5. Wählen Sie den passenden Datentransport. Belassen Sie für eine sichere, cachebare Ressourcenabfrage benötigte Identifikatoren in der URI. Verwenden Sie für größere Eingaben das von der Anwendung unterstützte Request-Body-Design, sofern Semantik und Sicherheitsmodell dies erlauben.
6. Prüfen Sie die erzeugende Schicht. Gleichen Sie Zeitstempel und Request-Details mit den Logs von Anwendung, Webserver, Reverse Proxy, CDN und WAF ab. Die erste Komponente, die die Ablehnung protokolliert, ist in der Regel die zu untersuchende Schicht.
7. Wenden Sie die engste Korrektur an. Beheben Sie die URL-Erzeugung, Redirect-Logik oder Parameterverarbeitung, bevor Sie ein Server- oder Intermediary-Limit ändern. Falls ein Limit geändert werden muss, holen Sie eine Genehmigung ein, bewerten Sie die Auswirkungen auf Ressourcen und Sicherheit, aktualisieren Sie die richtige Schicht und testen Sie repräsentative Routen.
8. Testen Sie den ursprünglichen Request und verwandte Fälle erneut. Bestätigen Sie, dass der vorgesehene Request erfolgreich ist, fehlerhafte oder übergroße Requests weiterhin kontrolliert werden, Redirects enden und nicht betroffene Routen ihre erwarteten Statuscodes behalten.

Vorbeugung und Überprüfung der Lösung

• Begrenzen Sie Anzahl und Länge von Query-Parameterwerten durch Validierung in der Anwendung.
• Verhindern Sie, dass Redirect-Code die aktuelle URL wiederholt verschachtelt oder erneut kodiert.
• Testen Sie lange Filter, Paginierung, Tracking-Parameter und Redirect-Ketten in Integrationstests.
• Dokumentieren Sie Einstellungen von Proxy, CDN, WAF, Webserver und Anwendung und versionieren Sie sie, sofern unterstützt.
• Überwachen Sie 414-Antworten nach Route, Client und Deployment, damit Regressionen bei der URL-Erzeugung sichtbar werden.
• Bevorzugen Sie für große Anwendungseingaben unterstützte Request-Bodies, statt große Daten in einer URL zu kodieren.
• Vermeiden Sie Zugangsdaten oder sensible Daten in URLs, da diese in Verlauf, Logs oder Referrer-Daten erscheinen können.

Häufig gestellte Fragen