HTTP 304 Not Modified: Was es bedeutet

Was dieser Fehler bedeutet und wie du ihn erkennst

• Ein Browser-Entwicklertool, API-Client, Monitoring-Tool oder Checker meldet den Status 304 Not Modified.
• Die Response enthält Cache- oder Validator-Header, aber keinen Ressourcen-Body.
• Ein Browser kann die Seite normal anzeigen, weil er seine gecachte Repräsentation wiederverwendet.
• Ein API-Client oder Checker kann scheinbar eine leere Response erhalten, wenn er bedingtes Caching nicht korrekt implementiert.
• Das Ergebnis kann sich auf eine einzelne URL oder Ressource statt auf die gesamte Website beziehen.
• DNS und TLS können weiterhin funktionieren, weil der Client einen HTTP-Endpunkt erreicht und eine HTTP-Response erhalten hat.

Hauptursachen nach Wahrscheinlichkeit

1. Der Client hat einen bedingten Request gesendet. Request-Header wie If-None-Match oder If-Modified-Since fragten ab, ob die gecachte Repräsentation noch aktuell ist.
2. Die Ressource hat sich nicht geändert. Der Server oder ein Intermediär hat den übermittelten Validator, etwa einen ETag- oder Last-Modified-Wert, abgeglichen und korrekt 304 zurückgegeben.
3. Ein Browser, Proxy oder CDN hat eine normale Cache-Validierung durchgeführt. Die Response kann von einem Intermediär und nicht von der Origin-Anwendung erzeugt worden sein.
4. Ein Client oder Monitoring-Tool hat eine normale Cache-Response als Fehler angezeigt. Manche Tools erwarten eine vollständige Response mit Body und verwenden ihre gespeicherte Kopie möglicherweise nicht wieder.
5. Validator- oder Cache-Konfiguration ist inkonsistent. Unerwartete Ergebnisse können auftreten, wenn Anwendungs-Deployments, Proxy-Regeln oder Origin-Header veraltete, widersprüchliche oder zu breit gefasste Cache-Validatoren erzeugen.

HTTP 304 ist für sich genommen weder eine Weiterleitung noch ein Authentifizierungsfehler, eine Rate-Limit-Response oder ein Serverausfall. Diese Bedingungen sollten anhand des tatsächlichen Status, der Header und der Logs bestätigt werden, statt sie aus 304 abzuleiten.

So behebst du den Fehler

Für Besucher

1. Lassen Sie den Browser die Response zunächst verarbeiten. Ein normaler Browser sollte seine gecachte Kopie verwenden, wenn er 304 erhält. Wenn die Seite korrekt angezeigt wird, ist normalerweise keine weitere Aktion erforderlich.
2. Prüfen Sie die genaue URL. Bestätigen Sie Hostname, Pfad, Query-String und Protokoll. Unterschiedliche URLs können separate gecachte Repräsentationen haben.
3. Wiederholen Sie den Request einmal, wenn der angezeigte Inhalt veraltet oder unvollständig ist. Verwenden Sie die normalen Reload-Funktionen des Browsers, statt wiederholt zu aktualisieren.
4. Vergleichen Sie einen anderen Client nur, wenn dies hilfreich ist. Wenn ein Browser veraltete Inhalte anzeigt und ein anderer nicht, notieren Sie die betroffene URL, die ungefähre Uhrzeit und das Verhalten des Clients für den Website-Betreiber.
5. Kontaktieren Sie den Website-Betreiber, wenn die Ressource nicht geladen werden kann. Melden Sie die URL und den Zeitstempel, aber teilen Sie keine Passwörter, Cookies, Authorization-Header oder andere privaten Daten.

Für Entwickler und Website-Betreiber

1. Erfassen Sie den vollständigen Kontext von Request und Response. Notieren Sie die HTTP-Methode, die vollständige URL einschließlich relevanter Query-Parameter, den Status, Request- und Response-Validatoren, Cache-Control, Vary sowie Proxy- oder CDN-Header. Entfernen Sie Zugangsdaten und personenbezogene Daten, bevor Sie die Informationen weitergeben.
2. Bestätigen Sie, dass der Request bedingt ist. Suchen Sie nach If-None-Match oder If-Modified-Since. Ein 304 ist normalerweise dann sinnvoll, wenn der Client eine gecachte Repräsentation zur Validierung besitzt.
3. Prüfen Sie die Response-erzeugende Ebene. Ermitteln Sie, ob 304 vom Browser, einem lokalen oder gemeinsam genutzten Proxy, CDN, Reverse Proxy, Webserver oder von der Anwendung kam. Verwenden Sie, sofern verfügbar, die Request-ID und den Zeitstempel dieser Komponente.
4. Vergleichen Sie die Validatoren mit der Ressource. Prüfen Sie, ob ETag oder Last-Modified die angeforderte Repräsentation korrekt abbilden und ob die Content-Negotiation gegebenenfalls durch eine geeignete Vary-Richtlinie berücksichtigt wird.
5. Testen Sie einen unbedingten Request, wenn Sie den aktuellen Body benötigen. Verwenden Sie einen autorisierten Diagnose-Client oder lassen Sie die bedingten Request-Header in einem kontrollierten Test vorübergehend weg. Dies ist ein schreibgeschützter Vergleich. Befolgen Sie jedoch die normalen Zugriffskontrollen des Dienstes und senden Sie keine sensiblen Header an nicht vertrauenswürdige Tools.
6. Prüfen Sie kürzlich vorgenommene Änderungen an Cache und Deployment. Kontrollieren Sie Anwendungs-Releases, Asset-Generierung, Proxy- oder CDN-Regeln, Komprimierung und Content-Negotiation, Routing sowie das Verhalten bei der Cache-Invalidierung. Konzentrieren Sie sich auf Änderungen, die die konkrete Route betreffen, statt sofort globale Einstellungen zu ändern.
7. Wenden Sie die engste sichere Korrektur an. Korrigieren Sie den Validator, die Cache-Richtlinie oder die Intermediär-Regel erst, nachdem Sie die Abweichung identifiziert haben. Deaktivieren Sie das Caching nicht global, wenn nur eine Route oder Repräsentation betroffen ist.
8. Testen Sie denselben Request-Pfad erneut. Testen Sie sowohl einen bedingten als auch einen neuen Request und bestätigen Sie anschließend, dass verbundene Routen und Request-Methoden weiterhin die vorgesehenen Statuswerte und Repräsentationen zurückgeben.

Vorbeugung und Überprüfung der Lösung

• Behandeln Sie 304 im Monitoring als erwartetes Ergebnis einer Cache-Validierung, sofern der Client seine gecachte Repräsentation verwenden kann.
• Testen Sie wichtige Routen nach Deployments sowohl mit normalen als auch mit bedingten Requests.
• Halten Sie das Verhalten von ETag, Last-Modified, Cache-Control und Vary bewusst fest und dokumentieren Sie es.
• Stellen Sie sicher, dass sich Cache-Validatoren ändern, wenn sich die ausgelieferte Repräsentation ändert, einschließlich relevanter Varianten der Content-Negotiation.
• Überwachen Sie Statusraten nach Route und Cache-Ebene, damit ein unerwartetes 304-Muster von normalem Browser-Traffic unterschieden werden kann.
• Halten Sie Proxy-, CDN-, Webserver- und Anwendungskonfigurationen, sofern praktikabel, versionskontrolliert.
• Bewahren Sie bereinigte Request-IDs und Zeitstempel lange genug auf, um einen Bericht der Ebene zuordnen zu können, die die Response erzeugt hat.

Häufig gestellte Fragen