Ich bin dabei, ein Problem mit einer permanenten HTTP 301-Umleitung zu beheben. Nach einem kurzen Test scheint es, dass Safari seinen Cache von 301s löscht, wenn er neu gestartet wird, aber Firefox tut das nicht.
Wann leeren IE, Chrome, Firefox und Safari ihren Cache von 301s?
Wenn ich zum Beispiel Folgendes umleiten möchte 1.example
a 2.example
aber ich habe versehentlich die Umleitung auf 3.example
ist das ein Problem. Ich kann den Fehler korrigieren, aber jeder, der die Seite besucht hat 1.example
in der Zwischenzeit die falsche Umleitung zu 3.example
und können daher auch nicht erreichen 1.example
o 2.example
bis ihr Cache geleert wird. Bei der Untersuchung stelle ich fest, dass es keine Cache-Control
y Expires
Kopfzeilen gesetzt. Die Kopfzeilen für die falsche 301-Antwort hätten wie folgt ausgesehen:
HTTP/1.1 301 Moved Permanently
Date: Wed, 27 Feb 2013 12:05:53 GMT
Server: Apache/2.2.21 (Unix) DAV/2 PHP/5.3.8
X-Powered-By: PHP/5.3.8
Location: http://3.example/
Content-Type: text/html
Das zeigen meine eigenen Tests:
- IE7, IE8 und Android 2.3.4 haben keinen Cache.
- Firefox 18.0.2, Safari 5.1.7 (unter Windows 7) und Opera 12.14 alle Cache und leeren den Cache beim Neustart des Browsers.
- Der Cache von IE10 und Chrome 25 wird beim Neustart des Browsers nicht gelöscht, Wann werden sie also freigegeben?
21 Stimmen
Bitte sagen Sie Chrome, dass wir einen Ausweg aus diesem 301-Höllenloch brauchen: bugs.chromium.org/p/chromium/issues/
0 Stimmen
@BT Da das Problem alle Browser betrifft, kann es eigentlich nur von der IETF gelöst werden, wahrscheinlich durch die Festlegung eines obligatorischen Timeouts für zwischengespeicherte 301er, die keine TTL haben, so dass die Browser ihre zwischengespeicherten Annahmen schließlich erneut überprüfen.
2 Stimmen
Ich habe auf der IETF-Mailingliste eine Diskussion darüber begonnen, falls sich jemand, der dieses Thema noch verfolgt, einbringen möchte: lists.w3.org/Archives/Public/ietf-http-wg/2017OctDec/0363.html