HTTP 410 Gone: Bedeutung und Behebung

Was dieser Fehler bedeutet und wie du ihn erkennst

• Ein Browser, API-Client, Crawler, Monitoring-Tool oder Uptime-Checker meldet 410 Gone.
• Die Response kann eine einzelne URL, ein Pfadmuster, eine HTTP-Methode oder eine API-Version betreffen und nicht die gesamte Website.
• DNS kann weiterhin aufgelöst werden und TLS kann weiterhin erfolgreich sein, da der Request einen HTTP-Endpunkt erreicht hat.
• Response-Header können Informationen zum Caching-Verhalten, zu einem Weiterleitungsziel, zum Authentifizierungskontext, zu einem Proxy oder CDN oder zum Server liefern, der den Request verarbeitet hat.
• Wird die Ressource absichtlich entfernt, liefert eine Wiederholung des Requests normalerweise dasselbe Ergebnis.

Hauptursachen nach Wahrscheinlichkeit

Wahrscheinlichste Ursachen

1. Absichtliche Entfernung oder Stilllegung einer Ressource — Der Betreiber hat eine Seite, Datei, einen API-Endpunkt oder eine Version dauerhaft entfernt und die alte Adresse so konfiguriert, dass sie 410 zurückgibt.
2. Anwendungs- oder Routing-Regel — Die Anwendung ordnet eine stillgelegte Route, einen gelöschten Datensatz oder eine nicht unterstützte API-Version dem Status 410 zu.
3. Rewrite- oder Virtual-Host-Konfiguration des Webservers — Eine Routenregel, eine Deployment-Änderung oder eine fehlerhafte Site-Konfiguration liefert für eine eigentlich weiterhin funktionierende URL den Status 410.
4. Verhalten von Reverse Proxy oder CDN — Ein zwischengeschaltetes System kann die Response auf Grundlage seiner Routing-, Cache- oder Edge-Konfiguration gecacht oder erzeugt haben.
5. Nicht übereinstimmender Request — Die URL kann für eine bestimmte Methode oder Pfadform gültig, für die verwendete Methode jedoch entfernt oder nicht unterstützt sein.
6. Individuelle Sicherheits- oder Request-Verarbeitungslogik — Eine WAF, ein Gateway oder eine Anwendungsrichtlinie kann absichtlich 410 verwenden, obwohl Probleme mit Authentifizierung, Autorisierung und Rate Limits häufig andere Statuscodes nutzen.

Der Statuscode allein kann nicht feststellen, welche Komponente die Response erzeugt hat. Response-Header, Zeitstempel und Logs sind erforderlich, um eine beabsichtigte Entfernung von einer versehentlichen Regel oder einer veralteten Response eines zwischengeschalteten Systems zu unterscheiden.

So behebst du den Fehler

Wenn Sie die Website besuchen

1. Prüfen Sie die Adresse sorgfältig, einschließlich Hostname, Pfad, Schreibweise, Groß- und Kleinschreibung sowie eines eventuell enthaltenen Versionssegments.
2. Wiederholen Sie die exakte URL einmal, ohne die Seite wiederholt neu zu laden. Wenn die Seite ein Konto erfordert, melden Sie sich über den normalen Prozess der Website an und versuchen Sie es erneut.
3. Wenn Sie über ein altes Lesezeichen, ein Suchergebnis oder einen externen Link zu der URL gelangt sind, suchen Sie nach der aktuellen Navigation der Website oder einem angekündigten Ersatz. Gehen Sie nicht automatisch davon aus, dass ein 410 ein gleichwertiges Ziel besitzt.
4. Wenn die Response bestehen bleibt, obwohl die Ressource weiterhin existieren sollte, teilen Sie dem Betreiber die URL, den Zeitpunkt des Requests, die HTTP-Methode und die angezeigte 410-Response mit. Senden Sie keine Passwörter, Cookies oder Access-Tokens.

Wenn Sie die Website betreiben oder entwickeln

