Baseline 2023 *
Newly available
Sicherer Kontext: Diese Funktion ist nur in sicheren Kontexten (HTTPS) in einigen oder allen unterstützenden Browsern verfügbar.
Der HTTP Clear-Site-Data Antwort-Header sendet ein Signal an den Client, dass er alle Browserdaten bestimmter Typen (Cookies, Speicher, Cache), die mit der anfordernden Website verbunden sind, entfernen soll. Er ermöglicht Webentwicklern eine gröÃere Kontrolle über die von Browsern für ihre Ursprünge gespeicherten Daten.
// Single directive
Clear-Site-Data: "cache"
// Multiple directives (comma separated)
Clear-Site-Data: "cache", "cookies"
// Wild card
Clear-Site-Data: "*"
Hinweis: Alle Direktiven müssen der Syntax der Anführungszeichen entsprechen. Eine Direktive, die nicht die doppelten Anführungszeichen enthält, ist ungültig.
"cache"
Der Server signalisiert, dass der Client lokal zwischengespeicherte Daten (den Browser-Cache, siehe HTTP-Caching) für den Ursprung der Antwort-URL entfernen soll. Abhängig vom Browser könnten auch Dinge wie vorab gerenderte Seiten, Vorwärts-Rückwärts-Cache, Skript-Caches, WebGL-Shader-Caches oder Adressleisten-Vorschläge geleert werden.
"clientHints" Experimentell
Gibt an, dass der Server alle für den Ursprung der Antwort-URL gespeicherten Client-Hinweise (angefordert über Accept-CH) entfernen wird.
Hinweis: In Browsern, die den "clientHints"-Datentyp unterstützen, werden Client-Hinweise auch gelöscht, wenn die Typen "cache", "cookies" oder "*" angegeben werden. "clientHints" ist daher nur notwendig, wenn keiner dieser anderen Typen angegeben ist.
"cookies"
Der Server signalisiert, dass der Client alle Cookies für den Ursprung der Antwort-URL entfernen soll. HTTP-Authentifizierungsdaten werden ebenfalls gelöscht. Dies betrifft die gesamte registrierte Domain, einschlieÃlich Subdomains. Somit werden beispielsweise https://example.com sowie https://stage.example.com Cookies gelöscht.
"executionContexts" Experimentell
Der Server signalisiert, dass der Client alle Browser-Kontexte für den Ursprung der Antwort neu laden soll (Location.reload).
"prefetchCache" Experimentell
Wird verwendet, um Spekulationsregeln zu löschen, die auf den Ursprungs-Referrer beschränkt sind.
"prerenderCache" Experimentell
Wird verwendet, um Spekulationsregeln zu löschen, die auf den Ursprungs-Referrer beschränkt sind.
"storage"
Der Server signalisiert, dass der Client alle DOM-Speicher für den Ursprung der Antwort-URL entfernen soll. Dazu gehören Speichersysteme wie:
localStorage.clear aus),sessionStorage.clear aus),IDBFactory.deleteDatabase ausgeführt),ServiceWorkerRegistration.unregister ausgeführt),NPP_ClearSiteData)."*" (Wildcard)
Der Server signalisiert, dass der Client alle Datentypen für den Ursprung der Antwort löschen soll. Wenn in zukünftigen Versionen dieses Headers weitere Datentypen hinzugefügt werden, werden diese ebenfalls von diesem erfasst.
Wenn sich ein Benutzer von Ihrer Website oder Ihrem Dienst abmeldet, möchten Sie möglicherweise lokal gespeicherte Daten entfernen, einschlieÃlich aller vorgeladenen oder vorgerenderten Inhalte für spekulierte Navigationen. Um dies zu tun, fügen Sie den Clear-Site-Data-Header der Seite hinzu, die das erfolgreiche Abmelden von der Website bestätigt (zum Beispiel https://example.com/logout):
Clear-Site-Data: "cache", "cookies", "storage", "executionContexts", "prefetchCache", "prerenderCache"
Wenn dieser Header mit der Antwort auf https://example.com/clear-cookies geliefert wird, werden alle Cookies auf derselben Domain https://example.com und alle Subdomains (wie https://stage.example.com etc.) gelöscht.
Clear-Site-Data: "cookies"
Wenn dieser Header mit der Antwort auf https://example.com/change-state.json geliefert wird, werden alle spekulierten Navigationen auf derselben Domain https://example.com und allen Subdomains (wie https://stage.example.com) gelöscht.
Clear-Site-Data: "prerenderCache"
Um sowohl Vorablesen als auch Vorab-Rendern von Spekulationen zu löschen, müssen sowohl prefetchCache als auch prerenderCache gesendet werden:
Clear-Site-Data: "prefetchCache", "prerenderCache"
Es gibt Fälle, in denen das Löschen eines der beiden oder beider geeignet ist.
Zum Beispiel könnte eine clientseitig gerenderte Anwendung, die Daten aus JavaScript zieht, prerenderCache bei einem Statuswechsel verwenden, um die vorgerenderten Seiten zu verwerfen, aber das vorab geladene HTML beibehalten, um es bei der Darstellung (oder erneuter Vorab-Renderung) der Seite zu verwenden.
Andererseits, wenn das vorab geladene HTML-Dokument veraltete Daten enthält, die entsprechende vorgerenderte Seite jedoch so eingerichtet ist, dass sie die Daten beim Anzeigen aktualisiert, müssen Sie möglicherweise nicht prerenderCache verwenden, möchten aber wahrscheinlich die prefetchCache-Direktive verwenden: damit das veraltete HTML nicht in einer zukünftigen Vorab-Renderung verwendet wird.
Wenn das vorab geladene HTML-Dokument veraltete Daten enthält und auch keine veralteten Inhalte auf vorgerenderten Seiten aktualisiert, ist das Angeben von sowohl prefetchCache als auch prerenderCache am geeignetsten.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4