1. Reproduzieren Sie den exakten Request. Erfassen Sie URL, HTTP-Methode, Host, Query-Parameter, Status, Response-Header und ob der Request authentifiziert war. Vergleichen Sie den fehlschlagenden Request mit einer bekannten funktionierenden verwandten Route oder Methode.
2. Entscheiden Sie, ob der 410 beabsichtigt ist. Bestätigen Sie, ob die Seite, Datei, der Datensatz oder die API-Version absichtlich entfernt wurde. Falls ja, dokumentieren Sie die Entfernung und behalten Sie die Response bei, sofern kein geeigneter Ersatz erforderlich ist.
3. Identifizieren Sie die antworterzeugende Schicht. Prüfen Sie, ob Header und Request-Pfad darauf hinweisen, dass die Anwendung, der Webserver, der Reverse Proxy, das CDN oder die WAF die Response erzeugt hat. Untersuchen Sie jede Schicht im Request-Pfad, statt alle gleichzeitig zu ändern.
4. Prüfen Sie passende Logs. Durchsuchen Sie die relevanten Access-, Anwendungs-, Proxy-, CDN- oder Sicherheits-Logs anhand von Zeitstempel, Route und Request-ID. Suchen Sie nach einer Entfernungsregel, einem gelöschten Datensatz, einem Rewrite, einer Deployment-Änderung oder einer gecachten Response.
5. Prüfen Sie kürzlich vorgenommene Änderungen und den Cache-Status. Vergleichen Sie Routing, API-Versionierung, Authentifizierung, Rewrite- und Edge-Cache-Konfiguration mit dem letzten bekannten funktionierenden Deployment. Wenn ein zwischengeschaltetes System eine falsche Response gecacht hat, verwenden Sie den dokumentierten und autorisierten Prozess zur Cache-Invalidierung, statt das Caching allgemein zu deaktivieren.
6. Wenden Sie die kleinstmögliche autorisierte Korrektur an. Stellen Sie die Route wieder her oder entfernen Sie die fehlerhafte Regel nur, wenn die Ressource verfügbar sein soll. Wenn ein gleichwertiger Ersatz existiert, konfigurieren und testen Sie eine gezielte Weiterleitung. Leiten Sie nicht zugehörige oder fehlende URLs nicht einfach weiter, um den 410 zu verbergen.
7. Testen Sie denselben Request erneut. Überprüfen Sie Status, Header und Response-Body mit dem relevanten Client sowie gegebenenfalls vom betroffenen Netzwerk- oder Edge-Standort aus. Bestätigen Sie, dass absichtlich entfernte Routen weiterhin wie dokumentiert reagieren und verwandte Routen ihre vorgesehenen Statuscodes behalten.
8. Überprüfen Sie Monitoring und Dokumentation. Aktualisieren Sie Routenverzeichnisse, API-Hinweise zu Stilllegungen, Weiterleitungen und Tests, damit ein künftiges Release nicht versehentlich eine aktive Ressource entfernt.

Vorbeugung und Überprüfung der Lösung

• Führen Sie ein Verzeichnis wichtiger Webrouten, Dateien und API-Versionen einschließlich ihres vorgesehenen Entfernungsverhaltens.
• Behandeln Sie absichtliche Entfernungen als Änderungen am Release: Dokumentieren und testen Sie sie und identifizieren Sie jede freigegebene Ersatz-URL.
• Halten Sie die Konfiguration von Anwendung, Webserver, Proxy, CDN und WAF versionskontrolliert und prüfen Sie Routenänderungen vor dem Deployment.
• Testen Sie wichtige URLs und API-Methoden nach Releases, Migrationen und Stilllegungen.
• Überwachen Sie HTTP-Statusraten nach Route, Methode und Deployment, damit unerwartete 410-Responses von geplanten Entfernungen unterschieden werden können.
• Bewahren Sie Access- und Anwendungs-Logs lange genug auf, um eine Response der verantwortlichen Schicht zuordnen zu können.
• Legen Sie Verfahren zur Cache-Invalidierung und zum Rollback bei versehentlichen Edge- oder Proxy-Responses fest.

Häufig gestellte Fragen