diff --git a/files/de/web/http/headers/accept-ch/index.md b/files/de/web/http/headers/accept-ch/index.md
index 76f8e02f0..9fd855c21 100644
--- a/files/de/web/http/headers/accept-ch/index.md
+++ b/files/de/web/http/headers/accept-ch/index.md
@@ -7,7 +7,7 @@ l10n:
{{HTTPSidebar}}{{securecontext_header}}
-Der **`Accept-CH`**-Header kann von einem Server gesetzt werden, um anzugeben, welche [Client-Hints](/de/docs/Web/HTTP/Client_hints) Header ein Client in nachfolgenden Anfragen einschließen sollte.
+Der **`Accept-CH`**-Header kann von einem Server gesetzt werden, um festzulegen, welche [Client-Hints](/de/docs/Web/HTTP/Client_hints)-Header ein Client in nachfolgenden Anfragen einfügen soll.
@@ -29,7 +29,7 @@ Der **`Accept-CH`**-Header kann von einem Server gesetzt werden, um anzugeben, w
> [!NOTE]
-> Client-Hints sind nur auf sicheren Ursprüngen (über TLS) verfügbar. Der `Accept-CH`-Header sollte für alle sicheren Anfragen beibehalten werden, um sicherzustellen, dass Client-Hints zuverlässig gesendet werden.
+> Client-Hints sind nur auf sicheren Ursprüngen (über TLS) zugänglich. Der `Accept-CH`-Header sollte für alle sicheren Anfragen gespeichert werden, um sicherzustellen, dass die Client-Hints zuverlässig gesendet werden.
## Syntax
diff --git a/files/de/web/http/headers/accept-charset/index.md b/files/de/web/http/headers/accept-charset/index.md
index 7f12abe2b..fd78417bc 100644
--- a/files/de/web/http/headers/accept-charset/index.md
+++ b/files/de/web/http/headers/accept-charset/index.md
@@ -10,11 +10,11 @@ l10n:
> [!WARNING]
> Verwenden Sie diesen Header nicht. Browser lassen diesen Header weg und Server sollten ihn ignorieren.
-Der **`Accept-Charset`**-Anfrage-HTTP-Header war ein Header, der die von einem Client unterstützten {{glossary("character encoding", "Zeichenkodierungen")}} mitteilte. Er wird nicht mehr weit verbreitet verwendet.
+Der HTTP-Request-Header **`Accept-Charset`** war ein Header, der die vom Client unterstützten {{glossary("character encoding", "Zeichenkodierungen")}} anzeigte. Er wird nicht mehr häufig verwendet.
-UTF-8 ist gut unterstützt und die überwältigend bevorzugte Wahl für Zeichenkodierung. Um [bessere Privatsphäre durch weniger konfigurationsbasierten Entropie](https://www.eff.org/deeplinks/2010/01/primer-information-theory-and-privacy) zu gewährleisten, lassen alle Browser den `Accept-Charset` Header weg.
+UTF-8 wird gut unterstützt und ist die überwältigend bevorzugte Wahl für die Zeichenkodierung. Um [bessere Privatsphäre durch weniger konfigurationsbasierte Entropie zu gewährleisten](https://www.eff.org/deeplinks/2010/01/primer-information-theory-and-privacy), lassen alle Browser den `Accept-Charset` Header weg.
-Heute ist `Accept-Charset` vor allem als einer von mehreren [verbotenen Headernamen](/de/docs/Glossary/Forbidden_header_name) bekannt.
+Heutzutage ist `Accept-Charset` vor allem dafür bekannt, einer von mehreren [verbotenen Headernamen](/de/docs/Glossary/Forbidden_header_name) zu sein.
@@ -31,7 +31,7 @@ Heute ist `Accept-Charset` vor allem als einer von mehreren [verbotenen Headerna
## Siehe auch
-- HTTP [Inhaltsverhandlung](/de/docs/Web/HTTP/Content_negotiation)
-- [Accept-Charset ist nicht mehr](https://hsivonen.fi/accept-charset/)
-- Header mit dem Ergebnis der Inhaltsverhandlung: {{HTTPHeader("Content-Type")}}
+- HTTP [Inhaltsaushandlung](/de/docs/Web/HTTP/Content_negotiation)
+- [Accept-Charset is no more](https://hsivonen.fi/accept-charset/)
+- Header mit dem Ergebnis der Inhaltsaushandlung: {{HTTPHeader("Content-Type")}}
- Andere ähnliche Header: {{HTTPHeader("TE")}}, {{HTTPHeader("Accept-Encoding")}}, {{HTTPHeader("Accept-Language")}}, {{HTTPHeader("Accept")}}
diff --git a/files/de/web/http/headers/accept-encoding/index.md b/files/de/web/http/headers/accept-encoding/index.md
index 3ba6a2a7c..abb71986e 100644
--- a/files/de/web/http/headers/accept-encoding/index.md
+++ b/files/de/web/http/headers/accept-encoding/index.md
@@ -7,24 +7,24 @@ l10n:
{{HTTPSidebar}}
-Der **`Accept-Encoding`** Anfrage-HTTP-Header gibt an, welche Inhaltscodierung (normalerweise ein Komprimierungsalgorithmus) der Client verstehen kann. Der Server verwendet die [Inhaltsaushandlung](/de/docs/Web/HTTP/Content_negotiation), um einen der Vorschläge auszuwählen und informiert den Client über diese Wahl mit dem {{HTTPHeader("Content-Encoding")}} Antwort-Header.
+Der **`Accept-Encoding`** HTTP-Header in der Anfrage gibt die Inhaltskodierung (normalerweise ein Komprimierungsalgorithmus) an, die der Client verstehen kann. Der Server verwendet [Inhaltsaushandlung](/de/docs/Web/HTTP/Content_negotiation), um eines der vorgeschlagenen Formate auszuwählen und informiert den Client über diese Wahl mit dem {{HTTPHeader("Content-Encoding")}} Header in der Antwort.
-Selbst wenn sowohl der Client als auch der Server die gleichen Komprimierungsalgorithmen unterstützen, kann der Server entscheiden, den Körper einer Antwort nicht zu komprimieren, wenn der Wert `identity` ebenfalls akzeptabel ist. Zwei häufige Gründe führen dazu:
+Auch wenn sowohl der Client als auch der Server dieselben Komprimierungsalgorithmen unterstützen, kann der Server entscheiden, den Inhalt einer Antwort nicht zu komprimieren, wenn der `identity`-Wert ebenfalls akzeptabel ist. Zwei häufige Gründe sind dafür:
-- Die zu sendenden Daten sind bereits komprimiert, daher würde eine zweite Komprimierung die übertragene Datenmenge nicht verringern. Dies gilt für vorab komprimierte Bildformate (beispielsweise JPEG);
-- Der Server ist überlastet und kann keine Rechenressourcen zur Durchführung der Komprimierung bereitstellen. Zum Beispiel empfiehlt Microsoft, nicht zu komprimieren, wenn ein Server mehr als 80 % seiner Rechenleistung nutzt.
+- Die zu sendenden Daten sind bereits komprimiert, sodass eine zweite Komprimierung die übertragene Datenmenge nicht verringern würde. Dies gilt für vorkomprimierte Bildformate (z. B. JPEG);
+- Der Server ist überlastet und kann keine Rechenressourcen für die Komprimierung bereitstellen. Microsoft empfiehlt beispielsweise, keine Komprimierung vorzunehmen, wenn ein Server mehr als 80 % seiner Rechenkapazität nutzt.
-Solange die Direktiven `identity;q=0` oder `*;q=0` den Wert `identity`, was keine Kodierung bedeutet, nicht ausdrücklich verbieten, darf der Server niemals einen {{HTTPStatus("406")}} `Nicht akzeptabel` Fehler zurückgeben.
+Solange die Direktiven `identity;q=0` oder `*;q=0` den `identity`-Wert, der keine Kodierung bedeutet, nicht ausdrücklich verbieten, darf der Server niemals einen {{HTTPStatus("406")}} `Not Acceptable` Fehler zurückgeben.
> [!NOTE]
>
-> - Ein IANA-Register hält [eine Liste der offiziellen Inhaltskodierungen](https://www.iana.org/assignments/http-parameters/http-parameters.xhtml#content-coding) bereit.
-> - Die `bzip` und `bzip2` Kodierungen sind nicht standardisiert, können jedoch in einigen Fällen, einschließlich Unterstützung für ältere Systeme, verwendet werden.
+> - Ein IANA-Register führt [eine Liste offizieller Inhaltskodierungen](https://www.iana.org/assignments/http-parameters/http-parameters.xhtml#content-coding).
+> - Die `bzip` und `bzip2` Kodierungen sind nicht standardisiert, können jedoch in einigen Fällen verwendet werden, einschließlich Unterstützung älterer Systeme.
-
Header-Typ
+
Headertyp
{{Glossary("Request header")}}
@@ -52,21 +52,21 @@ Accept-Encoding: deflate, gzip;q=1.0, *;q=0.5
## Direktiven
- `gzip`
- - : Ein Komprimierungsformat, das die [Lempel-Ziv-Codierung](https://en.wikipedia.org/wiki/LZ77_and_LZ78#LZ77) (LZ77) mit einer 32-Bit-CRC verwendet.
+ - : Ein Komprimierungsformat, das den [Lempel-Ziv-Algorithmus](https://en.wikipedia.org/wiki/LZ77_and_LZ78#LZ77) (LZ77) mit einem 32-Bit-CRC nutzt.
- `compress`
- : Ein Komprimierungsformat, das den [Lempel-Ziv-Welch](https://en.wikipedia.org/wiki/LZW) (LZW) Algorithmus verwendet.
- `deflate`
- - : Ein Komprimierungsformat, das die [zlib](https://en.wikipedia.org/wiki/Zlib) Struktur mit dem [_deflate_](https://en.wikipedia.org/wiki/DEFLATE) Komprimierungsalgorithmus verwendet.
+ - : Ein Komprimierungsformat, das die [zlib](https://en.wikipedia.org/wiki/Zlib) Struktur mit dem [_deflate_](https://en.wikipedia.org/wiki/DEFLATE) Komprimierungsalgorithmus nutzt.
- `br`
- - : Ein Komprimierungsformat, das den [Brotli-Algorithmus](https://en.wikipedia.org/wiki/Brotli) verwendet.
+ - : Ein Komprimierungsformat, das den [Brotli](https://en.wikipedia.org/wiki/Brotli) Algorithmus verwendet.
- `zstd`
- - : Ein Komprimierungsformat, das den [Zstandard-Algorithmus](https://en.wikipedia.org/wiki/Zstd) verwendet.
+ - : Ein Komprimierungsformat, das den [Zstandard](https://en.wikipedia.org/wiki/Zstd) Algorithmus benutzt.
- `identity`
- - : Gibt die Identity-Funktion an (d. h. ohne Änderung oder Komprimierung). Dieser Wert wird immer als akzeptabel angesehen, selbst wenn er weggelassen wird.
+ - : Gibt die Identitätsfunktion an (d. h. ohne Änderungen oder Komprimierung). Dieser Wert gilt immer als akzeptabel, auch wenn er weggelassen wird.
- `*`
- - : Passt zu jeder Inhaltskodierung, die nicht bereits im Header aufgeführt ist. Dies ist der Standardwert, wenn der Header nicht vorhanden ist. Diese Direktive deutet nicht darauf hin, dass ein Algorithmus unterstützt wird, sondern gibt an, dass keine Präferenz ausgedrückt wird.
-- `;q=` (q-Werte Gewichtung)
- - : Jeder Wert wird in einer Präferenzreihenfolge ausgedrückt, die durch einen relativen [Qualitätswert](/de/docs/Glossary/Quality_values), genannt _Gewicht_, angegeben wird.
+ - : Entspricht jeder nicht bereits im Header aufgeführten Inhaltskodierung. Dies ist der Standardwert, wenn der Header nicht vorhanden ist. Diese Direktive deutet nicht darauf hin, dass irgendein Algorithmus unterstützt wird, sondern dass keine Präferenz ausgedrückt wird.
+- `;q=` (q-Wert Gewichtung)
+ - : Jeder Wert wird in einer Präferenzreihenfolge ausgedrückt, die mit einem relativen [Qualitätswert](/de/docs/Glossary/Quality_values) bezeichnet wird, der _Gewicht_ genannt wird.
## Beispiele
@@ -93,6 +93,6 @@ Accept-Encoding: br;q=1.0, gzip;q=0.8, *;q=0.1
- HTTP [Inhaltsaushandlung](/de/docs/Web/HTTP/Content_negotiation)
- Ein Header mit dem Ergebnis der Inhaltsaushandlung: {{HTTPHeader("Content-Encoding")}}
- Andere ähnliche Header: {{HTTPHeader("TE")}}, {{HTTPHeader("Accept")}}, {{HTTPHeader("Accept-Language")}}
-- {{Glossary("Brotli-Komprimierung")}}
-- {{Glossary("GZip-Komprimierung")}}
-- {{Glossary("Zstandard-Komprimierung")}}
+- {{Glossary("Brotli compression")}}
+- {{Glossary("GZip compression")}}
+- {{Glossary("Zstandard compression")}}
diff --git a/files/de/web/http/headers/accept-language/index.md b/files/de/web/http/headers/accept-language/index.md
index 804496d49..b038c05b5 100644
--- a/files/de/web/http/headers/accept-language/index.md
+++ b/files/de/web/http/headers/accept-language/index.md
@@ -7,18 +7,18 @@ l10n:
{{HTTPSidebar}}
-Der **`Accept-Language`** HTTP-Anforderungsheader gibt die natürliche Sprache und das Gebietsschema an, die der Client bevorzugt. Der Server verwendet [Inhaltsaushandlung](/de/docs/Web/HTTP/Content_negotiation), um einen der Vorschläge auszuwählen, und informiert den Client über die Wahl mit dem {{HTTPHeader("Content-Language")}} Antwortheader. Browser setzen die erforderlichen Werte für diesen Header basierend auf ihrer aktiven Benutzeroberflächensprache. Benutzer können auch zusätzliche bevorzugte Sprachen über die Browsereinstellungen konfigurieren.
+Der **`Accept-Language`** Anforderungs-HTTP-Header gibt an, welche natürliche Sprache und welches Gebietsschema der Client bevorzugt. Der Server verwendet die [Inhaltsaushandlung](/de/docs/Web/HTTP/Content_negotiation), um eines der Vorschläge auszuwählen und informiert den Client mit dem {{HTTPHeader("Content-Language")}} Antwort-Header über die Entscheidung. Browser setzen erforderliche Werte für diesen Header entsprechend ihrer aktiven Benutzeroberflächensprache. Benutzer können über die Browsereinstellungen auch zusätzliche bevorzugte Sprachen konfigurieren.
-Der `Accept-Language` Header listet in der Regel die gleichen Gebietsschemata wie die {{domxref("navigator.languages")}} Eigenschaft, mit abnehmenden `q` Werten (Qualitätswerten) auf. Einige Browser (Chrome und Safari) fügen in `Accept-Language` sprachspezifische Fallback-Tags hinzu – zum Beispiel `en-US,en;q=0.9,zh-CN;q=0.8,zh;q=0.7`, wenn `navigator.languages` `["en-US", "zh-CN"]` ist. Aus Datenschutzgründen (Reduzierung von {{Glossary("fingerprinting")}}) können sowohl `Accept-Language` als auch `navigator.languages` nicht die vollständige Liste der Benutzervorlieben enthalten, wie in Safari (immer) und dem Inkognito-Modus von Chrome, wo nur eine Sprache aufgelistet wird.
+Der `Accept-Language`-Header listet im Allgemeinen dieselben Gebietsschemata auf wie die Eigenschaft {{domxref("navigator.languages")}}, mit abnehmenden `q`-Werten (Qualitätswerte). Einige Browser (Chrome und Safari) fügen in `Accept-Language` sprachbasierte Fallback-Tags hinzu – zum Beispiel `en-US,en;q=0.9,zh-CN;q=0.8,zh;q=0.7`, wenn `navigator.languages` `["en-US", "zh-CN"]` ist. Aus Datenschutzgründen (Reduzierung von {{Glossary("fingerprinting")}}) können `Accept-Language` und `navigator.languages` nicht die vollständige Liste der Benutzerpräferenzen enthalten, wie in Safari (immer) und im Inkognitomodus von Chrome, wo nur eine Sprache aufgelistet ist.
-Dieser Header dient als Hinweis, wenn der Server die Zielsprache des Inhalts nicht anderweitig bestimmen kann (zum Beispiel die Verwendung einer spezifischen URL, die von einer expliziten Benutzerentscheidung abhängt). Der Server sollte niemals eine explizite Sprachauswahl des Benutzers überschreiben. Der Inhalt von `Accept-Language` liegt oft außerhalb der Kontrolle eines Benutzers (zum Beispiel beim Reisen). Ein Benutzer möchte möglicherweise auch eine Seite in einer anderen Sprache besuchen als der Sprache der Benutzeroberfläche.
+Dieser Header dient als Hinweis, wenn der Server die Zielsprache des Inhalts anderweitig nicht bestimmen kann (zum Beispiel bei der Verwendung einer spezifischen URL, die von einer expliziten Benutzerentscheidung abhängt). Der Server sollte niemals eine explizite Benutzer-Sprachauswahl überschreiben. Der Inhalt von `Accept-Language` liegt oft außerhalb der Kontrolle eines Benutzers (zum Beispiel bei Reisen). Ein Benutzer möchte möglicherweise auch eine Seite in einer anderen Sprache als in der Benutzeroberfläche sehen.
-Der Server kann möglicherweise einen {{HTTPStatus("406")}} (Not Acceptable) Fehlercode zurücksenden, wenn kein Inhalt in einer passenden Sprache bereitgestellt werden kann. Solches Verhalten wird jedoch selten implementiert, um eine bessere Benutzererfahrung zu gewährleisten, und Server ignorieren oft den `Accept-Language` Header in solchen Fällen.
+Der Server kann möglicherweise einen {{HTTPStatus("406")}} (Nicht akzeptabel) Fehlercode zurücksenden, wenn er Inhalte nicht in einer passenden Sprache bereitstellen kann. Ein solches Verhalten wird jedoch selten implementiert, um ein besseres Benutzererlebnis zu gewährleisten, und Server ignorieren den `Accept-Language`-Header in solchen Fällen häufig.
-
Header-Typ
+
Headertyp
{{Glossary("Request header")}}
@@ -48,17 +48,16 @@ Accept-Language: *
Accept-Language: fr-CH, fr;q=0.9, en;q=0.8, de;q=0.7, *;q=0.5
```
-## Anweisungen
+## Direktiven
- ``
- - : Ein Sprach-Tag (manchmal auch als "Gebietsschema-Identifikator" bezeichnet).
- Dies besteht aus einem 2- bis 3-Buchstaben-Basis-Sprachtag, der eine Sprache angibt, optional gefolgt von zusätzlichen Untertags, die durch `'-'` getrennt sind.
- Die häufigsten zusätzlichen Informationen sind die Länder- oder Regionsvariante (wie `'en-US'` oder `'fr-CA'`) oder die Art des zu verwendenden Alphabets (wie `'sr-Latn'`).
- Andere Varianten, wie die Art der Orthographie (`'de-DE-1996'`), werden im Kontext dieses Headers normalerweise nicht verwendet.
+ - : Ein Sprach-Tag (auch als "Gebietsschema-Identifikator" bezeichnet).
+ Dies besteht aus einem 2-3 Buchstaben umfassenden Basis-Sprach-Tag, das eine Sprache angibt, optional gefolgt von zusätzlichen Untertags, die durch `'-'` getrennt sind. Die häufigsten Zusatzinformationen sind die länderspezifische oder regionale Variante (wie `'en-US'` oder `'fr-CA'`) oder die zu verwendende Schriftart (wie `'sr-Latn'`).
+ Andere Varianten, wie der Typ der Orthographie (`'de-DE-1996'`), werden im Kontext dieses Headers normalerweise nicht verwendet.
- `*`
- - : Jede Sprache; `'*'` wird als Platzhalter verwendet.
-- `;q=` (q-Faktor Gewichtung)
- - : Jeder Wert in einer Reihenfolge der Präferenz, ausgedrückt durch einen relativen {{glossary("Quality values", "Qualitätswert")}}, genannt _Gewicht_.
+ - : Beliebige Sprache; `'*'` wird als Platzhalter verwendet.
+- `;q=` (q-Faktor-Gewichtung)
+ - : Jeder Wert, der in einer Präferenzreihenfolge angegeben wird, ausgedrückt durch einen relativen {{glossary("Quality values", "Qualitätswert")}} genanntes _Gewicht_.
## Beispiele
@@ -78,7 +77,7 @@ Accept-Language: en-US,en;q=0.5
{{Specifications}}
-## Kompatibilität der Browser
+## Browser-Kompatibilität
{{Compat}}
diff --git a/files/de/web/http/headers/accept-patch/index.md b/files/de/web/http/headers/accept-patch/index.md
index 554e547a5..a5dbabdec 100644
--- a/files/de/web/http/headers/accept-patch/index.md
+++ b/files/de/web/http/headers/accept-patch/index.md
@@ -7,19 +7,19 @@ l10n:
{{HTTPSidebar}}
-Der **`Accept-Patch`** Antwort-HTTP-Header gibt an, welchen Medientyp der Server in einer PATCH-Anfrage verarbeiten kann.
+Der **`Accept-Patch`** Antwort-HTTP-Header gibt an, welchen Medientyp der Server in einer PATCH-Anfrage versteht.
-**`Accept-Patch`** als Antwort auf eine beliebige Methode bedeutet, dass PATCH auf der durch die Request-URI identifizierten Ressource erlaubt ist. Zwei häufige Fälle führen dazu:
+**`Accept-Patch`** als Antwort auf eine beliebige Methode bedeutet, dass PATCH auf die durch die Request-URI identifizierte Ressource erlaubt ist. Zwei häufige Fälle führen dazu:
-Ein Server, der eine PATCH-Anfrage mit einem nicht unterstützten Medientyp erhält, könnte mit {{HTTPStatus("415")}} `Unsupported Media Type` antworten und einen Accept-Patch-Header angeben, der einen oder mehrere unterstützte Medientypen referenziert.
+Ein Server, der eine PATCH-Anfrage mit einem nicht unterstützten Medientyp erhält, könnte mit {{HTTPStatus("415")}} `Unsupported Media Type` antworten und einen Accept-Patch-Header zurückgeben, der einen oder mehrere unterstützte Medientypen angibt.
> [!NOTE]
-> Ein IANA-Register pflegt [eine Liste von Medientypen](https://www.iana.org/assignments/media-types/media-types.xhtml).
+> Ein IANA-Register führt [eine Liste von Medientypen](https://www.iana.org/assignments/media-types/media-types.xhtml).
-
Header-Typ
+
Headertyp
{{Glossary("Response header")}}
@@ -37,7 +37,7 @@ Accept-Patch: text/example;charset=utf-8
Accept-Patch: application/merge-patch+json
```
-## Anweisungen
+## Direktiven
Keine
@@ -57,9 +57,9 @@ Accept-Patch: application/merge-patch+json
## Browser-Kompatibilität
-Browser-Kompatibilität ist für diesen Header nicht relevant (Header wird vom Server gesendet, und die Spezifikation definiert kein Client-Verhalten).
+Die Browser-Kompatibilität ist für diesen Header nicht relevant (Header wird vom Server gesendet und die Spezifikation definiert kein Client-Verhalten).
## Siehe auch
-- HTTP-Methode {{HTTPMethod("PATCH")}}
+- Http-Methode {{HTTPMethod("PATCH")}}
- HTTP Semantik und Kontext {{RFC("7231", "PUT", "4.3.4")}}
diff --git a/files/de/web/http/headers/accept-post/index.md b/files/de/web/http/headers/accept-post/index.md
index 6c6781367..38586aef8 100644
--- a/files/de/web/http/headers/accept-post/index.md
+++ b/files/de/web/http/headers/accept-post/index.md
@@ -7,16 +7,16 @@ l10n:
{{HTTPSidebar}}
-Der **`Accept-Post`** HTTP-Antwort-Header gibt an, welche [Medientypen](/de/docs/Web/HTTP/Basics_of_HTTP/MIME_types) vom Server für HTTP-POST-Anfragen akzeptiert werden.
+Der **`Accept-Post`** HTTP-Antwortheader gibt an, welche [Medientypen](/de/docs/Web/HTTP/Basics_of_HTTP/MIME_types) vom Server für HTTP-Post-Anfragen akzeptiert werden.
-**`Accept-Post`** als Antwort auf jede Methode bedeutet, dass `POST` auf der angeforderten Ressource erlaubt ist (jede Dokument-/Medienformatangabe im Header zeigt weiter an, dass das Dokumentformat erlaubt ist).
+**`Accept-Post`** als Antwort auf eine beliebige Methode bedeutet, dass `POST` auf die angeforderte Ressource erlaubt ist (jede Dokument-/Medienformatangabe im Header zeigt ferner an, dass das Dokumentenformat erlaubt ist).
-Beispielsweise könnte ein Server, der eine `POST`-Anfrage mit einem nicht unterstützten Medientyp empfängt, mit {{HTTPStatus("415")}} `Unsupported Media Type` und einem **`Accept-Post`**-Header antworten, der auf einen oder mehrere unterstützte Medientypen verweist.
+Zum Beispiel könnte ein Server, der eine `POST`-Anfrage mit einem nicht unterstützten Medientyp erhält, mit {{HTTPStatus("415")}} `Unsupported Media Type` antworten und einen **`Accept-Post`**-Header zurückgeben, der auf einen oder mehrere unterstützte Medientypen verweist.
> [!NOTE]
>
-> - Ein IANA-Register führt [eine Liste offizieller Inhaltskodierungen](https://www.iana.org/assignments/http-parameters/http-parameters.xhtml#content-coding).
-> - Die Kodierungen `bzip` und `bzip2` sind nicht standardisiert, können aber in einigen Fällen verwendet werden, einschließlich der Unterstützung von älteren Systemen.
+> - Ein IANA-Register führt [eine Liste offizieller Inhaltscodierungen](https://www.iana.org/assignments/http-parameters/http-parameters.xhtml#content-coding).
+> - Die `bzip`- und `bzip2`-Codierungen sind nicht standardisiert, können jedoch in einigen Fällen verwendet werden, einschließlich Unterstützung für ältere Systeme.
@@ -40,7 +40,7 @@ Accept-Post: */*
```
> [!NOTE]
-> Der `Accept-Post`-Header spezifiziert einen Medienbereich auf die gleiche Weise wie {{HTTPHeader("Accept")}}, außer dass er keinen Vorzugswert (d.h. keine `q`-Argumente) hat. Dies liegt daran, dass `Accept-Post` ein Antwort-Header ist, während `Accept` ein Anfrage-Header ist.
+> Der `Accept-Post`-Header spezifiziert einen Medienbereich auf dieselbe Weise wie {{HTTPHeader("Accept")}}, mit der Ausnahme, dass er keinen Präferenzbegriff (d.h. keine `q`-Argumente) besitzt. Dies liegt daran, dass `Accept-Post` ein Antwortheader ist, während `Accept` ein Anforderungsheader ist.
## Direktiven
@@ -60,9 +60,9 @@ Accept-Post: */*
## Browser-Kompatibilität
-Die Browser-Kompatibilität ist für diesen Header nicht relevant (der Header wird vom Server gesendet, und die Spezifikation definiert kein Clientverhalten).
+Die Browser-Kompatibilität ist für diesen Header nicht relevant (der Header wird vom Server gesendet, und die Spezifikation definiert kein Verhalten auf der Clientseite).
## Siehe auch
-- HTTP-Methode {{HTTPMethod("POST")}}
+- Http-Methode {{HTTPMethod("POST")}}
- HTTP Semantik und Kontext {{RFC("7231", "POST", "4.3.3")}}
diff --git a/files/de/web/http/headers/accept-ranges/index.md b/files/de/web/http/headers/accept-ranges/index.md
index 7e22a0283..17618e00a 100644
--- a/files/de/web/http/headers/accept-ranges/index.md
+++ b/files/de/web/http/headers/accept-ranges/index.md
@@ -7,14 +7,14 @@ l10n:
{{HTTPSidebar}}
-Der **`Accept-Ranges`** HTTP-Antwortheader ist ein Indikator, den der Server verwendet, um seine Unterstützung für teilweise Anfragen seitens des Clients für Dateidownloads zu kennzeichnen. Der Wert dieses Feldes gibt die Einheit an, die zur Definition eines Bereichs verwendet werden kann.
+Der **`Accept-Ranges`** HTTP-Antwortheader ist ein Indikator, den der Server verwendet, um seine Unterstützung für teilweise Anfragen von der Clientseite bei Dateidownloads anzuzeigen. Der Wert dieses Feldes zeigt die Einheit an, die verwendet werden kann, um einen Bereich zu definieren.
-In Anwesenheit eines `Accept-Ranges` Headers kann der Browser versuchen, einen unterbrochenen Download _fortzusetzen_, anstatt den Download neu zu starten.
+In Anwesenheit eines `Accept-Ranges`-Headers kann der Browser versuchen, einen unterbrochenen Download _fortzusetzen_, anstatt den Download von vorne zu starten.
-
Header-Typ
+
Headertyp
{{Glossary("Response header")}}
@@ -34,9 +34,9 @@ Accept-Ranges: none
## Direktiven
- ``
- - : Definiert die Bereichseinheit, die der Server unterstützt. Obwohl `bytes` die einzige Bereichseinheit ist, die formell durch {{RFC("7233")}} definiert wurde, können zusätzliche Bereichseinheiten im [HTTP Range Unit Registry](https://www.iana.org/assignments/http-parameters/http-parameters.xhtml#range-units) registriert werden.
+ - : Definiert die Range-Einheit, die der Server unterstützt. Obwohl `bytes` die einzige Range-Einheit ist, die formal durch {{RFC("7233")}} definiert wurde, können zusätzliche Range-Einheiten im [HTTP Range Unit Registry](https://www.iana.org/assignments/http-parameters/http-parameters.xhtml#range-units) registriert werden.
- `none`
- - : Gibt an, dass keine Bereichseinheit unterstützt wird. Dies macht den Header äquivalent zu seiner eigenen Abwesenheit und wird daher selten verwendet. In einigen Browsern, wie IE9, wird diese Einstellung jedoch verwendet, um die Pausentasten im Download-Manager zu deaktivieren oder zu entfernen.
+ - : Gibt an, dass keine Range-Einheit unterstützt wird. Dies macht den Header äquivalent zu seiner eigenen Abwesenheit und wird daher selten verwendet. In einigen Browsern, wie IE9, wird diese Einstellung jedoch verwendet, um die Pause-Tasten im Download-Manager zu deaktivieren oder zu entfernen.
## Beispiele
diff --git a/files/de/web/http/headers/accept/index.md b/files/de/web/http/headers/accept/index.md
index 7bdf869d8..a34594f1b 100644
--- a/files/de/web/http/headers/accept/index.md
+++ b/files/de/web/http/headers/accept/index.md
@@ -1,5 +1,5 @@
---
-title: Akzeptieren
+title: Accept
slug: Web/HTTP/Headers/Accept
l10n:
sourceCommit: 7aab76c49ae49d606b4958f8dc8cd1269fb7b9b6
@@ -7,7 +7,7 @@ l10n:
{{HTTPSidebar}}
-Der **`Accept`** HTTP-Header der Anfrage gibt an, welche Inhaltstypen, ausgedrückt als [MIME-Typen](/de/docs/Web/HTTP/Basics_of_HTTP/MIME_types), der Client verstehen kann. Der Server verwendet [Content Negotiation](/de/docs/Web/HTTP/Content_negotiation), um einen der Vorschläge auszuwählen und informiert den Client über die Auswahl mit dem {{HTTPHeader("Content-Type")}} Antwort-Header. Browser setzen erforderliche Werte für diesen Header basierend auf dem Kontext der Anfrage. Zum Beispiel verwendet ein Browser unterschiedliche Werte in einer Anfrage, wenn er ein CSS-Stylesheet, ein Bild, ein Video oder ein Skript abruft.
+Der **`Accept`** HTTP-Anfrage-Header gibt an, welche Inhaltstypen, ausgedrückt als [MIME-Typen](/de/docs/Web/HTTP/Basics_of_HTTP/MIME_types), der Client in der Lage ist zu verstehen. Der Server verwendet [Inhaltsverhandlung](/de/docs/Web/HTTP/Content_negotiation), um einen der Vorschläge auszuwählen und informiert den Client über die Auswahl mit dem {{HTTPHeader("Content-Type")}} Antwort-Header. Browser setzen erforderliche Werte für diesen Header basierend auf dem Kontext der Anfrage. Beispielsweise verwendet ein Browser unterschiedliche Werte in einer Anfrage, wenn er ein CSS-Stylesheet, ein Bild, ein Video oder ein Skript abruft.
@@ -24,9 +24,9 @@ Der **`Accept`** HTTP-Header der Anfrage gibt an, welche Inhaltstypen, ausgedrü
{{Glossary("CORS-safelisted request header")}}
- ja, mit der zusätzlichen Einschränkung, dass Werte kein
- CORS-unsicheres Anfrage-Header-Byte enthalten dürfen: 0x00-0x1F (außer 0x09 (HT)),
- "():<>?@[\]{}, und 0x7F (DEL).
+ ja, mit der zusätzlichen Einschränkung, dass Werte keine
+ CORS-unsafe request header byte enthalten dürfen: 0x00-0x1F (außer 0x09 (HT)),
+ "():<>?@[\]{} und 0x7F (DEL).
@@ -39,7 +39,7 @@ Accept: /
Accept: /*
Accept: */*
-// Mehrere Typen, gewichtet mit der Qualitätwert-Syntax:
+// Mehrere Typen, gewichtet mit der Qualitätswert-Syntax:
Accept: text/html, application/xhtml+xml, application/xml;q=0.9, image/webp, */*;q=0.8
```
@@ -48,11 +48,11 @@ Accept: text/html, application/xhtml+xml, application/xml;q=0.9, image/webp, */*
- `/`
- : Ein einzelner, präziser [MIME-Typ](/de/docs/Web/HTTP/Basics_of_HTTP/MIME_types), wie `text/html`.
- `/*`
- - : Ein MIME-Typ, aber ohne Subtyp. `image/*` entspricht `image/png`, `image/svg`, `image/gif` und anderen Bildtypen.
+ - : Ein MIME-Typ, jedoch ohne Subtyp. `image/*` entspricht `image/png`, `image/svg`, `image/gif` und anderen Bildtypen.
- `*/*`
- - : Jeder MIME-Typ.
-- `;q=` (q-Faktor Gewichtung)
- - : Ein verwendeter Wert wird in einer Präferenzreihenfolge ausgedrückt, die mit einem relativen [Qualitätswert](/de/docs/Glossary/Quality_values) genanntes _Gewicht_ dargestellt wird.
+ - : Jeder MIME-Typ
+- `;q=` (q-Faktor-Gewichtung)
+ - : Ein Wert, der verwendet wird, um eine Reihenfolge der Präferenz auszudrücken, dargestellt durch einen relativen [Qualitätswert](/de/docs/Glossary/Quality_values), der als _Gewicht_ bezeichnet wird.
## Beispiele
@@ -72,13 +72,13 @@ Accept: text/html, application/xhtml+xml, application/xml;q=0.9, */*;q=0.8
{{Specifications}}
-## Browser-Kompatibilität
+## Kompatibilität mit Browsern
{{Compat}}
## Siehe auch
-- HTTP [Content Negotiation](/de/docs/Web/HTTP/Content_negotiation)
-- [Liste der Standard-Akzeptanzwerte](/de/docs/Web/HTTP/Content_negotiation/List_of_default_Accept_values)
-- Ein Header mit dem Ergebnis der Content Negotiation: {{HTTPHeader("Content-Type")}}
+- HTTP [Inhaltsverhandlung](/de/docs/Web/HTTP/Content_negotiation)
+- [Liste der Standard-Accept-Werte](/de/docs/Web/HTTP/Content_negotiation/List_of_default_Accept_values)
+- Ein Header mit dem Ergebnis der Inhaltsverhandlung: {{HTTPHeader("Content-Type")}}
- Andere ähnliche Header: {{HTTPHeader("TE")}}, {{HTTPHeader("Accept-Encoding")}}, {{HTTPHeader("Accept-Language")}}
diff --git a/files/de/web/http/headers/access-control-allow-credentials/index.md b/files/de/web/http/headers/access-control-allow-credentials/index.md
index 497107e92..275237e04 100644
--- a/files/de/web/http/headers/access-control-allow-credentials/index.md
+++ b/files/de/web/http/headers/access-control-allow-credentials/index.md
@@ -7,21 +7,21 @@ l10n:
{{HTTPSidebar}}
-Der **`Access-Control-Allow-Credentials`** Antwort-Header teilt Browsern mit, ob der Server erlaubt, dass Cross-Origin-HTTP-Anfragen Anmeldeinformationen enthalten.
+Der **`Access-Control-Allow-Credentials`** Antwort-Header teilt Browsern mit, ob der Server erlaubt, dass Cross-Origin HTTP-Anfragen Anmeldeinformationen enthalten.
-Anmeldeinformationen sind Cookies, {{glossary("TLS")}}-Client-Zertifikate oder Authentifizierungs-Header, die einen Benutzernamen und ein Passwort enthalten. Standardmäßig werden diese Anmeldeinformationen nicht in Cross-Origin-Anfragen gesendet, da dies eine Website anfällig für {{glossary("CSRF")}}-Angriffe machen kann.
+Anmeldeinformationen sind Cookies, {{glossary("TLS")}}-Client-Zertifikate oder Authentifizierungs-Header, die einen Benutzernamen und ein Passwort enthalten. Standardmäßig werden diese Anmeldeinformationen bei Cross-Origin-Anfragen nicht mitgesendet, da dies eine Website anfällig für {{glossary("CSRF")}}-Angriffe machen kann.
-Ein Client kann verlangen, dass Anmeldeinformationen in Anfragen an andere Domänen eingeschlossen werden, auf verschiedene Weisen:
+Ein Client kann auf verschiedene Weise verlangen, dass Anmeldeinformationen in Anfragen über Seiten hinweg enthalten sein sollen:
- Durch die Verwendung von {{domxref("Window/fetch", "fetch()")}}, indem die [`credentials`](/de/docs/Web/API/RequestInit#credentials) Option auf `"include"` gesetzt wird.
- Durch die Verwendung von {{domxref("XMLHttpRequest")}}, indem die {{domxref("XMLHttpRequest.withCredentials")}} Eigenschaft auf `true` gesetzt wird.
- Durch die Verwendung von {{domxref("EventSource()")}}, indem die {{domxref("EventSource.withCredentials")}} Eigenschaft auf `true` gesetzt wird.
-Wenn der Client verlangt hat, dass Anmeldeinformationen einbezogen werden:
+Falls der Client angefordert hat, dass Anmeldeinformationen einbezogen werden:
-- Falls die Anfrage {{glossary("Preflight_request", "vorab gesichtet")}} wird, enthält die Vorab-Anfrage keine Anmeldeinformationen. Wenn die Antwort des Servers auf die Vorab-Anfrage den `Access-Control-Allow-Credentials` Header auf `true` setzt, wird die tatsächliche Anfrage Anmeldeinformationen enthalten: anderenfalls meldet der Browser einen Netzwerkfehler.
+- Wenn die Anfrage {{glossary("Preflight_request", "preflighted")}} ist, dann enthält die Preflight-Anfrage keine Anmeldeinformationen. Wenn die Serverantwort auf die Preflight-Anfrage den `Access-Control-Allow-Credentials` Header auf `true` setzt, wird die eigentliche Anfrage Anmeldeinformationen enthalten; ansonsten meldet der Browser einen Netzwerkfehler.
-- Falls die Anfrage nicht vorab gesichtet wird, wird die Anfrage Anmeldeinformationen enthalten, und wenn die Antwort des Servers nicht den `Access-Control-Allow-Credentials` Header auf `true` setzt, meldet der Browser einen Netzwerkfehler.
+- Wenn die Anfrage nicht preflighted ist, dann wird die Anfrage Anmeldeinformationen enthalten, und wenn die Serverantwort den `Access-Control-Allow-Credentials` Header nicht auf `true` setzt, meldet der Browser einen Netzwerkfehler.
@@ -30,7 +30,7 @@ Wenn der Client verlangt hat, dass Anmeldeinformationen einbezogen werden:
{{Glossary("Response header")}}
-
{{Glossary("Verbotener Header-Name")}}
+
{{Glossary("Forbidden header name")}}
nein
@@ -42,10 +42,10 @@ Wenn der Client verlangt hat, dass Anmeldeinformationen einbezogen werden:
Access-Control-Allow-Credentials: true
```
-## Direktiven
+## Anweisungen
- `true`
- - : Der einzige gültige Wert für diesen Header ist `true` (Groß-/Kleinschreibung beachten). Wenn Sie keine Anmeldeinformationen benötigen, lassen Sie diesen Header vollständig weg (statt seinen Wert auf `false` zu setzen).
+ - : Der einzige gültige Wert für diesen Header ist `true` (groß-/kleinschreibungssensitiv). Wenn Sie keine Anmeldeinformationen benötigen, lassen Sie diesen Header ganz weg (anstatt seinen Wert auf `false` zu setzen).
## Beispiele
@@ -76,7 +76,7 @@ xhr.send(null);
{{Specifications}}
-## Browser-Kompatibilität
+## Kompatibilität der Browser
{{Compat}}
diff --git a/files/de/web/http/headers/access-control-allow-headers/index.md b/files/de/web/http/headers/access-control-allow-headers/index.md
index 2dff93b47..8b7348137 100644
--- a/files/de/web/http/headers/access-control-allow-headers/index.md
+++ b/files/de/web/http/headers/access-control-allow-headers/index.md
@@ -2,25 +2,25 @@
title: Access-Control-Allow-Headers
slug: Web/HTTP/Headers/Access-Control-Allow-Headers
l10n:
- sourceCommit: 9231a7046973685f4600e1891fa644ecce41ef3b
+ sourceCommit: 5bd9fe2b25c6eee2a14d0406ce7116998fa48c13
---
{{HTTPSidebar}}
-Der **`Access-Control-Allow-Headers`** Antwort-Header wird als Reaktion auf eine {{glossary("preflight request","Vorabbefragungsanfrage")}} verwendet, die den {{HTTPHeader("Access-Control-Request-Headers")}} enthält, um anzugeben, welche HTTP-Header während der eigentlichen Anfrage verwendet werden können.
+Der **`Access-Control-Allow-Headers`** Antwort-Header wird als Antwort auf eine {{glossary("Preflight-Anfrage")}} verwendet, die den {{HTTPHeader("Access-Control-Request-Headers")}} enthält, um anzugeben, welche HTTP-Header während der eigentlichen Anfrage verwendet werden können.
Dieser Header ist erforderlich, wenn die Anfrage einen {{HTTPHeader("Access-Control-Request-Headers")}} Header enthält.
-> **Hinweis:** {{glossary("CORS-safelisted_request_header", "CORS-sicher gelistete Anforderungsheader")}} sind immer erlaubt und werden normalerweise nicht in `Access-Control-Allow-Headers` aufgeführt (es sei denn, es besteht die Notwendigkeit, die Sicherheitsliste [zusätzliche Einschränkungen](/de/docs/Glossary/CORS-safelisted_request_header#additional_restrictions) zu umgehen).
+> **Note:** {{glossary("CORS-safelisted_request_header", "CORS-sichere Anfrage-Header")}} sind immer erlaubt und werden üblicherweise nicht in `Access-Control-Allow-Headers` aufgelistet (es sei denn, es besteht die Notwendigkeit, die Safelist [zusätzliche Einschränkungen](/de/docs/Glossary/CORS-safelisted_request_header#additional_restrictions) zu umgehen).
@@ -33,18 +33,18 @@ Access-Control-Allow-Headers: [[, ]*]
Access-Control-Allow-Headers: *
```
-## Anweisungen
+## Direktiven
- ``
- - : Der Name eines unterstützten Anforderungsheaders. Der Header kann beliebig viele Headernamen, getrennt durch Kommas, auflisten.
+ - : Der Name eines unterstützten Anfrage-Headers. Der Header kann eine beliebige Anzahl von Headern auflisten, die durch Kommas getrennt sind.
- `*` (Wildcard)
- - : Der Wert "`*`" zählt nur als spezieller Wildcard-Wert für Anfragen ohne Anmeldeinformationen (Anfragen ohne [HTTP-Cookies](/de/docs/Web/HTTP/Cookies) oder HTTP-Authentifizierungsinformationen). Bei Anfragen mit Anmeldeinformationen wird es als der wörtliche Headername "`*`" ohne besondere Semantik behandelt. Beachten Sie, dass der {{HTTPHeader("Authorization")}} Header nicht als Wildcard behandelt werden kann und immer explizit aufgeführt werden muss.
+ - : Der Wert `*` zählt nur als spezieller Wildcard-Wert für Anfragen ohne Anmeldeinformationen (Anfragen ohne [HTTP-Cookies](/de/docs/Web/HTTP/Cookies) oder HTTP-Authentifizierungsinformationen). Bei Anfragen mit Anmeldeinformationen wird er als der literale Headername `*` ohne besondere Semantik behandelt. Beachten Sie, dass der {{HTTPHeader("Authorization")}} Header nicht als Wildcard zulässig ist und immer explizit aufgeführt werden muss.
## Beispiele
### Ein benutzerdefinierter Header
-Hier ist ein Beispiel dafür, wie ein `Access-Control-Allow-Headers` Header aussehen könnte. Es zeigt an, dass ein benutzerdefinierter Header namens `X-Custom-Header` von CORS-Anfragen an den Server unterstützt wird (zusätzlich zu den {{glossary("CORS-safelisted_request_header", "CORS-sicher gelisteten Anforderungsheadern")}}).
+Hier ist ein Beispiel, wie ein `Access-Control-Allow-Headers` Header aussehen könnte. Er zeigt an, dass ein benutzerdefinierter Header namens `X-Custom-Header` von CORS-Anfragen an den Server unterstützt wird (zusätzlich zu den {{glossary("CORS-safelisted_request_header", "CORS-sicheren Anfrage-Headern")}}).
```http
Access-Control-Allow-Headers: X-Custom-Header
@@ -52,7 +52,7 @@ Access-Control-Allow-Headers: X-Custom-Header
### Mehrere Header
-Dieses Beispiel zeigt `Access-Control-Allow-Headers`, wenn Unterstützung für mehrere Header angegeben wird.
+Dieses Beispiel zeigt den `Access-Control-Allow-Headers`, wenn er Unterstützung für mehrere Header angibt.
```http
Access-Control-Allow-Headers: X-Custom-Header, Upgrade-Insecure-Requests
@@ -60,21 +60,21 @@ Access-Control-Allow-Headers: X-Custom-Header, Upgrade-Insecure-Requests
### Zusätzliche Einschränkungen umgehen
-Obwohl {{glossary("CORS-safelisted_request_header", "CORS-sicher gelistete Anforderungsheader")}} immer erlaubt sind und normalerweise nicht in `Access-Control-Allow-Headers` aufgelistet werden müssen, wird durch ihre Auflistung dennoch die [zusätzlichen Einschränkungen](/de/docs/Glossary/CORS-safelisted_request_header#additional_restrictions) umgangen die gelten.
+Obwohl {{glossary("CORS-safelisted_request_header", "CORS-sichere Anfrage-Header")}} immer erlaubt sind und normalerweise nicht in `Access-Control-Allow-Headers` aufgeführt werden müssen, wird ihre Auflistung dennoch die [zusätzlichen Einschränkungen](/de/docs/Glossary/CORS-safelisted_request_header#additional_restrictions) umgehen, die gelten.
```http
Access-Control-Allow-Headers: Accept
```
-### Beispiel einer Vorabbefragungsanfrage
+### Beispiel einer Preflight-Anfrage
-Betrachten wir ein Beispiel für eine {{glossary("preflight request","Vorabbefragungsanfrage")}}, die `Access-Control-Allow-Headers` betrifft.
+Betrachten wir ein Beispiel einer {{glossary("Preflight-Anfrage")}}, die `Access-Control-Allow-Headers` beinhaltet.
#### Anfrage
-Zuerst die Anfrage. Die Vorabbefragungsanfrage ist eine {{HTTPMethod("OPTIONS","OPTIONS")}} Anfrage, die eine Kombination aus den drei Vorabbefragungsanfrage-Headers enthält: {{HTTPHeader("Access-Control-Request-Method")}}, {{HTTPHeader("Access-Control-Request-Headers")}} und {{HTTPHeader("Origin")}}.
+Zuerst die Anfrage. Die Preflight-Anfrage ist eine {{HTTPMethod("OPTIONS")}} Anfrage, die eine Kombination aus den drei Preflight-Anfrage-Headern enthält: {{HTTPHeader("Access-Control-Request-Method")}}, {{HTTPHeader("Access-Control-Request-Headers")}} und {{HTTPHeader("Origin")}}.
-Die folgende Vorabbefragungsanfrage informiert den Server darüber, dass wir eine CORS-`GET`-Anfrage mit den im {{HTTPHeader("Access-Control-Request-Headers")}} genannten Headern ({{HTTPHeader("Content-Type")}} und `X-Requested-With`) senden möchten.
+Die folgende Preflight-Anfrage teilt dem Server mit, dass wir eine CORS `GET` Anfrage mit den im {{HTTPHeader("Access-Control-Request-Headers")}} Header aufgelisteten Headern ({{HTTPHeader("Content-Type")}} und `X-Requested-With`) senden möchten.
```http
OPTIONS /resource/foo
@@ -85,7 +85,7 @@ Origin: https://foo.bar.org
#### Antwort
-Wenn die CORS-Anfrage, die durch die Vorabbefragungsanfrage angezeigt wird, autorisiert ist, antwortet der Server auf die Vorabbefragungsanfrage mit einer Nachricht, die den erlaubten Ursprung, die Methoden und die Header anzeigt. Unten sehen wir, dass `Access-Control-Allow-Headers` die angeforderten Header enthält.
+Wenn die CORS-Anfrage, die durch die Preflight-Anfrage angezeigt wird, autorisiert ist, antwortet der Server auf die Preflight-Anfrage mit einer Nachricht, die den erlaubten Ursprung, Methoden und Header anzeigt. Unten sehen wir, dass `Access-Control-Allow-Headers` die angeforderten Header beinhaltet.
```http
HTTP/1.1 200 OK
diff --git a/files/de/web/http/headers/access-control-allow-methods/index.md b/files/de/web/http/headers/access-control-allow-methods/index.md
index e9c176c93..1c66851f7 100644
--- a/files/de/web/http/headers/access-control-allow-methods/index.md
+++ b/files/de/web/http/headers/access-control-allow-methods/index.md
@@ -2,12 +2,12 @@
title: Access-Control-Allow-Methods
slug: Web/HTTP/Headers/Access-Control-Allow-Methods
l10n:
- sourceCommit: 3eea6ef9070a54ffd6379164ff9fd39db66b5172
+ sourceCommit: 5bd9fe2b25c6eee2a14d0406ce7116998fa48c13
---
{{HTTPSidebar}}
-Der **`Access-Control-Allow-Methods`** Antwort-Header gibt eine oder mehrere Methoden an, die beim Zugriff auf eine Ressource als Antwort auf eine {{glossary("preflight request")}} erlaubt sind.
+Der **`Access-Control-Allow-Methods`** Antwort-Header spezifiziert eine oder mehrere erlaubte Methoden, wenn auf eine Ressource als Antwort auf eine {{glossary("preflight request")}} zugegriffen wird.
@@ -34,8 +34,7 @@ Access-Control-Allow-Methods: *
- \
- : Eine durch Kommas getrennte Liste der erlaubten [HTTP-Anfragemethoden](/de/docs/Web/HTTP/Methods).
- `*` (Wildcard)
- - : Der Wert "`*`" zählt nur als spezieller Platzhalterwert für Anfragen
- ohne Anmeldeinformationen (Anfragen ohne [HTTP-Cookies](/de/docs/Web/HTTP/Cookies) oder HTTP-Authentifizierungsinformationen). Bei Anfragen mit Anmeldeinformationen wird er als literaler Methodenname "`*`" ohne spezielle Semantik behandelt.
+ - : Der Wert `*` zählt nur als spezieller Wildcard-Wert für Anfragen ohne Anmeldeinformationen (Anfragen ohne [HTTP-Cookies](/de/docs/Web/HTTP/Cookies) oder HTTP-Authentifizierungsinformationen). Bei Anfragen mit Anmeldeinformationen wird es als der literale Methodenname `*` ohne spezielle Semantik behandelt.
## Beispiele
@@ -48,7 +47,7 @@ Access-Control-Allow-Methods: *
{{Specifications}}
-## Browserkompatibilität
+## Browser-Kompatibilität
{{Compat}}
diff --git a/files/de/web/http/headers/access-control-allow-origin/index.md b/files/de/web/http/headers/access-control-allow-origin/index.md
index 93005eeb2..e95f112db 100644
--- a/files/de/web/http/headers/access-control-allow-origin/index.md
+++ b/files/de/web/http/headers/access-control-allow-origin/index.md
@@ -2,12 +2,12 @@
title: Access-Control-Allow-Origin
slug: Web/HTTP/Headers/Access-Control-Allow-Origin
l10n:
- sourceCommit: 0880a90f3811475d78bc4b2c344eb4146f25f66c
+ sourceCommit: 5bd9fe2b25c6eee2a14d0406ce7116998fa48c13
---
{{HTTPSidebar}}
-Der **`Access-Control-Allow-Origin`** Antwort-Header zeigt an, ob die Antwort mit anfragendem Code vom gegebenen {{glossary("origin")}} geteilt werden kann.
+Der **`Access-Control-Allow-Origin`** Antwort-Header zeigt an, ob die Antwort mit anfragendem Code von dem angegebenen {{glossary("origin")}} geteilt werden kann.
@@ -33,34 +33,34 @@ Access-Control-Allow-Origin: null
## Direktiven
- `*`
- - : Für Anfragen _ohne Anmeldeinformationen_ kann der wörtliche Wert "`*`" als Platzhalter angegeben werden; der Wert teilt den Browsern mit, dass sie anfragendem Code von jedem Ursprung den Zugriff auf die Ressource erlauben sollen. Der Versuch, den Platzhalter mit Anmeldeinformationen zu verwenden, [führt zu einem Fehler](/de/docs/Web/HTTP/CORS/Errors/CORSNotSupportingCredentials).
+ - : Für Anfragen _ohne Anmeldeinformationen_ kann der Wert `*` als Platzhalter angegeben werden; dieser Wert teilt den Browsern mit, dass die anfragende Codierung von jedem Ursprung auf die Ressource zugreifen darf. Der Versuch, den Platzhalter mit Anmeldeinformationen zu verwenden, [führt zu einem Fehler](/de/docs/Web/HTTP/CORS/Errors/CORSNotSupportingCredentials).
- ``
- : Gibt einen Ursprung an. Es kann nur ein einzelner Ursprung angegeben werden. Wenn der Server Clients von mehreren Ursprüngen unterstützt, muss er den Ursprung für den spezifischen Client zurückgeben, der die Anfrage stellt.
- `null`
- : Gibt den Ursprung "null" an.
- > **Note:** `null` [sollte nicht verwendet werden](https://w3c.github.io/webappsec-cors-for-developers/#avoid-returning-access-control-allow-origin-null): "Es mag sicher erscheinen, `Access-Control-Allow-Origin: "null"` zurückzugeben, aber die Serialisierung des Ursprungs jeder Ressource, die ein nicht-hierarchisches Schema (wie `data:` oder `file:`) und Sandbox-Dokumente verwendet, ist als "null" definiert. Viele User Agents gewähren solchen Dokumenten Zugang zu einer Antwort mit einem `Access-Control-Allow-Origin: "null"`-Header, und jeder Ursprung kann ein feindliches Dokument mit einem "null"-Ursprung erstellen. Der "null"-Wert für den ACAO-Header sollte daher vermieden werden."
+ > **Note:** `null` [sollte nicht verwendet werden](https://w3c.github.io/webappsec-cors-for-developers/#avoid-returning-access-control-allow-origin-null): "Es mag sicher erscheinen, `Access-Control-Allow-Origin: "null"` zurückzugeben, aber die Serialisierung des Ursprungs jeder Ressource, die ein nicht-hierarchisches Schema verwendet (wie `data:` oder `file:`) und sandkastenartige Dokumente ist als "null" definiert. Viele Benutzeragenten gewähren solchen Dokumenten Zugriff auf eine Antwort mit einem `Access-Control-Allow-Origin: "null"` Header, und jeder Ursprung kann ein feindliches Dokument mit einem "null" Ursprung erstellen. Der "null"-Wert für den ACAO-Header sollte daher vermieden werden."
## Beispiele
-Eine Antwort, die dem Browser mitteilt, dass Code von jedem Ursprung auf eine Ressource zugreifen darf, wird Folgendes enthalten:
+Eine Antwort, die dem Browser mitteilt, dass Code von jedem Ursprung auf eine Ressource zugreifen darf, enthält Folgendes:
```http
Access-Control-Allow-Origin: *
```
-Eine Antwort, die dem Browser mitteilt, dass anfragender Code vom Ursprung `https://developer.mozilla.org` auf eine Ressource zugreifen darf, wird Folgendes enthalten:
+Eine Antwort, die dem Browser mitteilt, dass anfragender Code vom Ursprung `https://developer.mozilla.org` auf eine Ressource zugreifen darf, enthält Folgendes:
```http
Access-Control-Allow-Origin: https://developer.mozilla.org
```
-Das Einschränken der möglichen `Access-Control-Allow-Origin`-Werte auf eine Menge erlaubter Ursprünge erfordert Code auf der Serverseite, der den Wert des {{HTTPHeader("Origin")}} Anfrage-Headers überprüft, diesen mit einer Liste erlaubter Ursprünge vergleicht und, wenn der Wert des {{HTTPHeader("Origin")}} in der Liste ist, den `Access-Control-Allow-Origin` Wert auf den gleichen Wert wie den des {{HTTPHeader("Origin")}} setzt.
+Um die möglichen Werte von `Access-Control-Allow-Origin` auf eine Menge zulässiger Ursprünge zu beschränken, ist auf der Serverseite ein Code erforderlich, der den Wert des {{HTTPHeader("Origin")}} Anfrage-Headers überprüft, diesen mit einer Liste zulässiger Ursprünge vergleicht und dann, wenn der {{HTTPHeader("Origin")}} Wert in der Liste ist, den `Access-Control-Allow-Origin` Wert auf denselben Wert wie der {{HTTPHeader("Origin")}} Wert setzt.
### CORS und Caching
-Angenommen, der Server sendet eine Antwort mit einem `Access-Control-Allow-Origin`-Wert mit einem expliziten Ursprung (anstatt des "`*`" Platzhalters). In diesem Fall sollte die Antwort auch einen {{HTTPHeader("Vary")}} Antwort-Header mit dem Wert `Origin` enthalten, um den Browsern anzuzeigen, dass Serverantworten basierend auf dem Wert des `Origin` Anfrage-Headers unterschiedlich sein können.
+Angenommen, der Server sendet eine Antwort mit einem `Access-Control-Allow-Origin` Wert mit einem expliziten Ursprung (anstatt des `*` Platzhalters). In diesem Fall sollte die Antwort auch einen {{HTTPHeader("Vary")}} Response-Header mit dem Wert `Origin` enthalten — um den Browsern anzuzeigen, dass sich Serverantworten basierend auf dem Wert des `Origin` Anfrage-Headers unterscheiden können.
```http
Access-Control-Allow-Origin: https://developer.mozilla.org
diff --git a/files/de/web/http/headers/access-control-expose-headers/index.md b/files/de/web/http/headers/access-control-expose-headers/index.md
index 2d0098de1..f3fd59711 100644
--- a/files/de/web/http/headers/access-control-expose-headers/index.md
+++ b/files/de/web/http/headers/access-control-expose-headers/index.md
@@ -2,14 +2,14 @@
title: Access-Control-Expose-Headers
slug: Web/HTTP/Headers/Access-Control-Expose-Headers
l10n:
- sourceCommit: 1cd6fbcedb0cf3cd39e74c59d70f25b07ceab82c
+ sourceCommit: 5bd9fe2b25c6eee2a14d0406ce7116998fa48c13
---
{{HTTPSidebar}}
-Der **`Access-Control-Expose-Headers`** Antwort-Header ermöglicht es einem Server anzugeben, welche Antwort-Header für Skripte, die im Browser laufen, im Rahmen einer Cross-Origin-Anfrage verfügbar gemacht werden sollen.
+Der Antwortheader **`Access-Control-Expose-Headers`** ermöglicht es einem Server anzugeben, welche Antwortheader den im Browser ausgeführten Skripten im Zuge einer Cross-Origin-Anfrage zugänglich gemacht werden sollen.
-Standardmäßig sind nur die {{Glossary("CORS-safelisted response header", "CORS-safelisted response headers")}} sichtbar. Damit Clients auf andere Header zugreifen können, muss der Server diese im `Access-Control-Expose-Headers` Header auflisten.
+Nur die {{Glossary("CORS-safelisted response header", "CORS-safelisted response headers")}} sind standardmäßig zugänglich. Damit Clients auf andere Header zugreifen können, muss der Server sie im `Access-Control-Expose-Headers`-Header aufführen.
@@ -34,19 +34,20 @@ Access-Control-Expose-Headers: *
## Direktiven
- \
- - : Eine Liste von null oder mehr durch Kommas getrennten [Header-Namen](/de/docs/Web/HTTP/Headers), auf die Clients in einer Antwort zugreifen dürfen. Diese sind _zusätzlich_ zu den {{Glossary("CORS-safelisted response header", "CORS-safelisted response headers")}}.
+ - : Eine Liste von null oder mehr durch Kommas getrennten [Header-Namen](/de/docs/Web/HTTP/Headers), auf die Clients über eine Antwort zugreifen dürfen. Diese sind _zusätzlich_ zu den {{Glossary("CORS-safelisted response header", "CORS-safelisted response headers")}}.
- `*` (Wildcard)
- - : Der Wert "`*`" zählt nur als spezieller Wildcard-Wert für Anfragen ohne Berechtigungsnachweise (Anfragen ohne [HTTP-Cookies](/de/docs/Web/HTTP/Cookies) oder HTTP-Authentifizierungsinformationen). Bei Anfragen mit Berechtigungsnachweisen wird er als wörtlicher Header-Name "`*`" behandelt.
+ - : Der Wert `*` zählt nur als spezieller Wildcard-Wert für Anfragen ohne Berechtigungsnachweise (Anfragen ohne [HTTP-Cookies](/de/docs/Web/HTTP/Cookies) oder HTTP-Authentifizierungsinformationen).
+ Bei Anfragen mit Berechtigungsnachweisen wird er als der literal Header-Name `*` behandelt.
## Beispiele
-Die {{Glossary("CORS-safelisted response header", "CORS-safelisted response headers")}} sind: {{HTTPHeader("Cache-Control")}}, {{HTTPHeader("Content-Language")}}, {{HTTPHeader("Content-Length")}}, {{HTTPHeader("Content-Type")}}, {{HTTPHeader("Expires")}}, {{HTTPHeader("Last-Modified")}}, {{HTTPHeader("Pragma")}}. Um einen nicht-CORS-safelisted Antwort-Header freizugeben, können Sie angeben:
+Die {{Glossary("CORS-safelisted response header", "CORS-safelisted response headers")}} sind: {{HTTPHeader("Cache-Control")}}, {{HTTPHeader("Content-Language")}}, {{HTTPHeader("Content-Length")}}, {{HTTPHeader("Content-Type")}}, {{HTTPHeader("Expires")}}, {{HTTPHeader("Last-Modified")}}, {{HTTPHeader("Pragma")}}. Um einen nicht-CORS-safelisted Antwortheader freizugeben, können Sie angeben:
```http
Access-Control-Expose-Headers: Content-Encoding
```
-Um zusätzlich einen benutzerdefinierten Header freizugeben, wie `Kuma-Revision`, können Sie mehrere Header durch ein Komma getrennt angeben:
+Um zusätzlich einen benutzerdefinierten Header, wie `Kuma-Revision`, freizugeben, können Sie mehrere Header durch ein Komma getrennt angeben:
```http
Access-Control-Expose-Headers: Content-Encoding, Kuma-Revision
@@ -58,7 +59,7 @@ Für Anfragen ohne Berechtigungsnachweise kann ein Server auch mit einem Wildcar
Access-Control-Expose-Headers: *
```
-Ein Server kann auch für Anfragen mit Berechtigungsnachweisen mit dem Wert `*` antworten, aber in diesem Fall würde er sich auf einen Header mit dem Namen `*` beziehen.
+Ein Server kann auch auf Anfragen mit Berechtigungsnachweisen mit dem `*` Wert antworten, in diesem Fall würde er sich auf einen Header namens `*` beziehen.
## Spezifikationen
diff --git a/files/de/web/http/headers/access-control-max-age/index.md b/files/de/web/http/headers/access-control-max-age/index.md
index fc285bced..9d91e6333 100644
--- a/files/de/web/http/headers/access-control-max-age/index.md
+++ b/files/de/web/http/headers/access-control-max-age/index.md
@@ -7,16 +7,16 @@ l10n:
{{HTTPSidebar}}
-Der **`Access-Control-Max-Age`** Antwort-Header gibt an, wie lange die Ergebnisse einer {{glossary("preflight request", "Voranfrage")}} (also die in den Headern {{HTTPHeader("Access-Control-Allow-Methods")}} und {{HTTPHeader("Access-Control-Allow-Headers")}} enthaltenen Informationen) zwischengespeichert werden können.
+Der **`Access-Control-Max-Age`** Antwort-Header gibt an, wie lange die Ergebnisse einer {{glossary("Preflight-Anfrage")}} (also die Informationen, die in den Headern {{HTTPHeader("Access-Control-Allow-Methods")}} und {{HTTPHeader("Access-Control-Allow-Headers")}} enthalten sind) zwischengespeichert werden können.
@@ -31,15 +31,15 @@ Access-Control-Max-Age:
## Direktiven
- \
- - : Maximalanzahl von Sekunden, die die Ergebnisse zwischengespeichert werden können, als unsignierte nicht-negative Ganzzahl.
- Firefox [begrenzt dies auf 24 Stunden](https://searchfox.org/mozilla-central/source/netwerk/protocol/http/nsCORSListenerProxy.cpp#1207) (86400 Sekunden).
- Chromium (vor v76) [begrenzt auf 10 Minuten](https://source.chromium.org/chromium/chromium/src/+/main:services/network/public/cpp/cors/preflight_result.cc;drc=52002151773d8cd9ffc5f557cd7cc880fddcae3e;l=36) (600 Sekunden).
- Chromium (ab v76) [begrenzt auf 2 Stunden](https://source.chromium.org/chromium/chromium/src/+/main:services/network/public/cpp/cors/preflight_result.cc;drc=49e7c0b4886cac1f3d09dc046bd528c9c811a0fa;l=31) (7200 Sekunden).
+ - : Maximale Anzahl von Sekunden, die die Ergebnisse zwischengespeichert werden können, als unsignierte nicht-negative Ganzzahl.
+ Firefox [beschränkt dies auf 24 Stunden](https://searchfox.org/mozilla-central/source/netwerk/protocol/http/nsCORSListenerProxy.cpp#1207) (86400 Sekunden).
+ Chromium (vor Version 76) [beschränkt auf 10 Minuten](https://source.chromium.org/chromium/chromium/src/+/main:services/network/public/cpp/cors/preflight_result.cc;drc=52002151773d8cd9ffc5f557cd7cc880fddcae3e;l=36) (600 Sekunden).
+ Chromium (ab Version 76) [beschränkt auf 2 Stunden](https://source.chromium.org/chromium/chromium/src/+/main:services/network/public/cpp/cors/preflight_result.cc;drc=49e7c0b4886cac1f3d09dc046bd528c9c811a0fa;l=31) (7200 Sekunden).
Der Standardwert ist 5 Sekunden.
## Beispiele
-Zwischenspeichern der Ergebnisse einer Voranfrage für 10 Minuten:
+Ergebnisse einer Preflight-Anfrage für 10 Minuten zwischenspeichern:
```http
Access-Control-Max-Age: 600
@@ -49,7 +49,7 @@ Access-Control-Max-Age: 600
{{Specifications}}
-## Browser-Kompatibilität
+## Kompatibilität der Browser
{{Compat}}
diff --git a/files/de/web/http/headers/access-control-request-headers/index.md b/files/de/web/http/headers/access-control-request-headers/index.md
index 0e614bca6..f29c54993 100644
--- a/files/de/web/http/headers/access-control-request-headers/index.md
+++ b/files/de/web/http/headers/access-control-request-headers/index.md
@@ -1,5 +1,5 @@
---
-title: Zugriffskontrolle-Anfrage-Header
+title: Access-Control-Request-Headers
slug: Web/HTTP/Headers/Access-Control-Request-Headers
l10n:
sourceCommit: 58ad1df59f2ffb9ecab4e27fe1bdf1eb5a55f89b
@@ -7,13 +7,13 @@ l10n:
{{HTTPSidebar}}
-Der **`Access-Control-Request-Headers`** Anfrage-Header wird von Browsern verwendet, wenn sie eine {{glossary("preflight request", "Preflight-Anfrage")}} senden, um dem Server mitzuteilen, welche [HTTP-Header](/de/docs/Web/HTTP/Headers) der Client möglicherweise sendet, wenn die eigentliche Anfrage gestellt wird (zum Beispiel mit {{domxref("Window/fetch", "fetch()")}} oder {{domxref("XMLHttpRequest.setRequestHeader()")}}). Der ergänzende serverseitige Header {{HTTPHeader("Access-Control-Allow-Headers")}} beantwortet diesen browserseitigen Header.
+Der **`Access-Control-Request-Headers`** Anforderungsheader wird von Browsern verwendet, wenn eine {{glossary("preflight request", "Preflight-Anfrage")}} gesendet wird, um dem Server mitzuteilen, welche [HTTP-Header](/de/docs/Web/HTTP/Headers) der Client möglicherweise sendet, wenn die eigentliche Anfrage gestellt wird (z.B. mit {{domxref("Window/fetch", "fetch()")}} oder {{domxref("XMLHttpRequest.setRequestHeader()")}}). Der entsprechende serverseitige Header {{HTTPHeader("Access-Control-Allow-Headers")}} antwortet auf diesen browserseitigen Header.
@@ -31,7 +31,7 @@ Access-Control-Request-Headers: ,,…
## Direktiven
- \
- - : Eine sortierte Liste von einzigartigen, durch Kommas getrennten, kleingeschriebenen [HTTP-Headern](/de/docs/Web/HTTP/Headers), die in der Anfrage enthalten sind.
+ - : Eine sortierte Liste von einzigartigen, kommagetrennten, kleingeschriebenen [HTTP-Headern](/de/docs/Web/HTTP/Headers), die in der Anfrage enthalten sind.
## Beispiele
@@ -43,7 +43,7 @@ Access-Control-Request-Headers: content-type,x-pingother
{{Specifications}}
-## Browserkompatibilität
+## Browser-Kompatibilität
{{Compat}}
diff --git a/files/de/web/http/headers/access-control-request-method/index.md b/files/de/web/http/headers/access-control-request-method/index.md
index ef4763e73..d3d0e72f5 100644
--- a/files/de/web/http/headers/access-control-request-method/index.md
+++ b/files/de/web/http/headers/access-control-request-method/index.md
@@ -7,21 +7,17 @@ l10n:
{{HTTPSidebar}}
-Der **`Access-Control-Request-Method`** Anforderungsheader wird
-von Browsern verwendet, wenn eine {{glossary("preflight request","Vorab-Anfrage")}} gesendet wird. Er informiert den Server darüber,
-welche [HTTP-Methode](/de/docs/Web/HTTP/Methods) bei der
-tatsächlichen Anfrage verwendet wird. Dieser Header ist notwendig, da die Vorab-Anfrage immer eine
-{{HTTPMethod("OPTIONS")}} ist und nicht die gleiche Methode wie die tatsächliche Anfrage verwendet.
+Der **`Access-Control-Request-Method`** Anforderungsheader wird von Browsern verwendet, wenn eine {{glossary("preflight request", "Vorab-Anfrage")}} gestellt wird, um dem Server mitzuteilen, welche [HTTP-Methode](/de/docs/Web/HTTP/Methods) bei der tatsächlichen Anfrage verwendet wird. Dieser Header ist notwendig, da die Vorab-Anfrage immer eine {{HTTPMethod("OPTIONS")}} ist und nicht dieselbe Methode wie die tatsächliche Anfrage verwendet.
diff --git a/files/de/web/http/headers/age/index.md b/files/de/web/http/headers/age/index.md
index c8a3e8d3a..5f4188ea7 100644
--- a/files/de/web/http/headers/age/index.md
+++ b/files/de/web/http/headers/age/index.md
@@ -1,5 +1,5 @@
---
-title: Alter
+title: Age
slug: Web/HTTP/Headers/Age
l10n:
sourceCommit: 0880a90f3811475d78bc4b2c344eb4146f25f66c
@@ -7,9 +7,9 @@ l10n:
{{HTTPSidebar}}
-Der **`Age`**-Header enthält die Zeit in Sekunden, die das Objekt in einem Proxy-Cache war.
+Der **`Age`**-Header enthält die Zeit in Sekunden, die das Objekt im Proxy-Cache war.
-Der `Age`-Header ist normalerweise nahe null. Wenn er `Age: 0` ist, wurde das Objekt wahrscheinlich vom Ursprungsserver abgerufen; andernfalls wurde er normalerweise als Differenz zwischen dem aktuellen Datum des Proxys und dem im HTTP-Antwortheader enthaltenen {{HTTPHeader("Date")}}-Header berechnet.
+Der `Age`-Header ist normalerweise nahe null. Wenn er `Age: 0` ist, wurde er wahrscheinlich vom Ursprungsserver abgerufen; andernfalls wurde er normalerweise als Differenz zwischen dem aktuellen Datum des Proxys und dem im HTTP-Response enthaltenen allgemeinen {{HTTPHeader("Date")}}-Header berechnet.
@@ -33,7 +33,7 @@ Age:
## Direktiven
- \
- - : Eine nicht-negative ganze Zahl, die die Zeit im Sekunden angibt, die das Objekt in einem Proxy-Cache war.
+ - : Eine nicht-negative Ganzzahl, die die Zeit in Sekunden angibt, die das Objekt im Proxy-Cache war.
## Beispiele
diff --git a/files/de/web/http/headers/allow/index.md b/files/de/web/http/headers/allow/index.md
index 5c2ad0f57..1e07cda4c 100644
--- a/files/de/web/http/headers/allow/index.md
+++ b/files/de/web/http/headers/allow/index.md
@@ -1,5 +1,5 @@
---
-title: Erlauben
+title: Allow
slug: Web/HTTP/Headers/Allow
l10n:
sourceCommit: 0880a90f3811475d78bc4b2c344eb4146f25f66c
@@ -9,7 +9,7 @@ l10n:
Der **`Allow`**-Header listet die Menge der von einer Ressource unterstützten Methoden auf.
-Dieser Header muss gesendet werden, wenn der Server mit einem {{HTTPStatus("405")}} `Method Not Allowed` Statuscode antwortet, um anzugeben, welche Anfragemethoden verwendet werden können. Ein leerer `Allow`-Header zeigt an, dass die Ressource keine Anfragemethoden zulässt, was möglicherweise temporär für eine bestimmte Ressource geschieht, zum Beispiel.
+Dieser Header muss gesendet werden, wenn der Server mit dem Statuscode {{HTTPStatus("405")}} `Method Not Allowed` antwortet, um anzuzeigen, welche Anfragemethoden verwendet werden können. Ein leerer `Allow`-Header bedeutet, dass die Ressource keine Anfragemethoden zulässt, was zum Beispiel vorübergehend für eine bestimmte Ressource auftreten könnte.
@@ -19,7 +19,7 @@ Dieser Header muss gesendet werden, wenn der Server mit einem {{HTTPStatus("405"
{{Glossary("Forbidden header name")}}
-
no
+
nein
@@ -33,7 +33,7 @@ Allow:
## Direktiven
- \
- - : Die durch Kommas getrennte Liste der erlaubten [HTTP-Anfragemethoden](/de/docs/Web/HTTP/Methods).
+ - : Die durch Komma getrennte Liste der erlaubten [HTTP-Anfragemethoden](/de/docs/Web/HTTP/Methods).
## Beispiele
diff --git a/files/de/web/http/headers/alt-svc/index.md b/files/de/web/http/headers/alt-svc/index.md
index c25e95323..0e184a972 100644
--- a/files/de/web/http/headers/alt-svc/index.md
+++ b/files/de/web/http/headers/alt-svc/index.md
@@ -7,9 +7,9 @@ l10n:
{{HTTPSidebar}}
-Der **`Alt-Svc`** HTTP-Header ermöglicht es einem Server anzuzeigen, dass eine andere Netzwerkadresse (der "alternative Dienst") als autoritativ für diesen Ursprung angesehen werden kann, wenn zukünftige Anfragen gemacht werden.
+Der **`Alt-Svc`** HTTP-Header erlaubt einem Server anzugeben, dass eine andere Netzwerkadresse (der "alternative Dienst") als autoritativ für diese Herkunft behandelt werden kann, wenn in Zukunft Anfragen gestellt werden.
-Dies ermöglicht es, neue Protokollversionen zu bewerben, ohne sich auf derzeitige Anfragen auszuwirken, und hilft Servern auch bei der Verkehrsverwaltung. Die Nutzung eines alternativen Dienstes ist für den Endbenutzer nicht sichtbar; es ändert nicht die URL oder den Ursprung der Anfrage und führt nicht zu zusätzlichen Umlaufzeiten.
+Dies ermöglicht es, neue Protokollversionen zu bewerben, ohne die laufenden Anfragen zu beeinflussen, und kann auch Servern helfen, den Datenverkehr zu verwalten. Die Verwendung eines alternativen Dienstes ist für den Endbenutzer nicht sichtbar; sie ändert weder die URL noch die Herkunft der Anfrage und verursacht keine zusätzlichen Roundtrips.
## Syntax
@@ -20,22 +20,22 @@ Alt-Svc: =; ma=; persist=1
```
- `clear`
- - : Der spezielle Wert `clear` zeigt an, dass der Ursprung verlangt, dass alle alternativen Dienste für diesen Ursprung ungültig gemacht werden.
+ - : Der spezielle Wert `clear` zeigt an, dass die Herkunft anfordert, dass alle alternativen Dienste für diese Herkunft ungültig gemacht werden.
- ``
- - : Der {{Glossary("ALPN")}} Protokollbezeichner. Beispiele umfassen `h2` für HTTP/2 und `h3-25` für Entwurf 25 des HTTP/3-Protokolls.
+ - : Der {{Glossary("ALPN")}}-Protokoll-Identifier. Beispiele sind `h2` für HTTP/2 und `h3-25` für Entwurf 25 des HTTP/3-Protokolls.
- ``
- - : Der angegebene alternative Autoritäts-String besteht aus einem optionalen Host-Überschreibung, einem Doppelpunkt und einer obligatorischen Portnummer.
+ - : Der zitierte String, der die alternative Autorität spezifiziert. Er besteht aus einer optionalen Host-Überschreibung, einem Doppelpunkt und einer obligatorischen Portnummer.
- `ma=` {{optional_inline}}
- - : Die Anzahl der Sekunden, während der der alternative Dienst als aktuell betrachtet wird.
- Falls ausgelassen, wird standardmäßig 24 Stunden angenommen.
- Alternative Dienst-Einträge können bis zu _\_ Sekunden zwischengespeichert werden, minus dem Alter der Antwort (aus dem {{httpheader("Age")}} Header).
- Sobald der zwischengespeicherte Eintrag abläuft, kann der Client diesen alternativen Dienst nicht mehr für neue Verbindungen nutzen.
+ - : Die Anzahl von Sekunden, für die der alternative Dienst als frisch betrachtet wird.
+ Wenn weggelassen, beträgt der Standardwert 24 Stunden.
+ Einträge für alternative Dienste können bis zu _\_ Sekunden, abzüglich des Alters der Antwort (vom {{httpheader("Age")}}-Header) im Cache gespeichert werden.
+ Sobald der zwischengespeicherte Eintrag abläuft, kann der Client diesen alternativen Dienst nicht mehr für neue Verbindungen verwenden.
- `persist=1` {{optional_inline}}
- - : Normalerweise werden zwischengespeicherte alternative Dienst-Einträge bei Änderungen in der Netzwerkkonfiguration gelöscht.
- Die Nutzung des Parameters `persist=1` verlangt, dass der Eintrag durch solche Änderungen nicht gelöscht wird.
+ - : Normalerweise werden zwischengespeicherte Einträge für alternative Dienste bei Änderungen an der Netzwerkkonfiguration gelöscht.
+ Die Verwendung des Parameters `persist=1` fordert, dass der Eintrag durch solche Änderungen nicht gelöscht wird.
-Mehrere Einträge können in einem einzigen `Alt-Svc` Header durch Kommata getrennt angegeben werden.
-In diesem Fall werden frühere Einträge als vorzuziehender betrachtet.
+Mehrere Einträge können in einem einzigen `Alt-Svc`-Header durch Kommas getrennt angegeben werden.
+In diesem Fall werden frühere Einträge als bevorzugter betrachtet.
## Beispiel
@@ -56,4 +56,4 @@ Alt-Svc: h3-25=":443"; ma=3600, h2=":443"; ma=3600
## Siehe auch
-- [Alternative Services](https://www.mnot.net/blog/2016/03/09/alt-svc) (Artikel über `Alt-Svc` von dem Vorsitzenden der HTTP-Arbeitsgruppe Mark Nottingham)
+- [Alternative Services](https://www.mnot.net/blog/2016/03/09/alt-svc) (Artikel über `Alt-Svc` von Mark Nottingham, Vorsitzender der HTTP Working Group)
diff --git a/files/de/web/http/headers/alt-used/index.md b/files/de/web/http/headers/alt-used/index.md
index 17af86cba..3e8e3b548 100644
--- a/files/de/web/http/headers/alt-used/index.md
+++ b/files/de/web/http/headers/alt-used/index.md
@@ -7,11 +7,11 @@ l10n:
{{HTTPSidebar}}
-Der **`Alt-Used`** HTTP-Header wird in Anfragen verwendet, um den verwendeten alternativen Dienst zu identifizieren, genau wie das {{HTTPHeader("Host")}} HTTP-Headerfeld den Host und Port des Ursprungs identifiziert.
+Der **`Alt-Used`** HTTP-Header wird in Anfragen verwendet, um den in Gebrauch befindlichen alternativen Dienst zu identifizieren, genauso wie das {{HTTPHeader("Host")}} HTTP-Header-Feld den Host und Port des Ursprungs identifiziert.
-Er soll alternativen Diensten ermöglichen, Schleifen zu erkennen, den Datenverkehr zu differenzieren, um Lastverteilung zu ermöglichen, und allgemein sicherzustellen, dass das beabsichtigte Ziel des Datenverkehrs erkennbar ist, da sich das Einführen dieser Information nach Einsetzen eines Protokolls als problematisch erwiesen hat.
+Er ist dazu gedacht, alternativen Diensten das Erkennen von Schleifen zu ermöglichen, den Verkehr zwecks Lastverteilung zu differenzieren und generell sicherzustellen, dass es möglich ist, das beabsichtigte Ziel des Verkehrs zu identifizieren, da die Einführung dieser Information nach der Verwendung eines Protokolls sich als problematisch erwiesen hat.
-Wenn ein Client für eine Anfrage einen alternativen Dienst verwendet, kann er dies dem Server über den **`Alt-Used`** HTTP-Header anzeigen.
+Wenn ein Client für eine Anfrage einen alternativen Dienst verwendet, kann er dies dem Server über den **`Alt-Used`** HTTP-Header mitteilen.
## Syntax
@@ -22,9 +22,9 @@ Alt-Used: :
## Direktiven
- \
- - : Der Domainname des Servers.
+ - : der Domainname des Servers.
- \ {{optional_inline}}
- - : TCP-Portnummer, auf dem der Server lauscht.
+ - : TCP-Portnummer, an der der Server lauscht.
## Beispiele
diff --git a/files/de/web/http/headers/attribution-reporting-eligible/index.md b/files/de/web/http/headers/attribution-reporting-eligible/index.md
index 5f82636e5..2071da8ca 100644
--- a/files/de/web/http/headers/attribution-reporting-eligible/index.md
+++ b/files/de/web/http/headers/attribution-reporting-eligible/index.md
@@ -7,9 +7,9 @@ l10n:
{{HTTPSidebar}}{{SeeCompatTable}}
-Der **`Attribution-Reporting-Eligible`** Anforderungsheader zeigt an, dass die entsprechende Antwort berechtigt ist, eine Attribution-Quelle oder einen Auslöser zu registrieren.
+Der **`Attribution-Reporting-Eligible`** Anforderungsheader zeigt an, dass die entsprechende Antwort berechtigt ist, eine Attributionsquelle oder einen Auslöser zu registrieren.
-Dieser Header wird nie manuell gesetzt, sondern vom Browser als Reaktion auf verschiedene HTML-Element- oder JavaScript-Anforderungseinstellungen gesendet. Abhängig von den im `Attribution-Reporting-Eligible`-Wert angegebenen erlaubten Registrierungen wird vom Server erwartet, dass er mit einem {{httpheader("Attribution-Reporting-Register-Source")}}- oder {{httpheader("Attribution-Reporting-Register-Trigger")}}-Header antwortet, um die Registrierung einer Attributionsquelle oder eines Auslösers abzuschließen.
+Dieser Header wird niemals manuell gesetzt, sondern vom Browser als Antwort auf verschiedene HTML-Element- oder JavaScript-Anforderungseinstellungen gesendet. Je nach den in dem `Attribution-Reporting-Eligible`-Wert spezifizierten erlaubten Registrierungen wird erwartet, dass der Server mit einem {{httpheader("Attribution-Reporting-Register-Source")}} oder {{httpheader("Attribution-Reporting-Register-Trigger")}} Header antwortet, um die Registrierung einer Attributionsquelle oder eines Auslösers abzuschließen.
Siehe die [Attribution Reporting API](/de/docs/Web/API/Attribution_Reporting_API) für weitere Details.
@@ -32,18 +32,18 @@ Siehe die [Attribution Reporting API](/de/docs/Web/API/Attribution_Reporting_API
Attribution-Reporting-Eligible:
```
-## Direktiven
+## Richtlinien
- ``
- : Ein strukturiertes Header-Wörterbuch, das die in der entsprechenden Antwort erlaubten Registrierungen darstellt. Mögliche Schlüssel sind:
- `event-source`
- - : Eine [ereignisbasierte Attribution-Quelle](/de/docs/Web/API/Attribution_Reporting_API/Registering_sources#event-based_attribution_sources) kann registriert werden.
+ - : Eine [ereignisbasiertes Attributionsquelle](/de/docs/Web/API/Attribution_Reporting_API/Registering_sources#event-based_attribution_sources) kann registriert werden.
- `navigation-source`
- - : Eine [navigationsbasierte Attribution-Quelle](/de/docs/Web/API/Attribution_Reporting_API/Registering_sources#navigation-based_attribution_sources) kann registriert werden.
+ - : Eine [navigationsbasierte Attributionsquelle](/de/docs/Web/API/Attribution_Reporting_API/Registering_sources#navigation-based_attribution_sources) kann registriert werden.
- `trigger`
- : Ein [Attributionsauslöser](/de/docs/Web/API/Attribution_Reporting_API/Registering_triggers) kann registriert werden.
-Jede Antwort in einer Weiterleitungskette kann höchstens eine Quelle oder einen Auslöser registrieren.
+Jede Antwort in einer Umleitungskette kann höchstens eine Quelle oder einen Auslöser registrieren.
## Beispiele
diff --git a/files/de/web/http/headers/attribution-reporting-register-source/index.md b/files/de/web/http/headers/attribution-reporting-register-source/index.md
index 0494356a7..18b3c5eca 100644
--- a/files/de/web/http/headers/attribution-reporting-register-source/index.md
+++ b/files/de/web/http/headers/attribution-reporting-register-source/index.md
@@ -2,17 +2,17 @@
title: Attribution-Reporting-Register-Source
slug: Web/HTTP/Headers/Attribution-Reporting-Register-Source
l10n:
- sourceCommit: bb23abe84f0f4da3cf5d72a66d356cf5f9e3cfa2
+ sourceCommit: 0a9c10fc67901972221dc7b3d006334fbfa73dce
---
{{HTTPSidebar}}{{seecompattable}}
-Der **`Attribution-Reporting-Register-Source`** Header registriert ein Seitenmerkmal als eine [Attributionsquelle](/de/docs/Web/API/Attribution_Reporting_API/Registering_sources). Dieser ist Teil einer Antwort auf eine Anfrage, die einen {{httpheader("Attribution-Reporting-Eligible")}} Header beinhaltet hat. Er liefert die Informationen, die der Browser speichern soll, wenn auf die Attributionsquelle zugegriffen wird. Die Informationen, die Sie in diesen Header aufnehmen, bestimmen auch, welche Arten von Berichten der Browser erstellen kann.
+Der **`Attribution-Reporting-Register-Source`** Header registriert ein Seitenmerkmal als [Attributionsquelle](/de/docs/Web/API/Attribution_Reporting_API/Registering_sources). Dies wird als Teil einer Antwort auf eine Anfrage eingeschlossen, die einen {{httpheader("Attribution-Reporting-Eligible")}} Header enthielt. Es liefert die Informationen, die der Browser speichern soll, wenn mit der Attributionsquelle interagiert wird. Die in diesem Header enthaltenen Informationen bestimmen auch, welche Arten von Berichten der Browser generieren kann.
-Weitere Details finden Sie in der [Attribution Reporting API](/de/docs/Web/API/Attribution_Reporting_API).
+Siehe die [Attribution Reporting API](/de/docs/Web/API/Attribution_Reporting_API) für weitere Details.
> [!NOTE]
-> Wenn die aufrufende Seite die Attribution Reporting API nicht im Rahmen eines erfolgreichen [Privacy Sandbox-Anmeldeprozesses](/de/docs/Web/Privacy/Privacy_sandbox/Enrollment) integriert hat, wird der `Attribution-Reporting-Register-Source` Header ignoriert und Attributionsquellen werden nicht registriert.
+> Wenn die aufrufende Seite die Attribution Reporting API nicht in einem erfolgreichen [Datenschutz-Sandbox-Registrierungsprozess](/de/docs/Web/Privacy/Privacy_sandbox/Enrollment) enthalten hat, wird der `Attribution-Reporting-Register-Source` Header ignoriert und Attributionsquellen werden nicht registriert.
@@ -43,66 +43,66 @@ Attribution-Reporting-Register-Source:
- ``
- - : Ein JSON-String, der die Informationen bereitstellt, die der Browser speichern soll, wenn mit der Attributionsquelle interagiert wird. Verfügbare Felder sind:
+ - : Ein JSON-String, der die Informationen bereitstellt, die der Browser speichern soll, wenn mit der Attributionsquelle interagiert wird. Verfügbare Felder sind wie folgt:
- `"source_event_id"` {{optional_inline}}
- - : Ein String, der eine ID für die Attributionsquelle darstellt, die verwendet werden kann, um sie bei einer Interaktion mit der Quelle auf andere Informationen abzubilden oder Informationen am Berichts-Endpunkt zu aggregieren. Der String muss ausschließlich aus einer in Basis-10 formatierten 64-Bit-Integerzahl bestehen.
+ - : Ein String, der eine ID für die Attributionsquelle darstellt, die verwendet werden kann, um sie anderen Informationen zuzuordnen, wenn mit der Attributionsquelle interagiert wird, oder um Informationen am Berichtsendpunkt zu aggregieren. Der String muss ausschließlich aus einer im Basis-10-Format formatierten 64-Bit-Zahl bestehen.
- `"destination"`
- - : Ein einzelner String oder ein Array von 1–3 Strings. Diese Strings müssen eine vollständige URL enthalten, die der Seite (Schema + [eTLD+1](/de/docs/Glossary/eTLD)) entspricht, auf der ein Auslöser erwartet wird. Diese werden verwendet, um den Attributionstrigger mit der Quelle abzugleichen, wenn ein Auslöser aktiv wird.
+ - : Ein einziger String oder ein Array von 1–3 Strings. Diese Strings müssen eine vollständige URL enthalten, die der Seite (Schema + [eTLD+1](/de/docs/Glossary/eTLD)) entspricht, auf der ein Trigger erwartet wird. Diese werden verwendet, um den Attributionstrigger mit der Quelle abzugleichen, wenn mit einem Trigger interagiert wird.
- `"aggregation_keys"` {{optional_inline}}
- - : Ein Objekt, das benutzerdefinierte Schlüssel enthält, die verschiedene Datenpunkte darstellen, unter denen Berichtswerte aggregiert werden sollen.
+ - : Ein Objekt, das vom Benutzer bereitgestellte Schlüssel enthält, die verschiedene Datenpunkte darstellen, um Berichtswerte zusammenzufassen.
- `"aggregatable_report_window"` {{optional_inline}}
- - : Ein String, der eine Zeit in Sekunden darstellt, nach der Triggerdaten in generierten aggregierbaren Berichten nicht mehr enthalten sein werden (dies wird als **Berichtszeitfenster** bezeichnet). Wenn nicht gesetzt, wird standardmäßig der `"expiry"`-Wert verwendet.
+ - : Ein String, der eine Zeit in Sekunden darstellt, nach der Triggerdaten nicht mehr in generierte aggregierbare Berichte aufgenommen werden (dies wird als **Berichtsfenster** bezeichnet). Falls nicht gesetzt, wird standardmäßig der Wert `"expiry"` verwendet.
- `"debug_key"` {{optional_inline}}
- - : Ein 64-Bit unsigned Integer in Basis-10-Format, der einen Debug-Schlüssel darstellt. Setzen Sie diesen, wenn Sie einen [Debug-Bericht](/de/docs/Web/API/Attribution_Reporting_API/Generating_reports#debug_reports) zusammen mit dem zugehörigen Attributionsbericht generieren möchten.
+ - : Ein im Basis-10-Format formulierter 64-Bit-Ganzzahl, der einen Debug-Schlüssel darstellt. Setzen Sie diesen, wenn Sie einen [Debug-Bericht](/de/docs/Web/API/Attribution_Reporting_API/Generating_reports#debug_reports) zusammen mit dem zugehörigen Attributionsbericht generieren möchten.
- `"debug_reporting"` {{optional_inline}}
- - : Ein boolescher Wert. Wenn ein `debug_key` gesetzt ist, setzen Sie dies auf `true`, um anzugeben, dass der generierte Debug-Bericht ein ausführlicher Debug-Bericht sein soll.
+ - : Ein boolescher Wert. Wenn ein `debug_key` gesetzt ist, setzen Sie diesen auf `true`, um festzulegen, dass der generierte Debug-Bericht ein ausführlicher Debug-Bericht sein soll.
- `"event_level_epsilon"` {{optional_inline}}
- - : Eine Zahl, die größer oder gleich `0` ist und die Menge des [Rauschens, das Berichten hinzugefügt wird](/de/docs/Web/API/Attribution_Reporting_API/Generating_reports#adding_noise_to_reports), kontrolliert. Niedrigere Werte von Epsilon führen zu mehr Rauschen und bieten daher einen höheren Schutz der Privatsphäre. Die maximalen und Standardwerte variieren je nach Implementierung; Chrome hat zum Beispiel einen maximalen und Standardwert von `14`.
+ - : Eine Zahl, die gleich oder größer als `0` ist und die Menge des [Rauschens, das Berichten hinzugefügt wird](/de/docs/Web/API/Attribution_Reporting_API/Generating_reports#adding_noise_to_reports), steuert. Niedrigere Epsilon-Werte führen zu mehr Rauschen und bieten daher einen besseren Schutz der Privatsphäre. Die maximalen und die Standardwerte variieren je nach Implementierung; Chrome hat beispielsweise einen maximalen und einen Standardwert von `14`.
- `"event_report_window"` {{optional_inline}}
- - : Ein String, der eine Zeit in Sekunden darstellt, nach der nachfolgende Trigger nicht mehr dieser Quelle für den Zweck der Erstellung von Ereignis-Ebenen-Berichten zugeordnet werden (dies wird als **Berichtszeitfenster** bezeichnet). Wenn nicht gesetzt, fällt das Ereignis-Berichtszeitfenster auf den `"expiry"`-Wert zurück.
+ - : Ein String, der eine Zeit in Sekunden darstellt, nach der nachfolgende Trigger dieser Quelle nicht mehr zugeordnet werden können, um Ereignisberichte zu erstellen (dies wird als **Berichtsfenster** bezeichnet). Falls nicht gesetzt, fällt das Ereignisberichtsfenster auf den Wert `"expiry"` zurück.
> [!NOTE]
- > Wenn `"event_report_window"` angegeben ist, kann `"event_report_windows"` nicht angegeben werden, da die Quellregistrierung andernfalls fehlschlagen würde.
+ > Wenn `"event_report_window"` festgelegt ist, kann `"event_report_windows"` nicht angegeben werden, ansonsten schlägt die Quellenregistrierung fehl.
- `"event_report_windows"` {{optional_inline}}
- - : Ein Objekt, das eine Reihe von Berichtsfenstern darstellt, beginnend mit `"start_time"`, wobei Berichte für diese Quelle nach jedem angegebenen Endzeitpunkt in `"end_times"` geliefert werden. Dies kann verwendet werden, um die Zeit der Berichterstellung über mehrere Berichte hinweg zu variieren. Wird es nicht gesetzt, fällt das Ereignis-Berichtszeitfenster auf den `"expiry"`-Wert zurück. Die Eigenschaften sind wie folgt:
- - `"start_time"` {{optional_inline}}: Eine nicht-negative Zahl, die die Startzeit für die Berichtsfenster spezifiziert. Wenn nicht angegeben, ist der Standardwert `0`.
- - `"end_times"`: Ein Array von positiven Zahlen, die Endzeiten für nachfolgende Berichtsfenster spezifizieren. Die Werte müssen aufsteigend und größer als `"start_time"` sein.
+ - : Ein Objekt, das eine Reihe von Berichtsfenstern darstellt, die bei `"start_time"` beginnen und bei denen Berichte für diese Quelle nach jeder angegebenen Endzeit in `"end_times"` bereitgestellt werden. Dies kann verwendet werden, um die Zeit der Berichterstattung über mehrere Berichte zu variieren. Falls nicht gesetzt, fällt das Ereignisberichtsfenster auf den Wert `"expiry"` zurück. Eigenschaften sind wie folgt:
+ - `"start_time"` {{optional_inline}}: Eine nicht-negative Zahl, die die Startzeit für die Berichtsfenster angibt. Falls nicht angegeben, wird `0` als Standardwert gesetzt.
+ - `"end_times"`: Ein Array von positiven Zahlen, die Endzeiten für nachfolgende Berichtsfenster angeben. Die Werte müssen zunehmen und größer als `"start_time"` sein.
> [!NOTE]
- > Wenn `"event_report_windows"` angegeben ist, kann `"event_report_window"` nicht angegeben werden, da die Quellregistrierung andernfalls fehlschlagen würde.
+ > Wenn `"event_report_windows"` festgelegt ist, kann `"event_report_window"` nicht angegeben werden, ansonsten schlägt die Quellenregistrierung fehl.
- `"expiry"` {{optional_inline}}
- - : Ein String, der eine Ablaufzeit in Sekunden für die Attributionsquelle darstellt, nach der sie nicht mehr aktiv ist (d.h., nachfolgende Trigger werden dieser Quelle nicht mehr zugeordnet). Die maximal zulässige Ablaufzeit beträgt 2592000 Sekunden (30 Tage), was auch der Standardwert ist, wenn `"expiry"` nicht explizit gesetzt ist.
+ - : Ein String, der eine Ablaufzeit in Sekunden für die Attributionsquelle darstellt, nach der sie nicht mehr aktiv ist (d.h. nachfolgende Trigger sind dieser Quelle nicht mehr zuordenbar). Die maximal zulässige Ablaufzeit beträgt 2592000 Sekunden (30 Tage), was auch der Standardwert ist, wenn `"expiry"` nicht explizit festgelegt wird.
- `"filter_data"` {{optional_inline}}
- - : Ein Objekt, das benutzerdefinierte Daten definiert, die verwendet werden können, um zu filtern, welche Konversionen Berichte erzeugen. Weitere Informationen finden Sie unter [Filter](/de/docs/Web/API/Attribution_Reporting_API/Generating_reports#filters).
+ - : Ein Objekt, das benutzerdefinierte Daten definiert, die verwendet werden können, um zu filtern, welche Konversionen Berichte generieren. Weitere Details finden Sie unter [Filter](/de/docs/Web/API/Attribution_Reporting_API/Generating_reports#filters).
- `"max_event_level_reports"` {{optional_inline}}
- - : Eine Zahl zwischen `0` und `20` inklusive, die die Gesamtanzahl der Berichte auf Ereignis-Ebene festlegt, die diese Quelle erzeugen kann. Nach Erreichen dieses Maximums ist die Quelle nicht mehr in der Lage, neue Daten zu erzeugen. Wenn nicht angegeben, ist der Standardwert für `"max_event_level_reports"` `3` für navigationsbasierte Quellen und `1` für ereignisbasierte Quellen (bild- oder skriptbasiert).
+ - : Eine Zahl zwischen `0` und `20` inklusive, die die Gesamtanzahl der Ereignisberichte spezifiziert, die diese Quelle generieren kann. Nach Erreichen dieses Maximums ist die Quelle nicht mehr in der Lage, neue Daten zu produzieren. Wenn nicht angegeben, wird `"max_event_level_reports"` standardmäßig für navigationsbasierte Quellen auf `3` und für ereignisbasierte (bild- oder skriptbasierte) Quellen auf `1` gesetzt.
- `"priority"` {{optional_inline}}
- - : Ein String, der einen Prioritätswert für die Attributionsquelle darstellt. Standardmäßig werden Konversionen der neuesten übereinstimmenden Quelle zugeordnet. Für sowohl ereignisbasierte als auch zusammenfassende Berichte können Sie eine höhere Prioritätsnummer setzen, um bestimmte Quellen zu priorisieren. Beispielsweise hat ein Wert von `2` Vorrang vor dem Standardwert von `1`. Weitere Informationen finden Sie unter [Berichtsprioritäten und -grenzen](/de/docs/Web/API/Attribution_Reporting_API/Generating_reports#report_priorities_and_limits).
+ - : Ein String, der einen Prioritätswert für die Attributionsquelle darstellt. Standardmäßig werden Konversionen der zuletzt übereinstimmenden Quelle zugeordnet. Für sowohl ereignisbasierten als auch zusammenfassenden Berichten setzen Sie eine höhere Prioritätsnummer, um spezifische Quellen zu priorisieren. Zum Beispiel hat ein Wert von `2` Vorrang vor dem Standardwert von `1`. Weitere Informationen finden Sie unter [Berichtsprioritäten und -beschränkungen](/de/docs/Web/API/Attribution_Reporting_API/Generating_reports#report_priorities_and_limits).
- `"trigger_data"` {{optional_inline}}
- - : Ein Array von 32-Bit unsigned Integer-Zahlen, die Daten darstellen, die die verschiedenen Triggerereignisse beschreiben, die mit dieser Quelle übereinstimmen könnten. Zum Beispiel könnten "Benutzer fügte Artikel zum Warenkorb hinzu" oder "Benutzer meldete sich für die Mailingliste an" Aktionen sein, die auf der Triggerseite stattfinden und diese Quelle entsprechend einer Art von Konversion darstellen, die der Werbetreibende messen möchte. Diese müssen mit `"trigger_data"` übereinstimmen, die in den [Triggers](/de/docs/Web/HTTP/Headers/Attribution-Reporting-Register-Trigger#trigger_data) angegeben sind, damit eine Attributierung auf Ereignis-Ebene erfolgt. Wenn nicht angegeben, ist der Standardwert für `"trigger_data"` `[0, 1, 2, 3, 4, 5, 6, 7]` für navigationsbasierte Quellen und `[0, 1]` für ereignisbasierte (bild- oder skriptbasierte) Quellen.
+ - : Ein Array von 32-Bit-Ganzzahlen ohne Vorzeichen, die Daten darstellen, die die verschiedenen Triggerereignisse beschreiben, die zu dieser Quelle passen könnten. Beispielsweise könnten "Benutzer hat Artikel in den Warenkorb gelegt" oder "Benutzer hat sich für Mailingliste angemeldet" Aktionen sein, die auf der Triggerseite stattfinden und diese Quelle und eine Art von Konversion anzeigen, die der Werbetreibende messen möchte. Diese müssen mit `"trigger_data"` übereinstimmen, die in [Triggers](/de/docs/Web/HTTP/Headers/Attribution-Reporting-Register-Trigger#trigger_data) angegeben ist, damit eine ereignisbasierte Attribution stattfinden kann. Wenn weggelassen, wird `"trigger_data"` standardmäßig auf `[0, 1, 2, 3, 4, 5, 6, 7]` für navigationsbasierte Quellen und `[0, 1]` für ereignisbasierte (bild- oder skriptbasierte) Quellen gesetzt.
> [!NOTE]
- > Die Werte, die jedes Ereignis darstellen, und die Anzahl der Elemente im Array sind vollständig willkürlich und von Ihnen als Entwickler definiert. Das Array kann Werte enthalten, die nicht verwendet werden, aber es müssen Werte im Array vorhanden sein, um von dem Browser der Quelle bei der Registrierung eines Triggers zugeordnet zu werden.
+ > Die Werte, die jedes Ereignis darstellen, und die Anzahl der Elemente im Array sind völlig willkürlich und von Ihnen als Entwickler definiert. Das Array kann Werte enthalten, die nicht verwendet werden, aber Werte müssen im Array vorhanden sein, um von der Quelle bei der Registrierung eines Triggers durch den Browser zugeordnet zu werden.
- `"trigger_data_matching"` {{optional_inline}}
- : Ein String, der angibt, wie das `"trigger_data"` des Triggers mit dem `"trigger_data"` der Quelle abgeglichen wird. Mögliche Werte sind:
- - `"exact"`: Das `"trigger_data"` des Triggers muss genau mit einem Wert im `"trigger_data"` der Quelle übereinstimmen; wenn es keine solche Übereinstimmung gibt, findet keine Attributierung auf Ereignis-Ebene statt.
- - `"modulus"`: In diesem Fall wird die folgende Berechnung durchgeführt — `d % allowedValues.size` — wobei `d` das `"trigger_data"` des Triggers ist, und `allowedValues` die Abfolge von Werten im `"trigger_data"`-Array der Quelle ist. Wenn das Ergebnis dieser Berechnung mit einem Wert im `"trigger_data"`-Array der Quelle übereinstimmt, ist die Übereinstimmung erfolgreich. In einem solchen Fall wird der Wert immer übereinstimmen, es sei denn, `allowedValues` ist leer.
+ - `"exact"`: Das `"trigger_data"` des Triggers muss genau mit einem Wert übereinstimmen, der im `"trigger_data"` der Quelle enthalten ist; wenn es keine solche Übereinstimmung gibt, findet keine ereignisbasierte Attribution statt.
+ - `"modulus"`: In diesem Fall wird die folgende Berechnung durchgeführt — `d % allowedValues.size` — wobei `d` das `"trigger_data"` des Triggers ist und `allowedValues` die Sequenz der Werte im `"trigger_data"` Array der Quelle ist. Wenn das Ergebnis dieser Berechnung mit einem Wert im `"trigger_data"` Array der Quelle übereinstimmt, ist die Übereinstimmung erfolgreich. In einem solchen Fall wird der Wert immer übereinstimmen, es sei denn, `allowedValues` ist leer.
- Der `"modulus"` Modus existiert hauptsächlich aus Gründen der Abwärtskompatibilität mit dem Verhalten der API vor der Einführung von `"exact"`, und daher ist es unwahrscheinlich, dass Sie ihn verwenden. Es ist jedoch in bestimmten Fällen nützlich, die eine sehr spezifische Art der Kompression erfordern, die kleinere Registrierungsheader zur Folge hat. Dies kann erforderlich sein, wenn komplexe Filterlogik verwendet wird, die unterschiedliche Triggerdaten basierend auf dem Quelltyp gemäß der maximalen Anzahl von Quell-`"trigger_data"` [!NOTE]
- > Wenn `"modulus"` verwendet wird, muss das `"trigger_data"` der Quelle eine aufeinanderfolgende Folge von Ganzzahlen beginnend bei 0 bilden. Wenn die Triggerdaten keine solche Sequenz bilden, tritt ein Fehler auf.
+ > Wenn `"modulus"` verwendet wird, muss das `"trigger_data"` der Quelle eine zusammenhängende Folge von Ganzzahlen bilden, beginnend bei 0. Wenn die Triggerdaten keine solche Folge bilden, tritt ein Fehler auf.
- Wenn nicht angegeben, ist der Standardwert für `"trigger_data_matching"` `"modulus"`. Auch hier liegt der Grund dafür in der Abwärtskompatibilität: Das Auslassen des `"trigger_data_matching"` Feldes muss zu demselben Verhalten führen, das vor der Einführung dieses Feldes zu beobachten war.
+ Falls nicht angegeben, wird `"trigger_data_matching"` standardmäßig auf `"modulus"` gesetzt. Der Grund dafür ist die Rückwärtskompatibilität: Das Weglassen des `"trigger_data_matching"` Feldes muss zu dem gleichen Verhalten führen, das vor der Einführung dieses Feldes beobachtet wurde.
## Beispiele
-### Registrieren einer Quelle für einen Bericht auf Ereignis-Ebene
+### Registrieren einer Quelle für einen ereignisbasierten Bericht
-Ein Node.js-Server könnte den `Attribution-Reporting-Register-Source` Antwort-Header wie folgt setzen, um einen Browser einen Bericht auf Ereignis-Ebene erstellen zu lassen, wenn ein Trigger einer Quelle zugeordnet wird:
+Ein Node.js-Server könnte den `Attribution-Reporting-Register-Source` Header wie folgt setzen, um einen Browser dazu zu bringen, einen ereignisbasierten Bericht zu generieren, wenn ein Trigger mit einer Quelle abgeglichen wird:
```js
res.set(
@@ -120,9 +120,9 @@ res.set(
);
```
-### Registrieren einer Quelle für einen Zusammenfassungsbericht
+### Registrieren einer Quelle für einen zusammenfassenden Bericht
-Um den Browser einen Zusammenfassungsbericht erstellen zu lassen, wenn ein Trigger einer Quelle zugeordnet wird, müssen einige zusätzliche Felder _zusätzlich_ zu den für die Erstellung des Berichts auf Ereignis-Ebene erforderlichen hinzugefügt werden.
+Um den Browser dazu zu bringen, einen zusammenfassenden Bericht zu generieren, wenn ein Trigger mit einer Quelle abgeglichen wird, müssen Sie einige zusätzliche Felder _zusätzlich_ zu den für die ereignisbasierte Berichterstellung erforderlichen einschließen.
```js
res.set(
@@ -150,7 +150,7 @@ res.set(
{{Specifications}}
-## Kompatibilität der Browser
+## Browser-Kompatibilität
{{Compat}}
diff --git a/files/de/web/http/headers/attribution-reporting-register-trigger/index.md b/files/de/web/http/headers/attribution-reporting-register-trigger/index.md
index 6536bd139..ba240593f 100644
--- a/files/de/web/http/headers/attribution-reporting-register-trigger/index.md
+++ b/files/de/web/http/headers/attribution-reporting-register-trigger/index.md
@@ -7,28 +7,28 @@ l10n:
{{HTTPSidebar}}{{seecompattable}}
-Der **`Attribution-Reporting-Register-Trigger`** Header registriert ein Seitenmerkmal als ein [Attributionstrigger](/de/docs/Web/API/Attribution_Reporting_API/Registering_triggers). Dieser ist Teil einer Antwort auf eine Anfrage, die einen {{httpheader("Attribution-Reporting-Eligible")}} Header enthielt.
+Der **`Attribution-Reporting-Register-Trigger`** Header registriert ein Seitenmerkmal als einen [Zurechnungsauslöser](/de/docs/Web/API/Attribution_Reporting_API/Registering_triggers). Dieser wird als Teil einer Antwort auf eine Anfrage eingeschlossen, die einen {{httpheader("Attribution-Reporting-Eligible")}} Header enthält.
Weitere Details finden Sie in der [Attribution Reporting API](/de/docs/Web/API/Attribution_Reporting_API).
> [!NOTE]
-> Wenn die aufrufende Seite nicht durch einen erfolgreichen [Privacy Sandbox-Anmeldeprozess](/de/docs/Web/Privacy/Privacy_sandbox/Enrollment) in die Attribution Reporting API aufgenommen wurde, wird der `Attribution-Reporting-Register-Trigger` Header ignoriert und Attributionstrigger werden nicht registriert.
+> Wenn die aufrufende Seite die Attribution Reporting API nicht erfolgreich in einem [Privacy Sandbox-Anmeldeprozess](/de/docs/Web/Privacy/Privacy_sandbox/Enrollment) eingeschlossen hat, wird der `Attribution-Reporting-Register-Trigger` Header ignoriert und Zurechnungsauslöser werden nicht registriert.
-
Header-Typ
+
Headertyp
{{Glossary("Response header")}}
{{Glossary("Forbidden header name")}}
-
no
+
nein
{{Glossary("CORS-safelisted response header")}}
-
no
+
nein
@@ -43,45 +43,45 @@ Attribution-Reporting-Register-Trigger:
- ``
- - : Ein JSON-String, der Daten bereitstellt, die in generierte Berichte aufgenommen werden können, wie z.B. die ID des Triggers, sowie Prioritäts- und Deduplizierungswerte. Verfügbare Felder sind wie folgt:
+ - : Ein JSON-String, der Daten bereitstellt, die in generierten Berichten enthalten sein können, wie z. B. die ID des Auslösers sowie Prioritäts- und Duplikationswerte. Verfügbare Felder sind wie folgt:
- `"aggregatable_trigger_data"`
- - : Ein Array von Objekten, wobei jedes einen Aggregationsschlüssel definiert, der auf verschiedene Quellenschlüssel angewendet wird. Jedes Objekt enthält die folgenden Eigenschaften:
+ - : Ein Array von Objekten, wobei jedes einen Aggregationsschlüssel definiert, der auf verschiedene Quellschlüssel anzuwenden ist. Jedes Objekt enthält die folgenden Eigenschaften:
- `"key_piece"`
- : Ein hexadezimaler Wert, der einen Schlüssel darstellt.
- `"source_keys"`
- : Ein Array, das einen oder mehrere Schlüsselwerte für die Daten enthält.
- `"aggregatable_values"`
- - : Ein Objekt, das Eigenschaften enthält, die einen Wert für jeden in `"aggregatable_trigger_data"` definierten Datenpunkt darstellen. In jedem Fall ist der Bezeichner der Eigenschaft gleich dem in `"source_keys"` definierten Namen, und der Wert der Eigenschaft ist ein beliebiger Wert, den Sie benötigen.
+ - : Ein Objekt mit Eigenschaften, die einen Wert für jeden in `"aggregatable_trigger_data"` definierten Datenpunkt darstellen. In jedem Fall entspricht der Name der Eigenschaft dem in `"source_keys"` definierten Namen, und der Eigenschaftswert ist ein beliebiger Wert, den Sie wünschen.
- `"debug_key"` {{optional_inline}}
- - : Eine Zahl, die einen Debug-Schlüssel darstellt. Setzen Sie dies, wenn Sie einen [Debug-Bericht](/de/docs/Web/API/Attribution_Reporting_API/Generating_reports#debug_reports) zusammen mit dem zugehörigen Attributionsbericht generieren möchten.
+ - : Eine Zahl, die einen Debug-Schlüssel darstellt. Setzen Sie dies, wenn Sie neben dem zugehörigen Zurechnungsbericht einen [Debug-Bericht](/de/docs/Web/API/Attribution_Reporting_API/Generating_reports#debug_reports) generieren möchten.
- `"debug_reporting"` {{optional_inline}}
- - : Ein boolescher Wert. Wenn ein `debug_key` festgelegt ist, setzen Sie dies auf `true`, um anzugeben, dass der generierte Debug-Bericht ein ausführlicher Debug-Bericht sein soll.
+ - : Ein boolescher Wert. Wenn ein `debug_key` gesetzt ist, setzen Sie dies auf `true`, um anzugeben, dass der generierte Debug-Bericht ein ausführlicher Bericht sein soll.
- `"filters"` {{optional_inline}}
- - : Ein Objekt, das benutzerdefinierte Daten enthält, die verwendet werden können, um festzulegen, welche Trigger Berichte generieren. Weitere Details finden Sie unter [Filters](/de/docs/Web/API/Attribution_Reporting_API/Generating_reports#filters).
+ - : Ein Objekt, das benutzerdefinierte Daten enthält, die verwendet werden können, um zu filtern, welche Auslöser Berichte erzeugen. Weitere Details finden Sie unter [Filters](/de/docs/Web/API/Attribution_Reporting_API/Generating_reports#filters).
- `"event_trigger_data"`
- - : Ein Objekt, das Daten über den Trigger darstellt. Verfügbare Unterfelder sind wie folgt:
+ - : Ein Objekt, das Daten über den Auslöser darstellt. Verfügbare Unterfelder sind wie folgt:
- `"trigger_data"`
- - : Ein String, der Daten darstellt, die den Trigger beschreiben, welcher typischerweise verwendet wird, um Ereignisse wie "Benutzer hat ein Element zum Warenkorb hinzugefügt" oder "Benutzer hat sich für den Newsletter angemeldet" anzuzeigen. Dieser Wert wird im generierten Ereignisbericht enthalten sein, sofern vorhanden, obwohl er basierend auf dem [`"trigger_data_matching"`](/de/docs/Web/HTTP/Headers/Attribution-Reporting-Register-Source#trigger_data_matching) Feld der zugeordneten Quelle modifiziert werden kann.
+ - : Ein String, der Daten beschreibt, die den Auslöser kennzeichnen, der typischerweise verwendet wird, um Ereignisse wie "Benutzer fügt Artikel in den Warenkorb hinzu" oder "Benutzer meldet sich für Mailingliste an" anzugeben. Dieser Wert wird im generierten Ereignis-Bericht enthalten sein, falls vorhanden, obwohl er basierend auf dem entsprechenden Quelldatensatz der [`"trigger_data_matching"`](/de/docs/Web/HTTP/Headers/Attribution-Reporting-Register-Source#trigger_data_matching) Feld modifiziert wird.
> [!NOTE]
- > Die Werte, die jedes Ereignis repräsentieren, und die Anzahl der Elemente im Array sind völlig willkürlich und von Ihnen als Entwickler definiert. Das Array kann Werte enthalten, die nicht verwendet werden, aber Werte müssen im Array vorhanden sein, damit sie vom Browser der Quelle zugeordnet werden, wenn ein Trigger registriert wird.
+ > Die Werte, die jedes Ereignis darstellen, sowie die Anzahl der Elemente im Array sind völlig willkürlich und werden von Ihnen als Entwickler definiert. Das Array kann Werte enthalten, die nicht verwendet werden, aber Werte müssen im Array vorhanden sein, um vom Browser einem Auslöser zugeordnet zu werden, wenn dieser registriert wird.
- `"priority"` {{optional_inline}}
- - : Ein String, der einen Prioritätswert für den Attributionstrigger darstellt. Standardmäßig werden Trigger der zuletzt übereinstimmenden Quelle zugeordnet. Für sowohl Ereignis- als auch Zusammenfassungsberichte setzen Sie eine höhere Prioritätsnummer, um den Trigger mit älteren Quellen zu verknüpfen. Beispielsweise hat ein Wert von `2` Vorrang vor dem Standardwert von `1`. Weitere Informationen finden Sie unter [Berichtsprioritäten und -beschränkungen](/de/docs/Web/API/Attribution_Reporting_API/Generating_reports#report_priorities_and_limits).
+ - : Ein String, der einen Prioritätswert für den Zurechnungsauslöser darstellt. Standardmäßig werden Auslöser der zuletzt passenden Quelle zugeordnet. Für sowohl ereignisbezogene als auch zusammenfassende Berichte setzen Sie eine höhere Prioritätsnummer, um den Auslöser älteren Quellen zuzuordnen. Beispielsweise hat ein Wert von `2` Vorrang vor dem Standardwert von `1`. Weitere Informationen finden Sie unter [Berichtprioritäten und -beschränkungen](/de/docs/Web/API/Attribution_Reporting_API/Generating_reports#report_priorities_and_limits).
- `"deduplication_key"` {{optional_inline}}
- - : Ein String, der einen eindeutigen Schlüssel darstellt, um zu verhindern, dass Attributionsvorgänge dupliziert werden — zum Beispiel, wenn ein Benutzer dasselbe Element mehrfach zum Warenkorb hinzufügt. Weitere Informationen finden Sie unter [Vermeidung von Duplikation in Berichten](https://developers.google.com/privacy-sandbox/private-advertising/attribution-reporting/prevent-duplication).
+ - : Ein String, der einen eindeutigen Schlüssel darstellt, der verwendet werden kann, um zu verhindern, dass Zuordnungen dupliziert werden — z. B. wenn ein Benutzer denselben Artikel mehrmals in einen Warenkorb legt. Weitere Informationen finden Sie unter [Verhinderung von Duplikationen in Berichten](https://developers.google.com/privacy-sandbox/private-advertising/attribution-reporting/prevent-duplication).
- `"filters"` {{optional_inline}}
- - : Ein Objekt, das Filter enthält, die selektive Filterung durchführen, um `"trigger_data"`, `"priority"` und `"deduplication_key"` basierend auf den im entsprechenden {{httpheader("Attribution-Reporting-Register-Source")}} Header gesetzten `filter_data` festzulegen. Weitere Informationen finden Sie unter [Filters](/de/docs/Web/API/Attribution_Reporting_API/Generating_reports#filters).
+ - : Ein Objekt, das Filter enthält, die selektive Filterung durchführen, um `"trigger_data"`, `"priority"` und `"deduplication_key"` basierend auf dem in einem entsprechenden {{httpheader("Attribution-Reporting-Register-Source")}} Header gesetzten `filter_data` festzulegen. Weitere Informationen finden Sie unter [Filters](/de/docs/Web/API/Attribution_Reporting_API/Generating_reports#filters).
## Beispiele
-### Registrierung eines Triggers für einen ereignisgesteuerten Bericht
+### Registrierung eines Auslösers für einen ereignisbezogenen Bericht
-Ein Node.js-Server könnte den `Attribution-Reporting-Register-Trigger` Response-Header wie folgt setzen, um einen Trigger zu registrieren, der einer ereignisgesteuerten Berichts-Attributionsquelle entsprechen soll:
+Ein Node.js-Server könnte den `Attribution-Reporting-Register-Trigger` Antwortheader wie folgt setzen, um einen Auslöser zu registrieren, der zur Attribution einer Quelle für ereignisbezogene Berichte passt:
```js
res.set(
@@ -99,9 +99,9 @@ res.set(
);
```
-### Registrierung eines Triggers für einen Zusammenfassungsbericht
+### Registrierung eines Auslösers für einen zusammenfassenden Bericht
-Beim Registrieren eines Triggers, der einer Zusammenfassungsberichts-Attributionsquelle entsprechen soll, müssen Sie die folgenden Felder einschließen:
+Wenn Sie einen Auslöser registrieren, der mit einer Quelle für einen zusammenfassenden Bericht übereinstimmen soll, müssen Sie die folgenden Felder einschließen:
```js
res.set(
diff --git a/files/de/web/http/headers/authorization/index.md b/files/de/web/http/headers/authorization/index.md
index e47e8d8a5..5cfd3c2b3 100644
--- a/files/de/web/http/headers/authorization/index.md
+++ b/files/de/web/http/headers/authorization/index.md
@@ -7,14 +7,14 @@ l10n:
{{HTTPSidebar}}
-Der HTTP-Anforderungsheader **`Authorization`** kann verwendet werden, um Anmeldedaten bereitzustellen, die einen Benutzeragenten bei einem Server authentifizieren, wodurch der Zugriff auf eine geschützte Ressource ermöglicht wird.
+Der HTTP-Header **`Authorization`** kann verwendet werden, um Anmeldedaten bereitzustellen, die einen User-Agent gegenüber einem Server authentifizieren und den Zugriff auf eine geschützte Ressource ermöglichen.
-Der **`Authorization`**-Header wird in der Regel, aber nicht immer, gesendet, nachdem der Benutzeragent zunächst versucht hat, eine geschützte Ressource ohne Anmeldedaten anzufordern. Der Server antwortet mit einer {{HTTPStatus("401")}} „Unauthorized“-Nachricht, die mindestens einen {{HTTPHeader("WWW-Authenticate")}}-Header enthält. Dieser Header gibt an, welche Authentifizierungsschemata zum Zugriff auf die Ressource verwendet werden können (und alle zusätzlichen Informationen, die der Client benötigt, um sie zu verwenden). Der Benutzeragent sollte das sicherste Authentifizierungsschema auswählen, das er von den angebotenen unterstützt, den Benutzer nach seinen Anmeldedaten fragen und dann die Ressource erneut anfordern (einschließlich der kodierten Anmeldedaten im **`Authorization`**-Header).
+Der **`Authorization`**-Header wird normalerweise, aber nicht immer, gesendet, nachdem der User-Agent zuerst versucht hat, eine geschützte Ressource ohne Anmeldedaten anzufordern. Der Server antwortet mit einer {{HTTPStatus("401")}} `Unauthorized`-Meldung, die mindestens einen {{HTTPHeader("WWW-Authenticate")}}-Header enthält. Dieser Header gibt an, welche Authentifizierungsschemata zum Zugriff auf die Ressource verwendet werden können (und alle zusätzlichen Informationen, die der Client zur Verwendung benötigt). Der User-Agent sollte das sicherste Authentifizierungsschema auswählen, das er unterstützt, den Benutzer nach seinen Anmeldedaten fragen und dann die Ressource erneut anfordern (einschließlich der kodierten Anmeldedaten im **`Authorization`**-Header).
-Dieser Header wird bei Cross-Origin-Weiterleitungen entfernt.
+Dieser Header wird bei Weiterleitungen über Ursprünge hinweg entfernt.
> [!NOTE]
-> Dieser Header ist Teil des [Allgemeinen HTTP-Authentifizierungsrahmens](/de/docs/Web/HTTP/Authentication#the_general_http_authentication_framework).
+> Dieser Header ist Teil des [allgemeinen HTTP-Authentifizierungs-Frameworks](/de/docs/Web/HTTP/Authentication#the_general_http_authentication_framework).
> Er kann mit einer Reihe von [Authentifizierungsschemata](/de/docs/Web/HTTP/Authentication#authentication_schemes) verwendet werden.
@@ -25,7 +25,7 @@ Dieser Header wird bei Cross-Origin-Weiterleitungen entfernt.
{{Glossary("Forbidden header name")}}
-
Nein
+
nein
@@ -36,7 +36,7 @@ Dieser Header wird bei Cross-Origin-Weiterleitungen entfernt.
Authorization:
```
-Basic-Authentifizierung
+Basis-Authentifizierung
```http
Authorization: Basic
@@ -61,13 +61,13 @@ Authorization: Digest username=,
- ``
- - : Das [Authentifizierungsschema](/de/docs/Web/HTTP/Authentication#authentication_schemes), das definiert, wie die Anmeldedaten kodiert werden.
- Einige der häufigeren Typen sind (groß- und kleinschreibungsempfindlich): [`Basic`](/de/docs/Web/HTTP/Authentication#basic_authentication_scheme), `Digest`, `Negotiate` und `AWS4-HMAC-SHA256`.
+ - : Das [Authentifizierungsschema](/de/docs/Web/HTTP/Authentication#authentication_schemes), das definiert, wie die Anmeldedaten kodiert sind.
+ Einige der häufigeren Typen sind (nicht Groß-/Kleinschreibungs-empfindlich): [`Basic`](/de/docs/Web/HTTP/Authentication#basic_authentication_scheme), `Digest`, `Negotiate` und `AWS4-HMAC-SHA256`.
> [!NOTE]
- > Für weitere Informationen/Optionen siehe [HTTP Authentication > Authentication schemes](/de/docs/Web/HTTP/Authentication#authentication_schemes)
+ > Für weitere Informationen/Optionen siehe [HTTP-Authentifizierung > Authentifizierungsschemata](/de/docs/Web/HTTP/Authentication#authentication_schemes)
-Abgesehen von `` sind die verbleibenden Direktiven spezifisch für jedes [Authentifizierungsschema](/de/docs/Web/HTTP/Authentication#authentication_schemes). Im Allgemeinen müssen Sie die relevanten Spezifikationen für diese überprüfen (Schlüssel für eine kleine Untergruppe von Schemata sind unten aufgelistet).
+Abgesehen von `` sind die restlichen Direktiven spezifisch für jedes [Authentifizierungsschema](/de/docs/Web/HTTP/Authentication#authentication_schemes). Im Allgemeinen müssen Sie die entsprechenden Spezifikationen dafür überprüfen (Schlüssel für einen kleinen Teil von Schemata sind unten aufgeführt).
### Basic
@@ -76,57 +76,57 @@ Abgesehen von `` sind die verbleibenden Direktiven spezifisch für
- : Die Anmeldedaten, kodiert gemäß dem angegebenen Schema.
> [!NOTE]
- > Informationen über den Kodierungsalgorithmus finden Sie unten in den Beispielen, in {{HTTPHeader("WWW-Authenticate")}}, in [HTTP Authentication](/de/docs/Web/HTTP/Authentication) und in den relevanten Spezifikationen.
+ > Informationen zum Kodierungsalgorithmus finden Sie in den Beispielen: unten, in {{HTTPHeader("WWW-Authenticate")}}, in [HTTP-Authentifizierung](/de/docs/Web/HTTP/Authentication) und in den entsprechenden Spezifikationen.
### Digest
- \
- - : Ein Zeichenfolge der Hex-Ziffern, die beweist, dass der Benutzer ein Passwort kennt.
- Der Algorithmus kodiert den Benutzernamen und das Passwort, den Bereich, cnonce, qop, nc usw.
- Es wird im Detail in der Spezifikation beschrieben.
+ - : Eine Zeichenkette der Hexadezimalziffern, die beweist, dass der Benutzer ein Passwort kennt.
+ Der Algorithmus kodiert den Benutzernamen und das Passwort, Realm, cnonce, qop, nc usw.
+ Es ist detailliert in der Spezifikation beschrieben.
- `username`
- - : Eine in Anführungszeichen gesetzte Zeichenkette, die den Benutzernamen für den angegebenen `realm` im Klartext oder den Hash-Code in hexadezimaler Notation enthält.
- Wenn der Name Zeichen enthält, die im Feld nicht erlaubt sind, kann stattdessen `username*` verwendet werden (nicht „sowie“).
+ - : Eine zitierte Zeichenkette, die den Benutzernamen für das angegebene `realm` im Klartext oder als Hashcode in hexadezimaler Notation enthält.
+ Wenn der Name Zeichen enthält, die im Feld nicht erlaubt sind, kann stattdessen `username*` verwendet werden (nicht "sowie").
- `username*`
- - : Der Benutzername formatiert mit einer erweiterten Notation, die in RFC5987 definiert ist.
+ - : Der Benutzername, formatiert mit einer in RFC5987 definierten erweiterten Notation.
Dies sollte nur verwendet werden, wenn der Name nicht in `username` kodiert werden kann und wenn `userhash` auf `"false"` gesetzt ist.
- `uri`
- - : Die _Effektive Anforderungs-URI_. Weitere Informationen finden Sie in der Spezifikation.
+ - : Die _Effektive Anforderungs-URI_. Siehe die Spezifikation für weitere Informationen.
- `realm`
- - : Bereich des angeforderten Benutzernamens/Passworts (sollte wieder mit dem Wert in der entsprechenden {{HTTPHeader("WWW-Authenticate")}}-Antwort für die angeforderte Ressource übereinstimmen).
+ - : Realm des angeforderten Benutzername/Passwort (sollte ebenfalls mit dem Wert in der entsprechenden {{HTTPHeader("WWW-Authenticate")}}-Antwort für die angeforderte Ressource übereinstimmen).
- `opaque`
- : Der Wert in der entsprechenden {{HTTPHeader("WWW-Authenticate")}}-Antwort für die angeforderte Ressource.
- `algorithm`
- - : Der Algorithmus, der zur Berechnung der Digest verwendet wird. Muss ein unterstützter Algorithmus aus der {{HTTPHeader("WWW-Authenticate")}}-Antwort für die angeforderte Ressource sein.
+ - : Der Algorithmus, der zur Berechnung des Digests verwendet wird. Muss ein unterstützter Algorithmus aus der {{HTTPHeader("WWW-Authenticate")}}-Antwort für die angeforderte Ressource sein.
- `qop`
- - : Ein Token, das die _Qualität des Schutzes_ angibt, die auf die Nachricht angewendet wird.
- Muss mit dem Wert im Set übereinstimmen, das in der {{HTTPHeader("WWW-Authenticate")}}-Antwort für die angeforderte Ressource angegeben ist.
+ - : Ein Token, das die _Schutzqualität_ angibt, die auf die Nachricht angewendet wird.
+ Muss mit dem einen Wert im Satz übereinstimmen, der in der {{HTTPHeader("WWW-Authenticate")}}-Antwort für die angeforderte Ressource angegeben ist.
- `"auth"`: Authentifizierung
- `"auth-int"`: Authentifizierung mit Integritätsschutz
- `cnonce`
- - : Ein zitierter {{Glossary("ASCII")}}-nur Zeichenkette-Wert, der vom Client bereitgestellt wird.
- Dies wird sowohl vom Client als auch vom Server verwendet, um gegenseitige Authentifizierung bereitzustellen, einen gewissen Nachrichtenschutz zu gewährleisten und „gewählte Klartextangriffe“ zu vermeiden.
+ - : Eine zitierte {{Glossary("ASCII")}}-Zeichenfolge, die vom Client bereitgestellt wird.
+ Diese wird sowohl vom Client als auch vom Server verwendet, um gegenseitige Authentifizierung bereitzustellen, Schutz der Nachrichtenintegrität zu bieten und "gewählte Klartextangriffe" zu vermeiden.
Weitere Informationen finden Sie in der Spezifikation.
- `nc`
- - : Nonce-Zählung. Die hexadezimale Zählung der Anfragen, in denen der Client den aktuellen `cnonce`-Wert gesendet hat (einschließlich der aktuellen Anfrage).
- Der Server kann doppelte `nc`-Werte verwenden, um wiederholte Anfragen zu erkennen.
+ - : Nonce-Zähler. Der hexadezimale Zähler von Anfragen, bei denen der Client den aktuellen `cnonce`-Wert gesendet hat (einschließlich der aktuellen Anfrage).
+ Der Server kann doppelte `nc`-Werte verwenden, um Wiederholungsanfragen zu erkennen.
- `userhash` {{optional_inline}}
- : `"true"`, wenn der Benutzername gehasht wurde. Standardmäßig `"false"`.
## Beispiele
-### Basic-Authentifizierung
+### Basis-Authentifizierung
-Für die „Basic“-Authentifizierung werden die Anmeldedaten konstruiert, indem zuerst der Benutzername und das Passwort mit einem Doppelpunkt (`aladdin:opensesame`) kombiniert und dann die resultierende Zeichenfolge in [`base64`](/de/docs/Glossary/Base64) (`YWxhZGRpbjpvcGVuc2VzYW1l`) kodiert wird.
+Für die `"Basic"`-Authentifizierung werden die Anmeldedaten konstruiert, indem zuerst der Benutzername und das Passwort mit einem Doppelpunkt kombiniert werden (`aladdin:opensesame`), und dann durch Kodierung der resultierenden Zeichenkette in [`base64`](/de/docs/Glossary/Base64) (`YWxhZGRpbjpvcGVuc2VzYW1l`).
```http
Authorization: Basic YWxhZGRpbjpvcGVuc2VzYW1l
```
-> **Warning:** {{Glossary("Base64")}}-Kodierung kann leicht rückgängig gemacht werden, um den ursprünglichen Namen und das Passwort zu erhalten. Daher ist die Basic-Authentifizierung völlig unsicher.
-> {{Glossary("HTTPS")}} wird immer empfohlen, wenn Authentifizierung verwendet wird, aber noch mehr, wenn `Basic`-Authentifizierung verwendet wird.
+> **Warnung:** {{Glossary("Base64")}}-Kodierung kann leicht rückgängig gemacht werden, um den ursprünglichen Namen und das Passwort zu erhalten, sodass die Basis-Authentifizierung völlig unsicher ist.
+> {{Glossary("HTTPS")}} wird immer empfohlen, wenn Authentifizierung verwendet wird, aber noch mehr, wenn die `Basic`-Authentifizierung verwendet wird.
-Siehe auch [HTTP-Authentifizierung](/de/docs/Web/HTTP/Authentication) für Beispiele, wie Apache- oder Nginx-Server konfiguriert werden, um Ihre Website mit HTTP-Basisauthentifizierung passwortzuschützen.
+Siehe auch [HTTP-Authentifizierung](/de/docs/Web/HTTP/Authentication) für Beispiele, wie Apache- oder Nginx-Server konfiguriert werden, um Ihre Website mit HTTP-Basis-Authentifizierung kennwortzuschützen.
## Spezifikationen
diff --git a/files/de/web/http/headers/cache-control/index.md b/files/de/web/http/headers/cache-control/index.md
index a37fce151..0ac5f5f6e 100644
--- a/files/de/web/http/headers/cache-control/index.md
+++ b/files/de/web/http/headers/cache-control/index.md
@@ -1,5 +1,5 @@
---
-title: Cache-Steuerung
+title: Cache-Control
slug: Web/HTTP/Headers/Cache-Control
l10n:
sourceCommit: caffa587676396f62fed17ba53b16e55b0e8caf3
@@ -7,12 +7,12 @@ l10n:
{{HTTPSidebar}}
-Das **`Cache-Control`** HTTP-Header-Feld enthält _Direktiven_ (Anweisungen) — sowohl in Anfragen als auch in Antworten — die das [Caching](/de/docs/Web/HTTP/Caching) in Browsern und gemeinsamen Caches (z.B. Proxies, CDNs) steuern.
+Das **`Cache-Control`** HTTP-Headerfeld enthält _Direktiven_ (Anweisungen) — sowohl bei Anfragen als auch bei Antworten — die das [Caching](/de/docs/Web/HTTP/Caching) in Browsern und gemeinsamen Caches (z. B. Proxys, CDNs) steuern.
-
Header-Typ
+
Header type
{{Glossary("Request header")}},
{{Glossary("Response header")}}
@@ -35,78 +35,78 @@ Das **`Cache-Control`** HTTP-Header-Feld enthält _Direktiven_ (Anweisungen) —
Cache-Direktiven folgen diesen Regeln:
-- Cache-Direktiven sind nicht case-sensitive. Es wird jedoch empfohlen, Kleinbuchstaben zu verwenden, da einige Implementierungen Großbuchstaben-Direktiven nicht erkennen.
-- Mehrere Direktiven sind erlaubt und müssen durch Kommas getrennt werden (z.B. `Cache-control: max-age=180, public`).
-- Einige Direktiven haben ein optionales Argument. Wenn ein Argument angegeben wird, wird es durch ein Gleichheitszeichen (`=`) vom Direktivnamen getrennt. Typischerweise sind Argumente für die Direktiven Ganzzahlen und daher nicht in Anführungszeichen gesetzt (z.B. `Cache-control: max-age=12`).
+- Cache-Direktiven sind nicht case-sensitive. Es wird jedoch empfohlen, sie in Kleinbuchstaben zu schreiben, da einige Implementierungen Großbuchstaben nicht erkennen.
+- Mehrere Direktiven sind zulässig und müssen durch Kommas getrennt sein (z. B. `Cache-control: max-age=180, public`).
+- Einige Direktiven haben ein optionales Argument. Wenn ein Argument angegeben ist, wird es durch ein Gleichheitszeichen (`=`) vom Namen der Direktive getrennt. Typischerweise sind Argumente für die Direktiven Ganzzahlen und daher nicht in Anführungszeichen eingeschlossen (z. B. `Cache-control: max-age=12`).
### Cache-Direktiven
Die folgende Tabelle listet die standardmäßigen `Cache-Control`-Direktiven auf:
-| Anfrage | Antwort |
-| ------------------ | ------------------------ |
-| `max-age` | `max-age` |
-| `max-stale` | - |
-| `min-fresh` | - |
-| - | `s-maxage` |
-| `no-cache` | `no-cache` |
-| `no-store` | `no-store` |
-| `no-transform` | `no-transform` |
-| `only-if-cached` | - |
-| - | `must-revalidate` |
-| - | `proxy-revalidate` |
-| - | `must-understand` |
-| - | `private` |
-| - | `public` |
-| - | `immutable` |
-| - | `stale-while-revalidate` |
-| `stale-if-error` | `stale-if-error` |
-
-Hinweis: Überprüfen Sie die [Kompatibilitätstabelle](#browser-kompatibilität) für ihre Unterstützung; User Agents, die sie nicht erkennen, sollten sie ignorieren.
+| Anfrage | Antwort |
+| ---------------- | ------------------------ |
+| `max-age` | `max-age` |
+| `max-stale` | - |
+| `min-fresh` | - |
+| - | `s-maxage` |
+| `no-cache` | `no-cache` |
+| `no-store` | `no-store` |
+| `no-transform` | `no-transform` |
+| `only-if-cached` | - |
+| - | `must-revalidate` |
+| - | `proxy-revalidate` |
+| - | `must-understand` |
+| - | `private` |
+| - | `public` |
+| - | `immutable` |
+| - | `stale-while-revalidate` |
+| `stale-if-error` | `stale-if-error` |
+
+Hinweis: Überprüfen Sie die [Kompatibilitätstabelle](#/index.html), um deren Unterstützung zu verifizieren; User Agents, die sie nicht erkennen, sollten sie ignorieren.
## Vokabular
-Dieser Abschnitt definiert die in diesem Dokument verwendeten Begriffe, einige davon stammen aus der Spezifikation.
+Dieser Abschnitt definiert die in diesem Dokument verwendeten Begriffe, von denen einige aus der Spezifikation stammen.
- (HTTP) Cache
- - : Implementierung, die Anfragen und Antworten für die Wiederverwendung in nachfolgenden Anfragen speichert. Es kann entweder ein gemeinsamer Cache oder ein privater Cache sein.
+ - : Implementierung, die Anfragen und Antworten für die Wiederverwendung bei nachfolgenden Anfragen speichert. Sie kann entweder ein gemeinsamer Cache oder ein privater Cache sein.
- Gemeinsamer Cache
- - : Cache, der zwischen dem Ursprungsserver und Clients besteht (z.B. Proxy, CDN). Er speichert eine einzelne Antwort und verwendet sie mit mehreren Benutzern wieder — daher sollten Entwickler vermeiden, personalisierte Inhalte im gemeinsamen Cache zu speichern.
+ - : Cache, der zwischen dem Ursprungsserver und den Clients existiert (z. B. Proxy, CDN). Er speichert eine einzige Antwort und verwendet sie erneut bei mehreren Benutzern — Entwickler sollten vermeiden, personalisierte Inhalte im gemeinsamen Cache zu speichern.
- Privater Cache
- - : Cache, der sich im Client befindet. Er wird auch als _lokaler Cache_ oder _Browser-Cache_ bezeichnet. Er kann personalisierte Inhalte für einen einzelnen Benutzer speichern und wiederverwenden.
+ - : Cache, der im Client existiert. Er wird auch als _lokaler Cache_ oder _Browser-Cache_ bezeichnet. Er kann personalisierte Inhalte für einen einzelnen Benutzer speichern und wiederverwenden.
- Antwort speichern
- - : Eine Antwort in Caches speichern, wenn die Antwort cachefähig ist. Allerdings wird die gespeicherte Antwort nicht immer so wiederverwendet, wie sie ist. (Normalerweise bedeutet "cache", eine Antwort zu speichern.)
+ - : Eine Antwort in Caches speichern, wenn die Antwort cachefähig ist. Allerdings wird die zwischengespeicherte Antwort nicht immer unverändert wiederverwendet. (Normalerweise bedeutet „Cache“ die Speicherung einer Antwort.)
- Antwort wiederverwenden
- - : Gespeicherte Antworten für nachfolgende Anfragen wiederverwenden.
-- Antwort erneut validieren
- - : Den Ursprungsserver fragen, ob die gespeicherte Antwort noch [frisch](/de/docs/Web/HTTP/Caching#fresh_and_stale_based_on_age) ist. In der Regel erfolgt die Revalidierung durch eine bedingte Anfrage.
+ - : Zwischengespeicherte Antworten für nachfolgende Anfragen wiederverwenden.
+- Antwort neu validieren
+ - : Den Ursprungsserver fragen, ob die gespeicherte Antwort noch [frisch](/de/docs/Web/HTTP/Caching#fresh_and_stale_based_on_age) ist. In der Regel erfolgt die Neubeurteilung durch eine bedingte Anfrage.
- Frische Antwort
- - : Gibt an, dass die Antwort [frisch](/de/docs/Web/HTTP/Caching#fresh_and_stale_based_on_age) ist. Dies bedeutet normalerweise, dass die Antwort für nachfolgende Anfragen wiederverwendet werden kann, abhängig von Anfrage-Direktiven.
+ - : Deutet darauf hin, dass die Antwort [frisch](/de/docs/Web/HTTP/Caching#fresh_and_stale_based_on_age) ist. In der Regel bedeutet dies, dass die Antwort für nachfolgende Anfragen wiederverwendet werden kann, abhängig von Anfrage-Direktiven.
- Veraltete Antwort
- - : Gibt an, dass die Antwort eine [veraltete Antwort](/de/docs/Web/HTTP/Caching#fresh_and_stale_based_on_age) ist. Das bedeutet normalerweise, dass die Antwort nicht unverändert wiederverwendet werden kann. Cache-Speicher ist nicht verpflichtet, veraltete Antworten sofort zu entfernen, da eine Revalidierung die Antwort von veraltet zu [frisch](/de/docs/Web/HTTP/Caching#fresh_and_stale_based_on_age) ändern könnte.
+ - : Deutet darauf hin, dass die Antwort eine [veraltete Antwort](/de/docs/Web/HTTP/Caching#fresh_and_stale_based_on_age) ist. In der Regel bedeutet dies, dass die Antwort nicht unverändert wiederverwendet werden kann. Der Cache-Speicher ist nicht verpflichtet, veraltete Antworten sofort zu entfernen, da eine Neubeurteilung die Antwort von veraltet zu [frisch](/de/docs/Web/HTTP/Caching#fresh_and_stale_based_on_age) ändern könnte.
- Alter
- - : Die Zeit, die seit der Generierung einer Antwort vergangen ist. Es ist ein Kriterium dafür, ob eine Antwort [frisch oder veraltet](/de/docs/Web/HTTP/Caching#fresh_and_stale_based_on_age) ist.
+ - : Die Zeit seit der Erstellung einer Antwort. Sie ist ein Kriterium dafür, ob eine Antwort [frisch oder veraltet](/de/docs/Web/HTTP/Caching#fresh_and_stale_based_on_age) ist.
## Direktiven
-In diesem Abschnitt werden Direktiven aufgelistet, die das Caching beeinflussen — sowohl Antwort-Direktiven als auch Anfrage-Direktiven.
+Dieser Abschnitt listet Direktiven auf, die das Caching beeinflussen — sowohl Antwort-Direktiven als auch Anfrage-Direktiven.
### Antwort-Direktiven
#### `max-age`
-Die `max-age=N` Antwort-Direktive gibt an, dass die Antwort [frisch](/de/docs/Web/HTTP/Caching#fresh_and_stale_based_on_age) bleibt, bis _N_ Sekunden nach der Generierung der Antwort vergangen sind.
+Die `max-age=N` Antwort-Direktive weist darauf hin, dass die Antwort bis _N_ Sekunden nach ihrer Erstellung [frisch](/de/docs/Web/HTTP/Caching#fresh_and_stale_based_on_age) bleibt.
```http
Cache-Control: max-age=604800
```
-Gibt an, dass Caches diese Antwort speichern und für nachfolgende Anfragen verwenden können, solange sie [frisch](/de/docs/Web/HTTP/Caching#fresh_and_stale_based_on_age) ist.
+Dies deutet darauf hin, dass Caches diese Antwort speichern und sie für nachfolgende Anfragen wiederverwenden können, solange sie [frisch](/de/docs/Web/HTTP/Caching#fresh_and_stale_based_on_age) ist.
-Beachten Sie, dass `max-age` nicht die verstrichene Zeit seit dem Empfang der Antwort ist; es ist die verstrichene Zeit seit der Generierung der Antwort auf dem Ursprungsserver.
-Wenn der andere Cache(s) — auf der vom Antwort genutzten Netzwerkroute — die Antwort für 100 Sekunden speichert (angezeigt durch das `Age` Antwort-Header-Feld), würde der Browser-Cache 100 Sekunden von seiner [Frischelebensdauer](/de/docs/Web/HTTP/Caching#fresh_and_stale_based_on_age) abziehen.
+Beachten Sie, dass `max-age` nicht die verstrichene Zeit seit dem Empfang der Antwort bedeutet; es ist die verstrichene Zeit seit der Erstellung der Antwort auf dem Ursprungsserver.
+Wenn der andere Cache(s) — auf dem Netzwerkpfad, den die Antwort genommen hat — die Antwort für 100 Sekunden speichert (angezeigt durch das `Age` Antwort-Headerfeld), würde der Browser-Cache 100 Sekunden von seiner [Frischelebensdauer](/de/docs/Web/HTTP/Caching#fresh_and_stale_based_on_age) abziehen.
-Wenn der `max-age`-Wert negativ ist (zum Beispiel `-1`) oder keine ganze Zahl ist (zum Beispiel `3599.99`), dann ist das Caching-Verhalten nicht spezifiziert. Caches werden ermutigt, den Wert so zu behandeln, als wäre er `0` (dies wird im Abschnitt [Berechnung der Frischelebensdauer](https://httpwg.org/specs/rfc9111.html#calculating.freshness.lifetime) der HTTP-Spezifikation notiert).
+Wenn der `max-age` Wert negativ ist (zum Beispiel `-1`) oder kein Ganzzahlwert (zum Beispiel `3599.99`) ist, ist das Caching-Verhalten nicht spezifiziert. Caches wird empfohlen, den Wert so zu behandeln, als wäre er `0` (dies wird im Abschnitt [Berechnung der Frischelebensdauer](https://httpwg.org/specs/rfc9111.html#calculating.freshness.lifetime) der HTTP-Spezifikation erwähnt).
```http
Cache-Control: max-age=604800
@@ -116,7 +116,7 @@ Age: 100
#### `s-maxage`
Die `s-maxage` Antwort-Direktive gibt an, wie lange die Antwort in einem gemeinsamen Cache [frisch](/de/docs/Web/HTTP/Caching#fresh_and_stale_based_on_age) bleibt.
-Die `s-maxage` Direktive wird von privaten Caches ignoriert und überschreibt den von der `max-age` Direktive oder dem `Expires` Header für gemeinsame Caches angegebenen Wert, falls diese vorhanden sind.
+Die `s-maxage` Direktive wird von privaten Caches ignoriert und überschreibt den durch die `max-age` Direktive oder den `Expires` Header für gemeinsame Caches angegebenen Wert, falls diese vorhanden sind.
```http
Cache-Control: s-maxage=604800
@@ -124,35 +124,35 @@ Cache-Control: s-maxage=604800
#### `no-cache`
-Die `no-cache` Antwort-Direktive gibt an, dass die Antwort in Caches gespeichert werden kann, aber die Antwort vor jeder Wiederverwendung beim Ursprungsserver validiert werden muss, selbst wenn der Cache vom Ursprungsserver getrennt ist.
+Die `no-cache` Antwort-Direktive gibt an, dass die Antwort in Caches gespeichert werden kann, aber die Antwort muss vor jeder Wiederverwendung mit dem Ursprungsserver validiert werden, auch wenn der Cache vom Ursprungsserver getrennt ist.
```http
Cache-Control: no-cache
```
-Wenn Sie möchten, dass Caches gespeicherte Inhalte bei der Nutzung immer auf Aktualisierungen überprüfen, verwenden Sie `no-cache`. Dies wird erreicht, indem Caches angewiesen werden, jede Anfrage mit dem Ursprungsserver zu revalidieren.
+Wenn Sie möchten, dass Caches beim Wiederverwenden gespeicherter Inhalte immer nach Inhaltsaktualisierungen suchen, ist `no-cache` die zu verwendende Direktive. Sie bewirkt dies, indem sie Caches zwingt, jede Anfrage mit dem Ursprungsserver zu validieren.
-Beachten Sie, dass `no-cache` nicht "nicht cachen" bedeutet. `no-cache` erlaubt es Caches, eine Antwort zu speichern, erfordert aber, sie vor der Wiederverwendung zu revalidieren. Wenn das, was Sie unter "nicht cachen" verstehen, tatsächlich "nicht speichern" meint, dann ist `no-store` die Direktive, die Sie verwenden sollten.
+Beachten Sie, dass `no-cache` nicht bedeutet "nicht speichern". `no-cache` erlaubt Caches, eine Antwort zu speichern, verlangt aber, dass sie vor der Wiederverwendung neu validiert wird. Wenn der Sinn von "nicht speichern", den Sie haben, tatsächlich "nicht gespeichert", dann ist `no-store` die zu verwendende Direktive.
#### `must-revalidate`
-Die `must-revalidate` Antwort-Direktive gibt an, dass die Antwort in Caches gespeichert und während sie [frisch](/de/docs/Web/HTTP/Caching#fresh_and_stale_based_on_age) ist, wiederverwendet werden kann. Wenn die Antwort [veraltet](/de/docs/Web/HTTP/Caching#fresh_and_stale_based_on_age) wird, muss sie vor der Wiederverwendung mit dem Ursprungsserver validiert werden.
+Die `must-revalidate` Antwort-Direktive gibt an, dass die Antwort in Caches gespeichert und während sie [frisch](/de/docs/Web/HTTP/Caching#fresh_and_stale_based_on_age) ist, wiederverwendet werden kann. Wenn die Antwort [veraltet](/de/docs/Web/HTTP/Caching#fresh_and_stale_based_on_age) wird, muss sie mit dem Ursprungsserver vor der Wiederverwendung validiert werden.
-Typischerweise wird `must-revalidate` zusammen mit `max-age` verwendet.
+Typischerweise wird `must-revalidate` mit `max-age` verwendet.
```http
Cache-Control: max-age=604800, must-revalidate
```
-HTTP erlaubt es Caches, [veraltete Antworten](/de/docs/Web/HTTP/Caching#fresh_and_stale_based_on_age) wiederzuverwenden, wenn sie vom Ursprungsserver getrennt sind. `must-revalidate` ist eine Möglichkeit, dies zu verhindern - entweder wird die gespeicherte Antwort mit dem Ursprungsserver revalidiert oder eine 504 (Gateway Timeout) Antwort wird generiert.
+HTTP erlaubt es Caches, [veraltete Antworten](/de/docs/Web/HTTP/Caching#fresh_and_stale_based_on_age) wiederzuverwenden, wenn sie von dem Ursprungsserver getrennt sind. `must-revalidate` ist eine Möglichkeit, dies zu verhindern - entweder wird die gespeicherte Antwort mit dem Ursprungsserver neu validiert oder eine 504 (Gateway Timeout) Antwort erzeugt.
#### `proxy-revalidate`
-Die `proxy-revalidate` Antwort-Direktive ist das Äquivalent von `must-revalidate`, jedoch speziell nur für gemeinsame Caches.
+Die `proxy-revalidate` Antwort-Direktive ist das Äquivalent zu `must-revalidate`, jedoch speziell nur für gemeinsame Caches.
#### `no-store`
-Die `no-store` Antwort-Direktive gibt an, dass keine Caches irgendeiner Art (privat oder gemeinsam) diese Antwort speichern sollten.
+Die `no-store` Antwort-Direktive gibt an, dass keine Caches irgendeiner Art (privat oder gemeinsam) diese Antwort speichern sollen.
```http
Cache-Control: no-store
@@ -160,41 +160,41 @@ Cache-Control: no-store
#### `private`
-Die `private` Antwort-Direktive gibt an, dass die Antwort nur in einem privaten Cache (z.B. lokale Caches in Browsern) gespeichert werden kann.
+Die `private` Antwort-Direktive gibt an, dass die Antwort nur in einem privaten Cache (z. B. lokale Caches in Browsern) gespeichert werden darf.
```http
Cache-Control: private
```
-Sie sollten die `private` Direktive für benutzerpersonalisierte Inhalte hinzufügen, insbesondere für Antworten, die nach dem Einloggen empfangen werden, und für Sitzungen, die über Cookies verwaltet werden.
+Sie sollten die `private` Direktive für benutzerpersonalisierte Inhalte hinzufügen, insbesondere für Antworten, die nach der Anmeldung empfangen werden, und für Sitzungen, die über Cookies verwaltet werden.
-Wenn Sie vergessen, `private` zu einer Antwort mit personalisierten Inhalten hinzuzufügen, kann diese Antwort in einem gemeinsamen Cache gespeichert und für mehrere Benutzer wiederverwendet werden, was dazu führen kann, dass persönliche Informationen durchsickern.
+Wenn Sie vergessen, `private` zu einer Antwort mit personalisierten Inhalten hinzuzufügen, kann diese Antwort in einem gemeinsamen Cache gespeichert und letztendlich für mehrere Benutzer wiederverwendet werden, was zu einem Leck persönlicher Informationen führen kann.
#### `public`
-Die `public` Antwort-Direktive gibt an, dass die Antwort in einem gemeinsamen Cache gespeichert werden kann. Antworten für Anfragen mit `Authorization` Header-Feldern dürfen nicht in einem gemeinsamen Cache gespeichert werden; jedoch wird die `public` Direktive dazu führen, dass solche Antworten in einem gemeinsamen Cache gespeichert werden.
+Die `public` Antwort-Direktive gibt an, dass die Antwort in einem gemeinsamen Cache gespeichert werden kann. Antworten für Anfragen mit `Authorization` Header-Feldern dürfen nicht in einem gemeinsamen Cache gespeichert werden; die `public` Direktive wird jedoch bewirken, dass solche Antworten in einem gemeinsamen Cache gespeichert werden.
```http
Cache-Control: public
```
-Im Allgemeinen, wenn Seiten unter Basic Auth oder Digest Auth sind, sendet der Browser Anfragen mit dem `Authorization`-Header. Das bedeutet, dass die Antwort für eingeschränkte Benutzer (die Konten haben) zugangskontrolliert ist und grundsätzlich nicht gemeinsam gecacht werden darf, selbst wenn sie `max-age` hat.
+Im Allgemeinen senden Browser bei Seiten mit Basis-Authentifizierung oder Digest-Authentifizierung Anfragen mit dem `Authorization` Header. Das bedeutet, dass die Antwort für eingeschränkte Benutzer (die Konten haben) zugriffskontrolliert ist und grundsätzlich nicht gemeinsam-cachebar ist, auch wenn es `max-age` hat.
-Sie können die `public` Direktive verwenden, um diese Beschränkung aufzuheben.
+Sie können die `public` Direktive verwenden, um diese Einschränkung aufzuheben.
```http
Cache-Control: public, max-age=604800
```
-Beachten Sie, dass `s-maxage` oder `must-revalidate` ebenfalls diese Beschränkung aufheben.
+Beachten Sie, dass `s-maxage` oder `must-revalidate` auch diese Einschränkung aufheben.
-Wenn eine Anfrage keinen `Authorization`-Header hat oder Sie bereits `s-maxage` oder `must-revalidate` in der Antwort verwenden, müssen Sie `public` nicht verwenden.
+Wenn eine Anfrage keinen `Authorization` Header hat oder Sie bereits `s-maxage` oder `must-revalidate` in der Antwort verwenden, dann müssen Sie `public` nicht verwenden.
#### `must-understand`
-Die `must-understand` Antwort-Direktive gibt an, dass ein Cache die Antwort nur speichern soll, wenn er die Anforderungen für das Caching basierend auf dem Statuscode versteht.
+Die `must-understand` Antwort-Direktive gibt an, dass ein Cache die Antwort nur speichern sollte, wenn er die Anforderungen für das Caching basierend auf dem Statuscode versteht.
-`must-understand` sollte mit `no-store` für ein Fallback-Verhalten gekoppelt werden.
+`must-understand` sollte mit `no-store` für Fallback-Verhalten gekoppelt werden.
```http
Cache-Control: must-understand, no-store
@@ -202,77 +202,77 @@ Cache-Control: must-understand, no-store
Wenn ein Cache `must-understand` nicht unterstützt, wird es ignoriert. Wenn `no-store` ebenfalls vorhanden ist, wird die Antwort nicht gespeichert.
-Wenn ein Cache `must-understand` unterstützt, speichert er die Antwort mit dem Verständnis der Cache-Anforderungen basierend auf dessen Statuscode.
+Wenn ein Cache `must-understand` unterstützt, speichert er die Antwort mit einem Verständnis der Cache-Anforderungen basierend auf ihrem Statuscode.
#### `no-transform`
-Einige Zwischeninstanzen transformieren Inhalte aus verschiedenen Gründen. Beispielsweise konvertieren einige Bilder, um die Übertragungsgröße zu reduzieren. In einigen Fällen ist dies für den Inhaltsanbieter unerwünscht.
+Einige Vermittler transformieren Inhalte aus verschiedenen Gründen. Zum Beispiel konvertieren einige Bilder, um die Übertragungsgröße zu reduzieren. In einigen Fällen ist dies für den Inhaltsanbieter unerwünscht.
-`no-transform` gibt an, dass jede Zwischeninstanz (unabhängig davon, ob sie einen Cache implementiert oder nicht) die Antwortinhalte nicht transformieren sollte.
+`no-transform` gibt an, dass jeder Vermittler (unabhängig davon, ob er einen Cache implementiert) den Inhalt der Antwort nicht transformieren sollte.
#### `immutable`
-Die `immutable` Antwort-Direktive gibt an, dass die Antwort nicht aktualisiert wird, solange sie [frisch](/de/docs/Web/HTTP/Caching#fresh_and_stale_based_on_age) ist.
+Die `immutable` Antwort-Direktive gibt an, dass die Antwort nicht aktualisiert wird, während sie [frisch](/de/docs/Web/HTTP/Caching#fresh_and_stale_based_on_age) ist.
```http
Cache-Control: public, max-age=604800, immutable
```
-Eine moderne Best Practice für statische Ressourcen ist es, Versionen/Hashwerte in ihre URLs einzuschließen, während die Ressourcen nie modifiziert werden — sondern stattdessen, wenn nötig, die Ressourcen mit neueren Versionen aktualisieren, die neue Versionsnummern/Hashwerte haben, sodass ihre URLs unterschiedlich sind. Dies wird als **Cache-Busting**-Muster bezeichnet.
+Eine moderne Best Practice für statische Ressourcen ist es, zugehörige Versionen/Hashes in ihren URLs zu inkludieren, während die Ressourcen niemals modifiziert werden — sondern stattdessen, wenn notwendig, die Ressourcen mit neueren Versionen zu _aktualisieren_, die neue Versionsnummern/Hashes haben, sodass ihre URLs unterschiedlich sind. Das wird als das **Cache-Busting**-Muster bezeichnet.
```html
```
-Wenn ein Benutzer den Browser neu lädt, sendet der Browser bedingte Anfragen zur Validierung an den Ursprungsserver. Aber es ist nicht notwendig, solche statischen Ressourcen selbst dann zu revalidieren, wenn ein Benutzer den Browser neu lädt, da sie nie modifiziert werden.
-`immutable` teilt einem Cache mit, dass die Antwort unveränderlich ist, während sie [frisch](/de/docs/Web/HTTP/Caching#fresh_and_stale_based_on_age) ist, und vermeidet solche unnötigen bedingten Anfragen an den Server.
+Wenn ein Benutzer den Browser neu lädt, sendet der Browser bedingte Anfragen zur Validierung an den Ursprungsserver. Aber es ist nicht erforderlich, solche Arten von statischen Ressourcen selbst beim Neuladen des Browsers neu zu validieren, da sie nie modifiziert werden.
+`immutable` signalisiert einem Cache, dass die Antwort unveränderlich ist, während sie [frisch](/de/docs/Web/HTTP/Caching#fresh_and_stale_based_on_age) ist und vermeidet diese Art von unnötigen bedingten Anfragen an den Server.
-Wenn Sie ein Cache-Busting-Muster für Ressourcen verwenden und sie auf einen langen `max-age` anwenden, können Sie auch `immutable` hinzufügen, um die Revalidierung zu vermeiden.
+Wenn Sie ein Cache-Busting-Muster für Ressourcen verwenden und es auf eine lange `max-age` anwenden, können Sie auch `immutable` hinzufügen, um eine Neubeurteilung zu vermeiden.
#### `stale-while-revalidate`
-Die `stale-while-revalidate` Antwort-Direktive gibt an, dass der Cache eine veraltete Antwort wiederverwenden könnte, während er sie zu einem Cache revalidiert.
+Die `stale-while-revalidate` Antwort-Direktive gibt an, dass der Cache eine veraltete Antwort wiederverwenden könnte, während er sie zu einem Cache neu validiert.
```http
Cache-Control: max-age=604800, stale-while-revalidate=86400
```
-Im obigen Beispiel ist die Antwort 7 Tage lang [frisch](/de/docs/Web/HTTP/Caching#fresh_and_stale_based_on_age) (604800 Sekunden).
-Nach 7 Tagen wird sie [veraltet](/de/docs/Web/HTTP/Caching#fresh_and_stale_based_on_age), aber der Cache darf sie für alle Anfragen wiederverwenden, die an dem folgenden Tag (86400 Sekunden) gemacht werden, vorausgesetzt, dass sie die Antwort im Hintergrund revalidieren.
+Im obigen Beispiel ist die Antwort [frisch](/de/docs/Web/HTTP/Caching#fresh_and_stale_based_on_age) für 7 Tage (604800s).
+Nach 7 Tagen wird sie [veraltet](/de/docs/Web/HTTP/Caching#fresh_and_stale_based_on_age), aber der Cache darf sie für alle Anfragen wiederverwenden, die am folgenden Tag (86400s) gemacht werden, vorausgesetzt, dass sie die Antwort im Hintergrund neu validieren.
-Die Revalidierung wird den Cache wieder [frisch](/de/docs/Web/HTTP/Caching#fresh_and_stale_based_on_age) machen, sodass es für die Clients so erscheint, als wäre er die ganze Zeit [frisch](/de/docs/Web/HTTP/Caching#fresh_and_stale_based_on_age) gewesen — wodurch effektiv die Latenzstrafe der Revalidierung vor ihnen verborgen wird.
+Die Neubeurteilung wird den Cache wieder [frisch](/de/docs/Web/HTTP/Caching#fresh_and_stale_based_on_age) machen, sodass es für die Clients scheint, dass es während dieser Zeit immer [frisch](/de/docs/Web/HTTP/Caching#fresh_and_stale_based_on_age) war — effektiv die Latenzstrafe der Neubeurteilung vor ihnen verbergend.
-Wenn während dieses Zeitraums keine Anfrage durchgeführt wurde, wird der Cache [veraltet](/de/docs/Web/HTTP/Caching#fresh_and_stale_based_on_age) und die nächste Anfrage revalidiert normal.
+Wenn während dieses Zeitraums keine Anfrage erfolgt ist, wird der Cache [veraltet](/de/docs/Web/HTTP/Caching#fresh_and_stale_based_on_age) und die nächste Anfrage wird normal neu validiert.
#### `stale-if-error`
-Die `stale-if-error` Antwort-Direktive gibt an, dass der Cache eine [veraltete Antwort](/de/docs/Web/HTTP/Caching#fresh_and_stale_based_on_age) wiederverwenden kann, wenn ein Zwischenserver einen Fehler erzeugt oder wenn der Fehler lokal entsteht. Ein Fehler wird hier als jede Antwort mit einem Statuscode von 500, 502, 503 oder 504 betrachtet.
+Die `stale-if-error` Antwort-Direktive gibt an, dass der Cache eine [veraltete Antwort](/de/docs/Web/HTTP/Caching#fresh_and_stale_based_on_age) wiederverwenden kann, wenn ein Fehler von einem Upstream-Server generiert wird oder wenn der Fehler lokal generiert wird. Hier wird jeder Fehler als jede Antwort mit einem Statuscode von 500, 502, 503 oder 504 betrachtet.
```http
Cache-Control: max-age=604800, stale-if-error=86400
```
-Im obigen Beispiel ist die Antwort 7 Tage [frisch](/de/docs/Web/HTTP/Caching#fresh_and_stale_based_on_age) (604800s). Danach wird sie [veraltet](/de/docs/Web/HTTP/Caching#fresh_and_stale_based_on_age), kann aber für einen zusätzlichen Tag (86400s) verwendet werden, wenn ein Fehler auftritt.
+Im obigen Beispiel ist die Antwort [frisch](/de/docs/Web/HTTP/Caching#fresh_and_stale_based_on_age) für 7 Tage (604800s). Danach wird sie [veraltet](/de/docs/Web/HTTP/Caching#fresh_and_stale_based_on_age), kann aber für einen zusätzlichen Tag (86400s) verwendet werden, wenn ein Fehler auftritt.
-Nach dem Ablauf des stale-if-error-Zeitraums erhält der Client jeden generierten Fehler.
+Nach Ablauf der stale-if-error-Periode wird der Client jeden erzeugten Fehler erhalten.
### Anfrage-Direktiven
#### `no-cache`
-Die `no-cache` Anfrage-Direktive fordert Caches auf, die Antwort mit dem Ursprungsserver zu validieren, bevor sie wiederverwendet wird.
+Die `no-cache` Anfrage-Direktive fordert Caches auf, die Antwort mit dem Ursprungsserver vor der Wiederverwendung zu validieren.
```http
Cache-Control: no-cache
```
-`no-cache` ermöglicht es Clients, die aktuellste Antwort anzufordern, selbst wenn der Cache bereits eine [frische](/de/docs/Web/HTTP/Caching#fresh_and_stale_based_on_age) Antwort hat.
+`no-cache` ermöglicht es Clients, die aktuellste Antwort anzufordern, selbst wenn der Cache eine [frische](/de/docs/Web/HTTP/Caching#fresh_and_stale_based_on_age) Antwort hat.
-Browser fügen Anfragen normalerweise `no-cache` hinzu, wenn Benutzer eine Seite **zwangserneuern**.
+Browser fügen normalerweise `no-cache` zu Anfragen hinzu, wenn Benutzer eine Seite **erneut laden**.
#### `no-store`
-Die `no-store` Anfrage-Direktive erlaubt einem Client, Caches zu bitten, darauf zu verzichten, die Anfrage und die entsprechende Antwort zu speichern — selbst wenn die Antwort des Ursprungsservers gespeichert werden könnte.
+Die `no-store` Anfrage-Direktive erlaubt einem Client, Cache-Speicher zu bitten, Anfrage und entsprechende Antwort nicht zu speichern — selbst wenn die Ursprungsserver-Antwort gespeichert werden könnte.
```http
Cache-Control: no-store
@@ -280,64 +280,64 @@ Cache-Control: no-store
#### `max-age`
-Die `max-age=N` Anfrage-Direktive gibt an, dass der Client eine gespeicherte Antwort zulässt, die innerhalb von _N_ Sekunden auf dem Ursprungsserver generiert wurde — wobei _N_ eine beliebige nicht negative ganze Zahl sein kann (einschließlich `0`).
+Die `max-age=N` Anfrage-Direktive gibt an, dass der Client eine gespeicherte Antwort erlaubt, die auf dem Ursprungserver innerhalb von _N_ Sekunden erzeugt wurde — wobei _N_ jede nicht-negative Ganzzahl sein kann (einschließlich `0`).
```http
Cache-Control: max-age=10800
```
-Im obigen Fall, wenn die Antwort mit `Cache-Control: max-age=10800` vor mehr als 3 Stunden generiert wurde (berechnet aus `max-age` und dem `Age`-Header), kann der Cache diese Antwort nicht wiederverwenden.
+Im obigen Fall, wenn die Antwort mit `Cache-Control: max-age=10800` vor mehr als 3 Stunden generiert wurde (berechnet aus `max-age` und dem `Age` Header), könnte der Cache diese Antwort nicht wiederverwenden.
-Viele Browser verwenden diese Direktive für **Neuladungen**, wie unten beschrieben.
+Viele Browser verwenden diese Direktive für **Neuladen**, wie unten erklärt.
```http
Cache-Control: max-age=0
```
-`max-age=0` ist eine Umgehungslösung für `no-cache`, weil viele alte (HTTP/1.0) Cache-Implementierungen `no-cache` nicht unterstützen. Kürzlich verwenden Browser immer noch `max-age=0` beim "Neuladen" — für Rückwärtskompatibilität — und alternativ `no-cache`, um ein "zwangserneuern" zu verursachen.
+`max-age=0` ist ein Workaround für `no-cache`, da viele alte (HTTP/1.0) Cache-Implementierungen `no-cache` nicht unterstützen. Kürzlich verwenden Browser immer noch `max-age=0` beim "Neuladen" — aus Gründen der Abwärtskompatibilität — und alternativ `no-cache`, um ein "Force-Reloading" zu verursachen.
-Wenn der `max-age`-Wert negativ ist (zum Beispiel `-1`) oder keine ganze Zahl ist (zum Beispiel `3599.99`), ist das Caching-Verhalten nicht spezifiziert. Caches werden ermutigt, den Wert so zu behandeln, als wäre er `0`.
+Wenn der `max-age` Wert negativ ist (zum Beispiel `-1`) oder kein Ganzzahlwert (zum Beispiel `3599.99`) ist, ist das Caching-Verhalten nicht spezifiziert. Caches wird empfohlen, den Wert so zu behandeln, als wäre er `0`.
#### `max-stale`
-Die `max-stale=N` Anfrage-Direktive gibt an, dass der Client eine gespeicherte Antwort zulässt, die innerhalb von _N_ Sekunden [veraltet](/de/docs/Web/HTTP/Caching#fresh_and_stale_based_on_age) ist.
-Wenn kein _N_ Wert angegeben ist, akzeptiert der Client eine veraltete Antwort jeden Alters.
+Die `max-stale=N` Anfrage-Direktive gibt an, dass der Client eine gespeicherte Antwort erlaubt, die innerhalb von _N_ Sekunden [veraltet](/de/docs/Web/HTTP/Caching#fresh_and_stale_based_on_age) ist.
+Wenn kein _N_ Wert angegeben ist, akzeptiert der Client eine veraltete Antwort beliebigen Alters.
```http
Cache-Control: max-stale=3600
```
-Zum Beispiel zeigt eine Anfrage mit dem obigen Header an, dass der Browser eine veraltete Antwort aus dem Cache akzeptiert, die innerhalb der letzten Stunde abgelaufen ist.
+Zum Beispiel signalisiert eine Anfrage mit dem obigen Header, dass der Browser eine veraltete Antwort aus dem Cache akzeptiert, die in der letzten Stunde abgelaufen ist.
-Clients können diesen Header verwenden, wenn der Ursprungsserver ausgefallen ist oder zu langsam ist und sie können Antworten aus Caches akzeptieren, selbst wenn sie etwas älter sind.
+Clients können diesen Header verwenden, wenn der Ursprungsserver nicht erreichbar oder zu langsam ist und zwischengespeicherte Antworten aus Caches auch dann akzeptieren kann, wenn sie etwas alt sind.
-Beachten Sie, dass die wichtigsten Browser keine Anfragen mit `max-stale` unterstützen.
+Beachten Sie, dass die meisten Browser Anfragen mit `max-stale` nicht unterstützen.
#### `min-fresh`
-Die `min-fresh=N` Anfrage-Direktive gibt an, dass der Client eine gespeicherte Antwort zulässt, die mindestens _N_ Sekunden lang [frisch](/de/docs/Web/HTTP/Caching#fresh_and_stale_based_on_age) ist.
+Die `min-fresh=N` Anfrage-Direktive gibt an, dass der Client eine gespeicherte Antwort erlaubt, die mindestens für _N_ Sekunden [frisch](/de/docs/Web/HTTP/Caching#fresh_and_stale_based_on_age) ist.
```http
Cache-Control: min-fresh=600
```
-Im obigen Fall, wenn die Antwort mit `Cache-Control: max-age=3600` vor 51 Minuten in Caches gespeichert wurde, kann der Cache diese Antwort nicht wiederverwenden.
+Im obigen Fall, wenn die Antwort mit `Cache-Control: max-age=3600` vor 51 Minuten in Caches gespeichert wurde, könnte der Cache diese Antwort nicht wiederverwenden.
-Clients können diesen Header verwenden, wenn der Benutzer verlangt, dass die Antwort nicht nur [frisch](/de/docs/Web/HTTP/Caching#fresh_and_stale_based_on_age) ist, sondern auch für eine gewisse Zeit nicht aktualisiert wird.
+Clients können diesen Header verwenden, wenn der Benutzer verlangt, dass die Antwort nicht nur [frisch](/de/docs/Web/HTTP/Caching#fresh_and_stale_based_on_age) ist, sondern auch verlangt, dass sie für einen bestimmten Zeitraum nicht aktualisiert wird.
-Beachten Sie, dass die wichtigsten Browser keine Anfragen mit `min-fresh` unterstützen.
+Beachten Sie, dass die meisten Browser Anfragen mit `min-fresh` nicht unterstützen.
#### `no-transform`
-Bedeutet dasselbe wie `no-transform` für eine Antwort, jedoch für eine Anfrage.
+Gleiche Bedeutung wie `no-transform` für eine Antwort, aber für eine Anfrage.
#### `only-if-cached`
-Der Client gibt an, dass eine bereits im Cache gespeicherte Antwort zurückgegeben werden soll. Wenn ein Cache eine gespeicherte Antwort hat, selbst eine veraltete, wird sie zurückgegeben. Wenn keine zwischengespeicherte Antwort verfügbar ist, wird eine [504 Gateway Timeout](/de/docs/Web/HTTP/Status/504) Antwort zurückgegeben.
+Der Client gibt an, dass eine bereits zwischengespeicherte Antwort zurückgegeben werden sollte. Wenn ein Cache eine gespeicherte Antwort hat, selbst eine veraltete, wird sie zurückgegeben. Wenn keine zwischengespeicherte Antwort verfügbar ist, wird eine [504 Gateway Timeout](/de/docs/Web/HTTP/Status/504) Antwort zurückgegeben.
## Anwendungsfälle
-### Verhindern des Speicherns
+### Speicherung verhindern
Wenn Sie nicht möchten, dass eine Antwort in Caches gespeichert wird, verwenden Sie die `no-store` Direktive.
@@ -345,25 +345,25 @@ Wenn Sie nicht möchten, dass eine Antwort in Caches gespeichert wird, verwenden
Cache-Control: no-store
```
-Beachten Sie, dass `no-cache` bedeutet "es kann gespeichert werden, aber nicht ohne Validierung wiederverwenden" – es ist also nicht dafür gedacht, eine Antwort nicht zu speichern.
+Beachten Sie, dass `no-cache` bedeutet "es kann gespeichert werden, aber nicht wiederverwenden, bevor es validiert wird" — also ist es nicht dafür gedacht, eine Antwort davon abzuhalten, gespeichert zu werden.
```http example-bad
Cache-Control: no-cache
```
-Theoretisch sollte bei widersprüchlichen Direktiven die restriktivste beachtet werden. Das folgende Beispiel ist also im Grunde bedeutungslos, weil `private`, `no-cache`, `max-age=0` und `must-revalidate` im Widerspruch zu `no-store` stehen.
+Theoretisch, wenn Direktiven im Konflikt stehen, sollte die restriktivste Direktive beachtet werden. Daher ist das folgende Beispiel im Grunde genommen bedeutungslos, da `private`, `no-cache`, `max-age=0` und `must-revalidate` mit `no-store` in Konflikt stehen.
```http example-bad
-# widersprüchlich
+# im Konflikt
Cache-Control: private, no-cache, no-store, max-age=0, must-revalidate
-# entspricht
+# gleichwertig zu
Cache-Control: no-store
```
-### Caching von statischen Assets mit "Cache-Busting"
+### Caching von statischen Ressourcen mit "cache busting"
-Wenn Sie statische Assets mit Versionierungs-/Hashing-Mechanismen erstellen, ist das Hinzufügen einer Version/eines Hashes zum Dateinamen oder zur Abfragezeichenfolge eine gute Möglichkeit, das Caching zu verwalten.
+Wenn Sie statische Ressourcen mit Versionierungs-/Hashing-Mechanismen erstellen, ist das Hinzufügen einer Version / eines Hashs zum Dateinamen oder zur Abfragezeichenfolge eine gute Möglichkeit zur Verwaltung des Cachings.
Zum Beispiel:
@@ -373,9 +373,9 @@ Zum Beispiel:
```
-Die Version der React-Bibliothek wird sich ändern, wenn Sie die Bibliothek aktualisieren, und `hero.png` wird sich auch ändern, wenn Sie das Bild bearbeiten. Diese sind also schwer im Cache mit `max-age` zu speichern.
+Die Version der React-Bibliothek ändert sich, wenn Sie die Bibliothek aktualisieren, und `hero.png` ändert sich ebenfalls, wenn Sie das Bild bearbeiten. Diese sind also schwierig in einem Cache mit `max-age` zu speichern.
-In einem solchen Fall könnten Sie die Caching-Bedürfnisse adressieren, indem Sie eine spezifische, nummerierte Version der Bibliothek verwenden und den Hash des Bildes in seine URL einschließen.
+In einem solchen Fall könnten Sie den Caching-Anforderungen durch die Verwendung einer spezifischen, nummerierten Version der Bibliothek gerecht werden und den Hash des Bildes in seine URL einfügen.
```html
@@ -383,51 +383,51 @@ In einem solchen Fall könnten Sie die Caching-Bedürfnisse adressieren, indem S
```
-Sie können einen langen `max-age` Wert und `immutable` hinzufügen, weil sich die Inhalte nie ändern werden.
+Sie können einen langen `max-age` Wert und `immutable` hinzufügen, weil der Inhalt sich nie ändern wird.
```http
# /assets/*
Cache-Control: max-age=31536000, immutable
```
-Wenn Sie die Bibliothek aktualisieren oder das Bild bearbeiten, sollten neue Inhalte eine neue URL haben, und Caches werden nicht wiederverwendet. Dies wird als "Cache-Busting" Muster bezeichnet.
+Wenn Sie die Bibliothek aktualisieren oder das Bild bearbeiten, sollte neuer Inhalt eine neue URL haben, und Caches werden nicht wiederverwendet. Das wird als "Cache Busting"-Muster bezeichnet.
-Verwenden Sie `no-cache`, um sicherzustellen, dass die HTML-Antwort selbst nicht gecacht wird. `no-cache` könnte eine Revalidierung verursachen, und der Client erhält korrekt eine neue Version der HTML-Antwort und der statischen Assets.
+Verwenden Sie ein `no-cache`, um sicherzustellen, dass die HTML-Antwort selbst nicht zwischengespeichert wird. `no-cache` könnte eine Neubeurteilung verursachen, und der Client wird korrekt eine neue Version der HTML-Antwort und der statischen Ressourcen erhalten.
```http
# /index.html
Cache-Control: no-cache
```
-Hinweis: Wenn `index.html` unter Basic Authentifizierung oder Digest Authentifizierung steht, werden Dateien unter `/assets` nicht im gemeinsamen Cache gespeichert. Wenn `/assets/`-Dateien geeignet sind, im gemeinsamen Cache gespeichert zu werden, benötigen Sie zusätzlich eines von `public`, `s-maxage` oder `must-revalidate`.
+Hinweis: Wenn `index.html` unter Basis-Authentifizierung oder Digest-Authentifizierung kontrolliert wird, werden Dateien unter `/assets` nicht im gemeinsamen Cache gespeichert. Wenn Dateien unter `/assets/` geeignet sind, im gemeinsamen Cache gespeichert zu werden, benötigen Sie auch eines der `public`, `s-maxage` oder `must-revalidate`.
### Immer aktuelle Inhalte
-Für Inhalte, die dynamisch erzeugt werden oder die statisch sind, aber häufig aktualisiert werden, wollen Sie, dass ein Benutzer immer die aktuellste Version erhält.
+Für Inhalte, die dynamisch generiert werden oder statisch sind, aber häufig aktualisiert werden, möchten Sie, dass ein Benutzer immer die aktuellste Version erhält.
-Wenn Sie kein `Cache-Control` Header hinzufügen, weil die Antwort nicht gecacht werden soll, könnte das zu einem unerwarteten Ergebnis führen. Cache-Speicher dürfen sie heuristisch cachen — also wenn Sie irgendwelche Anforderungen an das Caching haben, sollten Sie diese immer ausdrücklich im `Cache-Control` Header angeben.
+Wenn Sie keinen `Cache-Control` Header hinzufügen, weil die Antwort nicht zwischengespeichert werden soll, könnte das zu einem unerwarteten Ergebnis führen. Der Cache-Speicher darf dies heuristisch zwischenspeichern — wenn Sie also Anforderungen an das Caching haben, sollten Sie sie immer explizit in dem `Cache-Control` Header angeben.
-Das Hinzufügen von `no-cache` zur Antwort verursacht eine Revalidierung beim Server, sodass Sie jedes Mal eine [frische](/de/docs/Web/HTTP/Caching#fresh_and_stale_based_on_age) Antwort servieren — oder wenn der Client bereits eine neue hat, einfach mit `304 Not Modified` antworten.
+Das Hinzufügen von `no-cache` zur Antwort verursacht eine Neubeurteilung mit dem Server, sodass Sie jedes Mal eine [frische](/de/docs/Web/HTTP/Caching#fresh_and_stale_based_on_age) Antwort bereitstellen können — oder wenn der Client bereits eine neue hat, einfach `304 Not Modified` antworten.
```http
Cache-Control: no-cache
```
-Die meisten HTTP/1.0 Caches unterstützen die `no-cache` Direktiven nicht, daher wurde historisch `max-age=0` als Umgehungslösung verwendet. Aber nur `max-age=0` könnte dazu führen, dass eine [veraltete Antwort](/de/docs/Web/HTTP/Caching#fresh_and_stale_based_on_age) wiederverwendet wird, wenn Caches vom Ursprungsserver getrennt sind. `must-revalidate` behandelt das. Deshalb ist das folgende Beispiel gleichbedeutend mit `no-cache`.
+Die meisten HTTP/1.0-Caches unterstützen keine `no-cache` Direktiven, daher wurde historisch `max-age=0` als Workaround verwendet. Aber nur `max-age=0` könnte eine [veraltete Antwort](/de/docs/Web/HTTP/Caching#fresh_and_stale_based_on_age) verursachen, die wiederverwendet wird, wenn Caches vom Ursprungsserver getrennt sind. `must-revalidate` adressiert dies. Daher ist das folgende Beispiel gleichwertig zu `no-cache`.
```http
Cache-Control: max-age=0, must-revalidate
```
-Aber jetzt können Sie einfach `no-cache` verwenden.
+Aber im Moment können Sie einfach `no-cache` verwenden.
### Löschen eines bereits gespeicherten Caches
Leider gibt es keine Cache-Direktiven zum Löschen bereits gespeicherter Antworten aus Caches.
-Stellen Sie sich vor, dass Clients/Caches eine [frische](/de/docs/Web/HTTP/Caching#fresh_and_stale_based_on_age) Antwort für einen Pfad speichern, ohne dass eine Anfrage an den Server erfolgt. Es gibt nichts, was ein Server für diesen Pfad tun könnte.
+Stellen Sie sich vor, dass Clients/Caches eine [frische](/de/docs/Web/HTTP/Caching#fresh_and_stale_based_on_age) Antwort für einen Pfad speichern, ohne Anfrageflug zum Server. Es gibt nichts, was ein Server für diesen Pfad tun könnte.
-Alternativ kann `Clear-Site-Data` einen Browser-Cache für eine Site löschen. Aber Vorsicht: Das löscht jede gespeicherte Antwort für eine Seite — und nur in Browsern, nicht für einen gemeinsamen Cache.
+Alternativ kann `Clear-Site-Data` einen Browser-Cache für eine Seite löschen. Aber seien Sie vorsichtig: Dies löscht jede gespeicherte Antwort für eine Seite — und nur in Browsern, nicht für einen gemeinsamen Cache.
## Spezifikationen
@@ -440,8 +440,8 @@ Alternativ kann `Clear-Site-Data` einen Browser-Cache für eine Site löschen. A
## Siehe auch
- [HTTP-Caching](/de/docs/Web/HTTP/Caching)
-- [Caching-Tutorial für Webautoren und Webmaster](https://www.mnot.net/cache_docs/)
-- [Caching Best Practices & Max-Age Gotchas](https://jakearchibald.com/2016/caching-best-practices/)
+- [Caching-Tutorial für Web-Autoren und Webmaster](https://www.mnot.net/cache_docs/)
+- [Caching Best Practices & max-age Stolperfallen](https://jakearchibald.com/2016/caching-best-practices/)
- [Cache-Control für Zivilisten](https://csswizardry.com/2019/03/cache-control-for-civilians/)
- [RFC 9111 – HTTP Caching](https://httpwg.org/specs/rfc9111.html)
- [RFC 5861 – HTTP Cache-Control Erweiterungen für veraltete Inhalte](https://httpwg.org/specs/rfc5861.html)
diff --git a/files/de/web/http/headers/clear-site-data/index.md b/files/de/web/http/headers/clear-site-data/index.md
index 0560274d1..240c14c2c 100644
--- a/files/de/web/http/headers/clear-site-data/index.md
+++ b/files/de/web/http/headers/clear-site-data/index.md
@@ -7,12 +7,12 @@ l10n:
{{securecontext_header}}{{HTTPSidebar}}
-Der **`Clear-Site-Data`**-Header entfernt Browserdaten (Cookies, Speicherung, Cache), die mit der anfordernden Website verbunden sind. Er ermöglicht Webentwicklern, mehr Kontrolle über die von einem Client-Browser für ihre Ursprünge gespeicherten Daten zu haben.
+Der **`Clear-Site-Data`**-Header löscht Browsing-Daten (Cookies, Speicher, Cache), die mit der anfordernden Website verbunden sind. Er ermöglicht es Webentwicklern, mehr Kontrolle über die vom Client-Browser für ihre Ursprünge gespeicherten Daten zu haben.
-
Header type
+
Headertyp
{{Glossary("Response header")}}
@@ -24,67 +24,67 @@ Der **`Clear-Site-Data`**-Header entfernt Browserdaten (Cookies, Speicherung, Ca
## Syntax
-Der `Clear-Site-Data`-Header akzeptiert eine oder mehrere Direktiven. Wenn alle Datentypen gelöscht werden sollen, kann die Platzhalter-Direktive (`"*"`) verwendet werden.
+Der `Clear-Site-Data`-Header akzeptiert eine oder mehrere Direktiven. Wenn alle Arten von Daten gelöscht werden sollen, kann die Joker-Direktive (`"*"`) verwendet werden.
```http
// Einzelne Direktive
Clear-Site-Data: "cache"
-// Mehrere Direktiven (durch Komma getrennt)
+// Mehrere Direktiven (kommagetrennt)
Clear-Site-Data: "cache", "cookies"
-// Platzhalter
+// Wildcard
Clear-Site-Data: "*"
```
## Direktiven
> [!NOTE]
-> Alle Direktiven müssen der [quoted-string grammar](https://datatracker.ietf.org/doc/html/rfc7230#section-3.2.6) entsprechen. Eine Direktive, die die Anführungszeichen nicht enthält, ist ungültig.
+> Alle Direktiven müssen der [quoted-string Grammatik](https://datatracker.ietf.org/doc/html/rfc7230#section-3.2.6) entsprechen. Eine Direktive, die nicht die Anführungszeichen enthält, ist ungültig.
- `"cache"` {{Experimental_Inline}}
- - : Zeigt an, dass der Server den lokal zwischengespeicherten Daten (den Browser-Cache, siehe [HTTP-Caching](/de/docs/Web/HTTP/Caching)) für den Ursprung der Antwort-URL entfernen möchte. Abhängig vom Browser können auch Dinge wie vorgerenderte Seiten, Skriptcaches, WebGL-Shader-Caches oder Adressleisten-Vorschläge gelöscht werden.
+ - : Gibt an, dass der Server wünscht, lokal zwischengespeicherte Daten (den Browsercache, siehe [HTTP-Caching](/de/docs/Web/HTTP/Caching)) für den Ursprung der Antwort-URL zu entfernen. Abhängig vom Browser kann dies auch Dinge wie vorgerenderte Seiten, Skript-Caches, WebGL-Shader-Caches oder Adressleiste-Vorschläge löschen.
- `"clientHints"` {{Experimental_Inline}}
- - : Zeigt an, dass der Server alle [client hints](/de/docs/Web/HTTP/Client_hints) (angefordert über {{httpheader("Accept-CH")}}) löschen möchte, die für den Ursprung der Antwort-URL gespeichert sind.
+ - : Gibt an, dass der Server wünscht, alle [Client-Hints](/de/docs/Web/HTTP/Client_hints) (angefordert via {{httpheader("Accept-CH")}}) für den Ursprung der Antwort-URL zu entfernen.
> [!NOTE]
- > In Browsern, die den Datentyp `"clientHints"` unterstützen, werden Client-Hints auch gelöscht, wenn die Typen `"cache"`, `"cookies"` oder `"*"` angegeben sind. `"clientHints"` ist daher nur erforderlich, wenn keiner dieser anderen Typen angegeben ist.
+ > In Browsern, die den Datentyp `"clientHints"` unterstützen, werden Client-Hints auch gelöscht, wenn die Typen `"cache"`, `"cookies"` oder `"*"` angegeben werden. `"clientHints"` ist daher nur erforderlich, wenn keiner dieser anderen Typen angegeben ist.
- `"cookies"`
- - : Zeigt an, dass der Server alle Cookies für den Ursprung der Antwort-URL entfernen möchte. Auch HTTP-Authentifizierungsdaten werden gelöscht. Dies betrifft die gesamte registrierte Domain, einschließlich Subdomains. So werden Cookies sowohl von `https://example.com` als auch von `https://stage.example.com` entfernt.
+ - : Gibt an, dass der Server wünscht, alle Cookies für den Ursprung der Antwort-URL zu entfernen. HTTP-Authentifizierungsanmeldedaten werden ebenfalls gelöscht. Dies betrifft die gesamte registrierte Domain, einschließlich Subdomains. Also sowohl `https://example.com` als auch `https://stage.example.com` werden die Cookies gelöscht.
- `"storage"`
- - : Zeigt an, dass der Server alle DOM-Speicher für den Ursprung der Antwort-URL entfernen möchte. Dies umfasst Speichersysteme wie:
+ - : Gibt an, dass der Server wünscht, alle DOM-Speicher für den Ursprung der Antwort-URL zu entfernen. Dies schließt Speichermethoden wie ein:
- localStorage (führt `localStorage.clear` aus),
- sessionStorage (führt `sessionStorage.clear` aus),
- - IndexedDB (führt für jede Datenbank {{domxref("IDBFactory.deleteDatabase")}} aus),
- - Service-Worker-Registrierungen (führt für jede Service-Worker-Registrierung {{domxref("ServiceWorkerRegistration.unregister")}} aus),
- - Web-SQL-Datenbanken (veraltet),
- - [Dateisystem-API-Daten](/de/docs/Web/API/File_and_Directory_Entries_API),
- - Plugin-Daten (Flash über [`NPP_ClearSiteData`](https://wiki.mozilla.org/NPAPI:ClearSiteData)).
+ - IndexedDB (für jede Datenbank {{domxref("IDBFactory.deleteDatabase")}} ausführen),
+ - Service-Worker-Registrierungen (für jede Service-Worker-Registrierung {{domxref("ServiceWorkerRegistration.unregister")}} ausführen),
+ - Web SQL-Datenbanken (veraltet),
+ - [FileSystem-API-Daten](/de/docs/Web/API/File_and_Directory_Entries_API),
+ - Plug-in-Daten (Flash über [`NPP_ClearSiteData`](https://wiki.mozilla.org/NPAPI:ClearSiteData)).
- `"executionContexts"` {{Experimental_Inline}}
- - : Zeigt an, dass der Server alle Browsing-Kontexte für den Ursprung der Antwort neu laden möchte ({{domxref("Location.reload")}}).
-- `"*"` (Platzhalter)
- - : Zeigt an, dass der Server alle Datentypen für den Ursprung der Antwort löschen möchte. Wenn in zukünftigen Versionen dieses Headers weitere Datentypen hinzugefügt werden, werden diese ebenfalls abgedeckt sein.
+ - : Gibt an, dass der Server wünscht, alle Browsing-Kontexte für den Ursprung der Antwort zu neu zu laden ({{domxref("Location.reload")}}).
+- `"*"` (Wildcard)
+ - : Gibt an, dass der Server wünscht, alle Arten von Daten für den Ursprung der Antwort zu löschen. Wenn in zukünftigen Versionen dieses Headers weitere Datentypen hinzugefügt werden, werden diese ebenfalls abgedeckt.
## Beispiele
### Abmelden von einer Website
-Wenn sich ein Nutzer von Ihrer Website oder Ihrem Dienst abmeldet, möchten Sie möglicherweise lokal gespeicherte Daten entfernen. Um dies zu tun, fügen Sie den `Clear-Site-Data`-Header zu der Seite hinzu, die das erfolgreiche Abmelden von der Website bestätigt (z. B. `https://example.com/logout`):
+Wenn sich ein Benutzer von Ihrer Website oder Ihrem Dienst abmeldet, möchten Sie möglicherweise lokal gespeicherte Daten entfernen. Fügen Sie dazu den `Clear-Site-Data`-Header zur Seite hinzu, die bestätigt, dass das Ausloggen von der Website erfolgreich abgeschlossen wurde (`https://example.com/logout`, zum Beispiel):
```http
Clear-Site-Data: "cache", "cookies", "storage", "executionContexts"
```
-### Cookies löschen
+### Löschen von Cookies
-Wenn dieser Header mit der Antwort an `https://example.com/clear-cookies` geliefert wird, werden alle Cookies auf derselben Domain `https://example.com` und allen Subdomains (wie `https://stage.example.com`, etc.) gelöscht.
+Wenn dieser Header mit der Antwort unter `https://example.com/clear-cookies` ausgegeben wird, werden alle Cookies auf derselben Domain `https://example.com` und allen Subdomains (wie `https://stage.example.com`, etc.) gelöscht.
```http
Clear-Site-Data: "cookies"
@@ -94,7 +94,7 @@ Clear-Site-Data: "cookies"
{{Specifications}}
-## Browser-Kompatibilität
+## Kompatibilität der Browser
{{Compat}}
diff --git a/files/de/web/http/headers/connection/index.md b/files/de/web/http/headers/connection/index.md
index a566aee36..0e74c8f79 100644
--- a/files/de/web/http/headers/connection/index.md
+++ b/files/de/web/http/headers/connection/index.md
@@ -7,14 +7,14 @@ l10n:
{{HTTPSidebar}}
-Der **`Connection`** Allgemein-Header steuert, ob die Netzwerkverbindung offen bleibt, nachdem die aktuelle Transaktion beendet ist. Wenn der gesendete Wert `keep-alive` lautet, bleibt die Verbindung bestehen und wird nicht geschlossen, was es ermöglicht, nachfolgende Anfragen an denselben Server zu senden.
+Der **`Connection`** allgemeine Header steuert, ob die Netzwerkverbindung nach Abschluss der aktuellen Transaktion offen bleibt. Wenn der gesendete Wert `keep-alive` ist, bleibt die Verbindung bestehen und wird nicht geschlossen, was es ermöglicht, nachfolgende Anfragen an denselben Server zu stellen.
> [!WARNING]
-> Verbindungs-spezifische Header-Felder wie `Connection` und {{HTTPHeader("Keep-Alive")}} sind in [HTTP/2](https://httpwg.org/specs/rfc9113.html#ConnectionSpecific) und [HTTP/3](https://httpwg.org/specs/rfc9114.html#header-formatting) verboten. Chrome und Firefox ignorieren sie in HTTP/2-Antworten, aber Safari hält sich an die HTTP/2-Spezifikationsanforderungen und lädt keine Antwort, die sie enthält.
+> Verbindungsbezogene Header-Felder wie `Connection` und {{HTTPHeader("Keep-Alive")}} sind in [HTTP/2](https://httpwg.org/specs/rfc9113.html#ConnectionSpecific) und [HTTP/3](https://httpwg.org/specs/rfc9114.html#header-formatting) untersagt. Chrome und Firefox ignorieren sie in HTTP/2-Antworten, aber Safari hält sich an die HTTP/2-Spezifikationsanforderungen und lädt keine Antwort, die sie enthält.
-Alle [Hop-by-hop-Header](/de/docs/Web/HTTP/Compression#hop-by-hop_compression), die von der Nachricht verwendet werden - einschließlich standardmäßiger Hop-by-hop-Header ({{HTTPHeader("Keep-Alive")}}, {{HTTPHeader("Transfer-Encoding")}}, {{HTTPHeader("TE")}}, `Connection`, {{HTTPHeader("Trailer")}}, {{HTTPHeader("Upgrade")}}, {{HTTPHeader("Proxy-Authorization")}} und {{HTTPHeader("Proxy-Authenticate")}}) - müssen im `Connection`-Header aufgelistet werden, sodass der erste Proxy weiß, dass er sie konsumieren und nicht weiterleiten soll.
+Alle [Hop-by-Hop-Header](/de/docs/Web/HTTP/Compression#hop-by-hop_compression), die von der Nachricht verwendet werden – einschließlich standardmäßiger Hop-by-Hop-Header ({{HTTPHeader("Keep-Alive")}}, {{HTTPHeader("Transfer-Encoding")}}, {{HTTPHeader("TE")}}, `Connection`, {{HTTPHeader("Trailer")}}, {{HTTPHeader("Upgrade")}}, {{HTTPHeader("Proxy-Authorization")}} und {{HTTPHeader("Proxy-Authenticate")}}) – müssen im `Connection`-Header aufgelistet werden, sodass der erste Proxy weiß, dass er sie verwenden muss und nicht weiterleiten darf.
-Der Standardwert von `Connection` hat sich zwischen HTTP/1.0 und HTTP/1.1 geändert. Daher senden Browser oft `Connection: keep-alive` explizit, um die Abwärtskompatibilität zu gewährleisten, obwohl dies in HTTP/1.1 der Standard ist.
+Der Standardwert von `Connection` änderte sich zwischen HTTP/1.0 und HTTP/1.1. Um die Rückwärtskompatibilität zu gewährleisten, senden Browser oft explizit `Connection: keep-alive`, obwohl dies der Standard in HTTP/1.1 ist.
@@ -42,9 +42,10 @@ Connection: close
## Direktiven
- `close`
- - : Gibt an, dass entweder der Client oder der Server die Verbindung schließen möchte. Dies ist der Standard bei HTTP/1.0-Anfragen.
-- jede durch Kommas getrennte Liste von HTTP-Headern \[Üblicherweise nur `keep-alive`]
- - : Gibt an, dass der Client die Verbindung offen halten möchte. Das Offenhalten einer Verbindung ist der Standard bei HTTP/1.1-Anfragen. Die Liste der Header sind die Namen der Header, die vom ersten nicht transparenten Proxy oder Cache entfernt werden sollen: Diese Header definieren die Verbindung zwischen dem Absender und der ersten Entität, nicht dem Zielknoten.
+ - : Gibt an, dass entweder der Client oder der Server die Verbindung schließen möchte.
+ Dies ist der Standard bei HTTP/1.0-Anfragen.
+- Jede kommagetrennte Liste von HTTP-Headern \[Üblicherweise nur `keep-alive`]
+ - : Gibt an, dass der Client die Verbindung offen halten möchte. Das Offenhalten einer Verbindung ist der Standard bei HTTP/1.1-Anfragen. Die Liste der Header sind die Namen der Header, die vom ersten nicht transparenten Proxy oder Cache dazwischen entfernt werden sollen: Diese Header definieren die Verbindung zwischen dem Absender und der ersten Entität, nicht dem Zielknoten.
## Spezifikationen
diff --git a/files/de/web/http/headers/content-digest/index.md b/files/de/web/http/headers/content-digest/index.md
index 9bd6d343f..7faf4eec7 100644
--- a/files/de/web/http/headers/content-digest/index.md
+++ b/files/de/web/http/headers/content-digest/index.md
@@ -7,11 +7,11 @@ l10n:
{{HTTPSidebar}}{{SeeCompatTable}}
-Der **`Content-Digest`** Antwort- oder Anfrage-Header bietet einen {{Glossary("digest")}} des tatsächlichen Nachrichteninhalts, des Stroms von Oktetten, die in einer HTTP-Nachricht gerahmt sind. Somit hängt `Content-Digest` unter anderem von {{HTTPHeader("Content-Encoding")}} und {{HTTPHeader("Content-Range")}} ab, nicht aber zum Beispiel von HTTP/1.1's {{HTTPHeader("Transfer-Encoding")}}. `Content-Digest` kann mit {{HTTPHeader("Repr-Digest")}} übereinstimmen, wenn eine Repräsentation in einer einzigen Nachricht gesendet wurde.
+Der **`Content-Digest`** Antwort- oder Anforderungsheader bietet einen {{Glossary("digest")}} des tatsächlichen Nachrichteninhalts, dem Byte-Strom, der in einer HTTP-Nachricht umrahmt ist. Daher ist `Content-Digest` unter anderem abhängig von {{HTTPHeader("Content-Encoding")}} und {{HTTPHeader("Content-Range")}}, jedoch nicht abhängig von beispielsweise {{HTTPHeader("Transfer-Encoding")}} von HTTP/1.1. `Content-Digest` kann mit {{HTTPHeader("Repr-Digest")}} übereinstimmen, wenn eine Darstellung in einer einzelnen Nachricht gesendet wurde.
-In diesem Zusammenhang bezieht sich _content_ auf eine bestimmte Oktettenrepräsentation der [ausgewählten Darstellung](https://www.rfc-editor.org/rfc/rfc9110#section-6.4) der Zielressource.
+In diesem Kontext bezieht sich _content_ auf eine bestimmte Byte-Darstellung der [ausgewählten Darstellung](https://www.rfc-editor.org/rfc/rfc9110#section-6.4) der Zielressource.
-Ein Client kann anfordern, dass ein Server einen `Content-Digest` bereitstellt, indem er {{HTTPHeader("Want-Content-Digest")}} ausstellt.
+Ein Client kann verlangen, dass ein Server einen `Content-Digest` sendet, indem er {{HTTPHeader("Want-Content-Digest")}} ausgibt.
@@ -20,18 +20,18 @@ Ein Client kann anfordern, dass ein Server einen `Content-Digest` bereitstellt,
{{Glossary("Representation header")}}
-
{{Glossary("Forbidden header name")}}
-
nein
+
{{Glossary("Verbotener Header-Name")}}
+
Nein
## Syntax
-`Content-Digest` beschreibt ein [RFC8941-Wörterbuch](https://www.rfc-editor.org/rfc/rfc8941#section-3.2), dessen Schlüssel die Namen von Digest-Algorithmen und dessen Werte der Digest in Bytes (oder ein Ganzzahl-Digest für Legacy-Digest-Algorithmen) sind.
+`Content-Digest` beschreibt ein [RFC8941-Wörterbuch](https://www.rfc-editor.org/rfc/rfc8941#section-3.2), wobei seine Schlüssel die Namen der Digest-Algorithmen und seine Werte der Digest in Bytes (oder ein ganzzahliger Digest für ältere Digest-Algorithmen) sind.
> [!NOTE]
-> Im Gegensatz zu früheren Entwürfen der Spezifikation, sind die standard-base64-kodierten Digest-Bytes als Teil der [Wörterbuchsyntax](https://www.rfc-editor.org/rfc/rfc8941#name-byte-sequences) in Doppelpunkte (`:`, ASCII 0x3A) eingeschlossen.
+> Im Gegensatz zu früheren Entwürfen der Spezifikation sind die standardmäßig base64-codierten Digest-Bytes als Teil der [Wörterbuchsyntax](https://www.rfc-editor.org/rfc/rfc8941#name-byte-sequences) in Doppelpunkte (`:`, ASCII 0x3A) eingeschlossen.
```http
Content-Digest: =::, ...
@@ -40,7 +40,7 @@ Content-Digest: =, ..
## Direktiven
-Für zulässige Digest-Algorithmen siehe {{HTTPHeader("Repr-Digest")}}.
+Zulässige Digest-Algorithmen finden Sie unter {{HTTPHeader("Repr-Digest")}}.
## Beispiele
diff --git a/files/de/web/http/headers/content-disposition/index.md b/files/de/web/http/headers/content-disposition/index.md
index 5854870f7..ed65dcb9b 100644
--- a/files/de/web/http/headers/content-disposition/index.md
+++ b/files/de/web/http/headers/content-disposition/index.md
@@ -7,19 +7,19 @@ l10n:
{{HTTPSidebar}}
-In einer regulären HTTP-Antwort ist der **`Content-Disposition`** Antwort-Header ein Header, der angibt, ob der Inhalt _inline_ im Browser angezeigt werden soll, also als Webseite oder als Teil einer Webseite, oder als _Anlage_, also heruntergeladen und lokal gespeichert werden soll.
+In einer regulären HTTP-Antwort ist der **`Content-Disposition`** Antwort-Header ein Header, der angibt, ob der Inhalt _inline_ im Browser angezeigt werden soll, also als Webseite oder als Teil einer Webseite, oder als _Anhang_, der heruntergeladen und lokal gespeichert wird.
-In einem `multipart/form-data` Körper ist der allgemeine HTTP **`Content-Disposition`** Header ein Header, der für jeden Unterabschnitt eines Multipart-Körpers verwendet werden muss, um Informationen über das Feld zu geben, auf das er sich bezieht. Der Unterabschnitt wird durch die _Boundary_ begrenzt, die im {{HTTPHeader("Content-Type")}} Header definiert ist. Wird er auf den Körper selbst angewendet, hat `Content-Disposition` keine Wirkung.
+In einem `multipart/form-data`-Körper ist der HTTP **`Content-Disposition`** allgemeine Header ein Header, der in jedem Teil eines Multipart-Körpers verwendet werden muss, um Informationen über das Feld zu geben, auf das er zutrifft. Der Teil wird durch die _Grenze_ begrenzt, die im {{HTTPHeader("Content-Type")}}-Header definiert ist. Wird er auf den Körper selbst angewendet, hat `Content-Disposition` keine Wirkung.
-Der `Content-Disposition` Header ist im größeren Kontext von MIME-Nachrichten für E-Mails definiert, aber nur ein Teil der möglichen Parameter gilt für HTTP-Formulare und {{HTTPMethod("POST")}} Anfragen. Nur der Wert `form-data`, sowie die optionalen Direktiven `name` und `filename`, können im HTTP-Kontext verwendet werden.
+Der `Content-Disposition`-Header ist im größeren Kontext von MIME-Nachrichten für E-Mails definiert, aber nur eine Teilmenge der möglichen Parameter gilt für HTTP-Formulare und {{HTTPMethod("POST")}}-Anfragen. Nur der Wert `form-data` sowie die optionalen Direktiven `name` und `filename` können im HTTP-Kontext verwendet werden.
-
Headertyp
+
Header-Typ
{{Glossary("Response header")}} (für den Hauptkörper), {{Glossary("Request header")}},
- {{Glossary("Response header")}} (für einen Unterabschnitt eines Multipart-Körpers)
+ {{Glossary("Response header")}} (für einen Teil eines Multipart-Körpers)
@@ -31,11 +31,11 @@ Der **`Content-DPR`** Antwort-Header wird verwendet, um das _Bild_ Gerät-zu-Pix
-Wenn der {{HTTPHeader("DPR")}} Client-Hinweis verwendet wird, um ein Bild auszuwählen, muss der Server `Content-DPR` in der Antwort spezifizieren. Wenn der Wert in `Content-DPR` von dem {{HTTPHeader("DPR")}} Wert in der Anfrage abweicht (d.h. Bild-DPR ist nicht gleich dem Bildschirm-DPR), muss der Client `Content-DPR` zur Bestimmung der inhärenten Bildgröße und zur Skalierung des Bildes verwenden.
+Wenn der {{HTTPHeader("DPR")}} Client-Hint verwendet wird, um ein Bild auszuwählen, muss der Server `Content-DPR` in der Antwort angeben. Wenn der Wert in `Content-DPR` sich von dem {{HTTPHeader("DPR")}} Wert in der Anfrage unterscheidet (d.h. Bild-DPR ist nicht dasselbe wie Bildschirm-DPR), muss der Client `Content-DPR` zur Bestimmung der intrinsischen Bildgröße und zur Skalierung des Bildes verwenden.
Wenn der `Content-DPR` Header mehr als einmal in einer Nachricht erscheint, wird das letzte Vorkommen verwendet.
-> **Note:** `Content-DPR` wurde in der Client-Hinweise-Spezifikation in [draft-ietf-httpbis-client-hints-07](https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-client-hints-07) entfernt. Die [Responsive Image Client Hints](https://wicg.github.io/responsive-image-client-hints/) Spezifikation schlägt vor, diesen Header durch das Spezifizieren von inhärenter Auflösung/Dimensionen in EXIF-Metadaten zu ersetzen.
+> **Note:** `Content-DPR` wurde aus der Client-Hints-Spezifikation in [draft-ietf-httpbis-client-hints-07](https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-client-hints-07) entfernt. Die [Responsive Image Client Hints](https://wicg.github.io/responsive-image-client-hints/) Spezifikation schlägt vor, diesen Header zu ersetzen, indem intrinsische Auflösung/Dimensionen in EXIF-Metadaten angegeben werden.
## Syntax
@@ -46,21 +46,21 @@ Content-DPR:
## Direktiven
- ``
- - : Das Bild-Gerät-zu-Pixel-Verhältnis, berechnet nach der folgenden Formel:
+ - : Das Geräte-zu-Bild-Pixel-Verhältnis, berechnet nach der folgenden Formel:
Content-DPR = _Ausgewählte Bildressourcengröße_ / (_Breite_ / _DPR_)
## Beispiele
-Siehe das [`DPR`](/de/docs/Web/HTTP/Headers/DPR#examples) Header-Beispiel.
+Siehe das Beispiel des [`DPR`](/de/docs/Web/HTTP/Headers/DPR#examples) Headers.
-## Kompatibilität der Browser
+## Browserkompatibilität
{{Compat}}
## Siehe auch
-- [Verbesserung des Datenschutzes und der Entwicklererfahrung mit User-Agent Client-Hinweisen](https://developer.chrome.com/docs/privacy-security/user-agent-client-hints) (developer.chrome.com)
-- Geräte-Client-Hinweise
+- [Verbesserung von Benutzerdatenschutz und Entwicklererfahrung mit User-Agent Client Hints](https://developer.chrome.com/docs/privacy-security/user-agent-client-hints) (developer.chrome.com)
+- Geräte-Client-Hints
- {{HTTPHeader("Device-Memory")}}
- {{HTTPHeader("DPR")}}
@@ -68,4 +68,4 @@ Siehe das [`DPR`](/de/docs/Web/HTTP/Headers/DPR#examples) Header-Beispiel.
- {{HTTPHeader("Width")}}
- {{HTTPHeader("Accept-CH")}}
-- [HTTP-Caching > Vary](/de/docs/Web/HTTP/Caching#vary) und {{HTTPHeader("Vary")}}
+- [HTTP Caching > Vary](/de/docs/Web/HTTP/Caching#vary) und {{HTTPHeader("Vary")}}
diff --git a/files/de/web/http/headers/content-encoding/index.md b/files/de/web/http/headers/content-encoding/index.md
index c0f1b919c..c794fd613 100644
--- a/files/de/web/http/headers/content-encoding/index.md
+++ b/files/de/web/http/headers/content-encoding/index.md
@@ -7,11 +7,16 @@ l10n:
{{HTTPSidebar}}
-Der **`Content-Encoding`** {{Glossary("representation header")}} listet alle Codierungen auf, die auf eine Ressource angewendet wurden, und in welcher Reihenfolge. Dies ermöglicht es dem Empfänger, die Daten zu decodieren, um das Originalformat zu erhalten, das im {{HTTPHeader("Content-Type")}}-Header beschrieben ist. Die Inhaltscodierung wird hauptsächlich verwendet, um Inhalte zu komprimieren, ohne Informationen über den ursprünglichen Medientyp zu verlieren.
+Der **`Content-Encoding`** {{Glossary("representation header")}} listet alle Kodierungen auf, die auf eine Ressource angewendet wurden, und in welcher Reihenfolge sie angewendet wurden.
+Dies ermöglicht es dem Empfänger zu wissen, wie die Daten dekodiert werden müssen, um das im {{HTTPHeader("Content-Type")}} Header beschriebene Originalformat zu erhalten.
+Die Inhaltskodierung wird hauptsächlich verwendet, um Inhalte zu komprimieren, ohne Informationen über den ursprünglichen Medientyp zu verlieren.
-Server werden ermutigt, Daten so weit wie möglich zu komprimieren und sollten Inhaltscodierung verwenden, wo dies angemessen ist. Die Komprimierung eines bereits komprimierten Medientyps wie .zip oder .jpeg ist möglicherweise nicht angemessen, da dies den Inhalt vergrößern kann. Wenn das ursprüngliche Medium bereits in irgendeiner Weise kodiert ist (z.B. eine .zip-Datei), dann würde diese Information nicht im `Content-Encoding`-Header enthalten sein.
+Servern wird empfohlen, Daten so weit wie möglich zu komprimieren und dort, wo es angemessen ist, die Inhaltskodierung zu verwenden.
+Das Komprimieren eines bereits komprimierten Medientyps wie einer .zip- oder .jpeg-Datei ist möglicherweise nicht angemessen, da dies die Größe des Inhalts erhöhen kann.
+Wenn das Originalmedium bereits auf irgendeine Weise kodiert ist (z.B. eine .zip-Datei), dann würde diese Information nicht im `Content-Encoding` Header enthalten sein.
-Wenn ein `Content-Encoding`-Header vorhanden ist, beziehen sich andere Metadaten (z.B. {{HTTPHeader("Content-Length")}}) auf die kodierte Form der Daten und nicht auf die ursprüngliche Ressource, es sei denn, dies wird ausdrücklich angegeben. Die Inhaltscodierung unterscheidet sich von {{HTTPHeader("Transfer-Encoding")}}, da `Transfer-Encoding` festlegt, wie HTTP-Nachrichten selbst über das Netzwerk auf einer [Hop-by-Hop-Basis](/de/docs/Web/HTTP/Headers#hop-by-hop_headers) übertragen werden.
+Wenn ein `Content-Encoding` Header vorhanden ist, beziehen sich andere Metadaten (z.B. {{HTTPHeader("Content-Length")}}) auf die kodierte Form der Daten und nicht auf die ursprüngliche Ressource, es sei denn, es wird ausdrücklich angegeben.
+Die Inhaltskodierung unterscheidet sich von der {{HTTPHeader("Transfer-Encoding")}}, da `Transfer-Encoding` angibt, wie HTTP-Nachrichten selbst über das Netzwerk [hop-by-hop](/de/docs/Web/HTTP/Headers#hop-by-hop_headers) übertragen werden.
@@ -42,27 +47,32 @@ Content-Encoding: deflate, gzip
## Direktiven
- `gzip`
- - : Ein Format, das das [Lempel-Ziv-Kodierung](https://en.wikipedia.org/wiki/LZ77_and_LZ78#LZ77) (LZ77) mit einem 32-Bit-CRC verwendet. Dies ist das ursprüngliche Format des UNIX _gzip_-Programms. Der HTTP/1.1-Standard empfiehlt außerdem, dass die Server, die diese Inhaltskodierung unterstützen, `x-gzip` als Alias erkennen, aus Gründen der Kompatibilität.
+ - : Ein Format unter Verwendung der [Lempel-Ziv-Codierung](https://en.wikipedia.org/wiki/LZ77_and_LZ78#LZ77) (LZ77) mit einem 32-Bit-CRC.
+ Dies ist das ursprüngliche Format des UNIX _gzip_ Programms.
+ Der HTTP/1.1-Standard empfiehlt auch, dass Server, die diese Inhaltskodierung unterstützen, `x-gzip` als Alias erkennen, aus Kompatibilitätsgründen.
- `compress`
- - : Ein Format, das den [Lempel-Ziv-Welch](https://en.wikipedia.org/wiki/LZW) (LZW)-Algorithmus verwendet. Der Wertname wurde vom UNIX _compress_-Programm übernommen, das diesen Algorithmus implementierte. Wie das compress-Programm, das auf den meisten UNIX-Distributionen verschwunden ist, wird diese Inhaltskodierung heute von vielen Browsern nicht mehr verwendet, teilweise wegen eines Patents (es ist 2003 abgelaufen).
+ - : Ein Format unter Verwendung des [Lempel-Ziv-Welch](https://en.wikipedia.org/wiki/LZW) (LZW) Algorithmus.
+ Der Wertename wurde vom UNIX _compress_ Programm übernommen, das diesen Algorithmus implementierte.
+ Wie das Compress-Programm, das aus den meisten UNIX-Distributionen verschwunden ist, wird diese Inhaltskodierung heute von vielen Browsern nicht mehr verwendet, teilweise wegen eines Patentproblems (es ist 2003 abgelaufen).
- `deflate`
- - : Verwendet die [zlib](https://en.wikipedia.org/wiki/Zlib)-Struktur (definiert in {{rfc(1950)}}) mit dem [deflate](https://en.wikipedia.org/wiki/Deflate)-Kompressionsalgorithmus (definiert in {{rfc(1951)}}).
+ - : Verwendung der [zlib](https://en.wikipedia.org/wiki/Zlib) Struktur (definiert in {{rfc(1950)}}) mit dem [deflate](https://en.wikipedia.org/wiki/Deflate) Kompressionsalgorithmus (definiert in {{rfc(1951)}}).
- `br`
- - : Ein Format, das die {{glossary("Brotli compression","Brotli")}}-Algorithmusstruktur verwendet (definiert in {{rfc(7932)}}).
+ - : Ein Format unter Verwendung der {{glossary("Brotli-Komprimierung","Brotli")}} Algorithmusstruktur (definiert in {{rfc(7932)}}).
- `zstd`
- - : Ein Format, das die {{glossary("Zstandard compression","Zstandard")}}-Algorithmusstruktur verwendet (definiert in {{rfc(8878)}}).
+ - : Ein Format unter Verwendung der {{glossary("Zstandard-Komprimierung","Zstandard")}} Algorithmusstruktur (definiert in {{rfc(8878)}}).
## Beispiele
-### Komprimieren mit gzip
+### Komprimierung mit gzip
-Auf der Clientseite können Sie eine Liste von Komprimierungsschemata angeben, die in einer HTTP-Anfrage gesendet werden. Der {{HTTPHeader("Accept-Encoding")}}-Header wird verwendet, um über die Inhaltskodierung zu verhandeln.
+Auf der Client-Seite können Sie eine Liste von Komprimierungsmethoden angeben, die in einer HTTP-Anfrage gesendet werden.
+Der {{HTTPHeader("Accept-Encoding")}} Header wird für die Verhandlung der Inhaltskodierung verwendet.
```http
Accept-Encoding: gzip, deflate
```
-Der Server antwortet mit dem verwendeten Schema, angezeigt durch den `Content-Encoding`-Antwort-Header.
+Der Server antwortet mit dem verwendeten Schema, das durch den `Content-Encoding` Antwortheader angegeben wird.
```http
Content-Encoding: gzip
diff --git a/files/de/web/http/headers/content-language/index.md b/files/de/web/http/headers/content-language/index.md
index 8e7b193ac..ce4fd71fc 100644
--- a/files/de/web/http/headers/content-language/index.md
+++ b/files/de/web/http/headers/content-language/index.md
@@ -2,16 +2,16 @@
title: Content-Language
slug: Web/HTTP/Headers/Content-Language
l10n:
- sourceCommit: 4d98e1657f9abb1af5c39bbb1f9fdbe47142426f
+ sourceCommit: 5bd9fe2b25c6eee2a14d0406ce7116998fa48c13
---
{{HTTPSidebar}}
-Der **`Content-Language`** {{Glossary("representation header")}} wird verwendet, um **die Sprache(n) zu beschreiben, die für das Publikum bestimmt sind**, damit Benutzer sie gemäß ihrer eigenen bevorzugten Sprache unterscheiden können.
+Der **`Content-Language`** {{Glossary("representation header")}} wird verwendet, um **die für das Publikum vorgesehene(n) Sprache(n) zu beschreiben**, damit Benutzer sie nach ihrer eigenen bevorzugten Sprache unterscheiden können.
-Wenn zum Beispiel "`Content-Language: de-DE`" eingestellt ist, bedeutet das, dass das Dokument für deutschsprachige Personen gedacht ist (es zeigt jedoch nicht an, dass das Dokument auf Deutsch verfasst ist. Es könnte beispielsweise in Englisch geschrieben sein als Teil eines Sprachkurses für Deutschsprachige. Wenn Sie angeben möchten, in welcher Sprache das Dokument verfasst ist, verwenden Sie stattdessen das [`lang`-Attribut](/de/docs/Web/HTML/Global_attributes/lang)).
+Wenn beispielsweise `Content-Language: de-DE` festgelegt ist, bedeutet dies, dass das Dokument für deutschsprachige Benutzer bestimmt ist (es wird jedoch nicht angegeben, dass das Dokument auf Deutsch verfasst ist. Es könnte zum Beispiel auf Englisch als Teil eines Sprachkurses für deutschsprachige Lerner verfasst sein. Wenn Sie angeben möchten, in welcher Sprache das Dokument verfasst ist, verwenden Sie stattdessen das [`lang` Attribut](/de/docs/Web/HTML/Global_attributes/lang)).
-Wenn kein `Content-Language` angegeben ist, ist die Standardeinstellung, dass der Inhalt für alle Sprachgruppen bestimmt ist. Mehrere Sprach-Tags sind ebenfalls möglich, ebenso wie die Anwendung des `Content-Language` Headers auf verschiedene Medientypen und nicht nur auf Textdokumente.
+Wenn kein `Content-Language` angegeben wird, ist die Standardannahme, dass der Inhalt für alle Sprachgruppen bestimmt ist. Mehrere Sprach-Tags sind ebenfalls möglich, ebenso wie die Anwendung des `Content-Language` Headers auf verschiedene Medientypen und nicht nur auf Textdokumente.
@@ -53,16 +53,16 @@ Content-Language: de-DE, en-CA
## Direktiven
- `language-tag`
- - : Mehrere Sprach-Tags werden durch ein Komma getrennt. Jedes Sprach-Tag ist eine Folge von einem oder mehreren nicht case-sensitiven Subtags, die jeweils durch ein Bindestrich-Zeichen ("`-`", `%x2D`) getrennt sind. In den meisten Fällen besteht ein Sprach-Tag aus einem primären Sprach-Subtag, der eine breite Familie verwandter Sprachen identifiziert (z. B. "`en`" = Englisch) und optional gefolgt von einer Reihe von Subtags, die den Bereich dieser Sprache verfeinern oder eingrenzen (z. B. "`en-CA`" = die Variante des Englischen, wie sie in Kanada gesprochen wird).
+ - : Mehrere Sprach-Tags werden durch ein Komma getrennt. Jedes Sprach-Tag ist eine Abfolge von einem oder mehreren fallunempfindlichen Subtags, die jeweils durch ein Bindestrich-Zeichen (`-`) getrennt sind. In den meisten Fällen besteht ein Sprach-Tag aus einem primären Sprach-Subtag, der eine breite Familie verwandter Sprachen identifiziert (z. B. `en` = Englisch) und eventuell gefolgt von einer Reihe von Subtags, die die Sprachreichweite verfeinern oder einschränken (z. B. `en-CA` = die in Kanada gesprochene Variante des Englischen).
> [!NOTE]
-> Sprach-Tags werden formal in [BCP 47](https://www.rfc-editor.org/rfc/bcp/bcp47.txt) definiert, die auf dem [ISO 639](https://en.wikipedia.org/wiki/ISO_639) Standard beruhen (häufig die [ISO 639-1 Code-Liste](https://en.wikipedia.org/wiki/List_of_ISO_639-1_codes)), um [Sprachcodes](https://en.wikipedia.org/wiki/Language_code) zu verwenden.
+> Sprach-Tags sind formell in [BCP 47](https://www.rfc-editor.org/rfc/bcp/bcp47.txt) definiert, die auf dem [ISO 639](https://en.wikipedia.org/wiki/ISO_639) Standard (häufig die [ISO 639-1 Code-Liste](https://en.wikipedia.org/wiki/List_of_ISO_639-1_codes)) für [Sprachcodes](https://en.wikipedia.org/wiki/Language_code) basieren, die verwendet werden sollen.
## Beispiele
-### Angabe der Sprache, in der ein Dokument verfasst ist
+### Die Sprache angeben, in der ein Dokument verfasst ist
-Das globale [`lang`](/de/docs/Web/HTML/Global_attributes/lang)-Attribut wird auf HTML-Elementen verwendet, um die Sprache eines gesamten [HTML](/de/docs/Web/HTML)-Dokuments oder Teile davon anzugeben.
+Das globale [`lang`](/de/docs/Web/HTML/Global_attributes/lang) Attribut wird auf HTML-Elementen verwendet, um die Sprache eines gesamten [HTML](/de/docs/Web/HTML) Dokuments oder Teilen davon anzugeben.
```html
@@ -70,7 +70,7 @@ Das globale [`lang`](/de/docs/Web/HTML/Global_attributes/lang)-Attribut wird auf
```
-Verwenden Sie **nicht** dieses Meta-Element, um die Sprache eines Dokuments anzugeben:
+Verwenden Sie dieses Meta-Element **nicht** auf diese Weise, um die Sprache eines Dokuments anzugeben:
```html example-bad
@@ -79,7 +79,7 @@ Verwenden Sie **nicht** dieses Meta-Element, um die Sprache eines Dokuments anzu
### Angabe einer Zielgruppe für eine Ressource
-Der `Content-Language` Header wird verwendet, um das **beabsichtigte Publikum der Seite** anzugeben und kann darauf hinweisen, dass dies mehr als eine Sprache umfasst.
+Der `Content-Language` Header wird verwendet, um die **beabsichtigte Zielgruppe** einer Seite anzugeben und kann darauf hinweisen, dass diese mehr als eine Sprache umfasst.
```http
Content-Language: de, en
@@ -96,5 +96,5 @@ Content-Language: de, en
## Siehe auch
- {{HTTPHeader("Accept-Language")}}
-- [HTTP headers, meta elements and language information](https://www.w3.org/International/questions/qa-http-and-lang.en)
+- [HTTP-Header, Meta-Elemente und Sprachinformationen](https://www.w3.org/International/questions/qa-http-and-lang.en)
- [HTML `lang` Attribut](/de/docs/Web/HTML/Global_attributes/lang)
diff --git a/files/de/web/http/headers/content-length/index.md b/files/de/web/http/headers/content-length/index.md
index 721538630..9cd9dd2be 100644
--- a/files/de/web/http/headers/content-length/index.md
+++ b/files/de/web/http/headers/content-length/index.md
@@ -7,7 +7,7 @@ l10n:
{{HTTPSidebar}}
-Der **`Content-Length`**-Header gibt die Größe des Nachrichtenkörpers in Bytes an, der an den Empfänger gesendet wird.
+Der **`Content-Length`**-Header gibt die Größe des Nachrichtenkörpers in Bytes an, die an den Empfänger gesendet wird.
@@ -47,7 +47,7 @@ Content-Length:
{{Specifications}}
-## Browser-Kompatibilität
+## Kompatibilität der Browser
{{Compat}}
diff --git a/files/de/web/http/headers/content-location/index.md b/files/de/web/http/headers/content-location/index.md
index 3ec654fd7..809c92d7a 100644
--- a/files/de/web/http/headers/content-location/index.md
+++ b/files/de/web/http/headers/content-location/index.md
@@ -7,9 +7,10 @@ l10n:
{{HTTPSidebar}}
-Der **`Content-Location`**-Header gibt einen alternativen Ort für die zurückgegebenen Daten an. Der Hauptzweck besteht darin, die URL einer Ressource anzugeben, die als Ergebnis der [Inhaltsverhandlung](/de/docs/Web/HTTP/Content_negotiation) übertragen wurde.
+Der **`Content-Location`**-Header gibt einen alternativen Ort für die zurückgegebenen Daten an. Der Hauptzweck besteht darin, die URL einer Ressource anzugeben, die als Ergebnis der [Inhaltsverhandlung](/de/docs/Web/HTTP/Content_negotiation) übertragen wird.
-{{HTTPHeader("Location")}} und `Content-Location` sind unterschiedlich. `Location` gibt die URL einer Weiterleitung an, während `Content-Location` die direkte URL angibt, die verwendet werden soll, um in Zukunft ohne weitere Inhaltsverhandlungen auf die Ressource zuzugreifen. `Location` ist ein Header, der mit der Antwort verknüpft ist, während `Content-Location` mit den zurückgegebenen Daten verknüpft ist. Diese Unterscheidung kann abstrakt erscheinen, wenn man keine [Beispiele](#beispiele) betrachtet.
+{{HTTPHeader("Location")}} und `Content-Location` sind unterschiedlich.
+`Location` gibt die URL einer Umleitung an, während `Content-Location` die direkte URL angibt, die verwendet werden soll, um auf die Ressource zuzugreifen, ohne in Zukunft eine weitere Inhaltsverhandlung durchzuführen. `Location` ist ein Header, der mit der Antwort verbunden ist, während `Content-Location` mit den zurückgegebenen Daten verknüpft ist. Diese Unterscheidung mag ohne [Beispiele](#beispiele) abstrakt erscheinen.
@@ -18,7 +19,7 @@ Der **`Content-Location`**-Header gibt einen alternativen Ort für die zurückge
{{Glossary("Representation header")}}
-
{{Glossary("Verbotener Header-Name")}}
+
{{Glossary("Forbidden header name")}}
nein
@@ -39,25 +40,25 @@ Content-Location:
## Beispiele
-### Anfordern von Daten vom Server in verschiedenen Formaten
+### Daten vom Server in verschiedenen Formaten anfordern
-Angenommen, die API einer Website kann Daten in {{glossary("JSON")}}, {{glossary("XML")}} oder [CSV](https://en.wikipedia.org/wiki/Comma-separated_values)-Formaten zurückgeben. Wenn die URL für ein bestimmtes Dokument bei `https://example.com/documents/foo` liegt, könnte die Website je nach `{{HTTPHeader("Accept")}}`-Header der Anfrage verschiedene URLs für `Content-Location` zurückgeben:
+Angenommen, die API einer Seite kann Daten in {{glossary("JSON")}}, {{glossary("XML")}} oder [CSV]() Formaten zurückgeben. Wenn die URL für ein bestimmtes Dokument unter `https://example.com/documents/foo` liegt, kann die Seite je nach `Accept`-Header der Anforderung unterschiedliche URLs für `Content-Location` zurückgeben:
-| Anforderungs-Header | Antwort-Header |
+| Request-Header | Response-Header |
| ------------------------------------- | --------------------------------------- |
| `Accept: application/json, text/json` | `Content-Location: /documents/foo.json` |
| `Accept: application/xml, text/xml` | `Content-Location: /documents/foo.xml` |
| `Accept: text/plain, text/*` | `Content-Location: /documents/foo.txt` |
-Diese URLs sind Beispiele — die Seite könnte die verschiedenen Dateitypen mit beliebigen URL-Mustern bereitstellen, wie z.B. einem [Query-String-Parameter](/de/docs/Web/API/HTMLAnchorElement/search): `/documents/foo?format=json`, `/documents/foo?format=xml` und so weiter.
+Diese URLs sind Beispiele — die Seite kann die verschiedenen Dateitypen mit beliebigen URL-Mustern bereitstellen, z. B. mit einem [Abfragezeichenfolgen-Parameter](/de/docs/Web/API/HTMLAnchorElement/search): `/documents/foo?format=json`, `/documents/foo?format=xml` usw.
-Dann könnte der Client sich merken, dass die JSON-Version unter dieser speziellen URL verfügbar ist und bei der nächsten Anforderung dieses Dokuments die Inhaltsverhandlung überspringen.
+Dann könnte der Client sich merken, dass die JSON-Version unter dieser bestimmten URL verfügbar ist und die Inhaltsverhandlung beim nächsten Anfordern dieses Dokuments überspringen.
-Der Server könnte auch andere [Inhaltsverhandlung](/de/docs/Web/HTTP/Content_negotiation)-Header in Betracht ziehen, wie {{HTTPHeader("Accept-Language")}}.
+Der Server könnte auch andere Header der [Inhaltsverhandlung](/de/docs/Web/HTTP/Content_negotiation) in Betracht ziehen, wie z. B. {{HTTPHeader("Accept-Language")}}.
-### Verweisen auf ein neues Dokument (HTTP 201 Created)
+### Verweis auf ein neues Dokument (HTTP 201 Created)
-Angenommen, Sie erstellen einen neuen Blogbeitrag über die API einer Website:
+Angenommen, Sie erstellen einen neuen Blogbeitrag über die API einer Seite:
```http
POST /new/post
@@ -66,10 +67,10 @@ Content-Type: text/markdown
# Mein erster Blogbeitrag!
-Ich habe dies über die API von `example.com` gemacht. Ich hoffe, es hat funktioniert.
+Ich habe dies über die API von `example.com` erstellt. Ich hoffe, es hat geklappt.
```
-Die Seite gibt den veröffentlichten Beitrag im Antwortkörper zurück. Der Server gibt an, _wo_ sich der neue Beitrag befindet, mit dem `Content-Location`-Header, wobei er angibt, dass sich dieser Ort auf den Inhalt (den Körper) dieser Antwort bezieht:
+Die Seite gibt den veröffentlichten Beitrag im Antwortkörper zurück. Der Server gibt mit dem `Content-Location`-Header an, _wo_ sich der neue Beitrag befindet, wobei dieser Ort auf den Inhalt (den Körper) dieser Antwort verweist:
```http
HTTP/1.1 201 Created
@@ -78,27 +79,25 @@ Content-Location: /my-first-blog-post
# Mein erster Blogbeitrag
-Ich habe dies über die API von `example.com` gemacht. Ich hoffe, es hat funktioniert.
+Ich habe dies über die API von `example.com` erstellt. Ich hoffe, es hat geklappt.
```
-### Angeben der URL des Ergebnisses einer Transaktion
+### Angabe der URL des Ergebnisses einer Transaktion
-Angenommen, Sie haben ein
-[`
```
-Wenn das Formular übermittelt wird, generiert die Website eine Quittung für die Transaktion. Der Server könnte `Content-Location` verwenden, um die URL dieser Quittung für zukünftigen Zugriff anzugeben.
+Wenn das Formular übermittelt wird, generiert die Seite eine Quittung für die Transaktion. Der Server könnte `Content-Location` verwenden, um die URL dieser Quittung für zukünftigen Zugriff anzugeben.
```http
HTTP/1.1 200 OK
diff --git a/files/de/web/http/headers/content-range/index.md b/files/de/web/http/headers/content-range/index.md
index 4aede8efc..2e6a75ed9 100644
--- a/files/de/web/http/headers/content-range/index.md
+++ b/files/de/web/http/headers/content-range/index.md
@@ -7,12 +7,12 @@ l10n:
{{HTTPSidebar}}
-Der **`Content-Range`** HTTP-Header in der Antwort gibt an, wo in einer vollständigen Nachrichtenstruktur eine Teilnachricht gehört.
+Der **`Content-Range`** Antwort-HTTP-Header zeigt an, wo in einer vollständigen Nachricht eine Teilnachricht gehört.
-
Headertyp
+
Header-Typ
{{Glossary("Response header")}},
{{Glossary("Content header")}}
@@ -42,13 +42,13 @@ Content-Range: */
## Direktiven
- \
- - : Die Einheit, in der Bereiche spezifiziert sind. Dies ist normalerweise `bytes`.
+ - : Die Einheit, in der Bereiche angegeben werden. Dies ist normalerweise `bytes`.
- \
- - : Eine ganze Zahl in der angegebenen Einheit, die die Startposition des angeforderten Bereichs angibt (nullbasiert und inklusive).
+ - : Eine Ganzzahl in der angegebenen Einheit, die die Startposition (nullbasiert & inklusive) des Anforderungsbereichs angibt.
- \
- - : Eine ganze Zahl in der angegebenen Einheit, die die Endposition des angeforderten Bereichs angibt (nullbasiert und inklusive).
+ - : Eine Ganzzahl in der angegebenen Einheit, die die Endposition (nullbasiert & inklusive) des angeforderten Bereichs angibt.
- \
- - : Die Gesamtlänge des Dokuments (oder `'*'`, wenn unbekannt).
+ - : Die Gesamtlänge des Dokuments (oder `'*'`, falls unbekannt).
## Beispiele
diff --git a/files/de/web/http/headers/content-security-policy-report-only/index.md b/files/de/web/http/headers/content-security-policy-report-only/index.md
index 5d719faf5..970773df8 100644
--- a/files/de/web/http/headers/content-security-policy-report-only/index.md
+++ b/files/de/web/http/headers/content-security-policy-report-only/index.md
@@ -7,22 +7,24 @@ l10n:
{{HTTPSidebar}}
-Der HTTP **`Content-Security-Policy-Report-Only`** Antwort-Header ermöglicht es Webentwicklern, CSP-Verletzungsberichte zu senden, um mit Richtlinien durch Überwachung ihrer Auswirkungen zu experimentieren, ohne diese durchzusetzen. Dies ermöglicht es, CSP-Verletzungen schnell während des Testens zu erkennen und zu beheben.
+Der HTTP **`Content-Security-Policy-Report-Only`** Response-Header ermöglicht es Webentwicklern, CSP-Verletzungsberichte zu senden, um Policies zu testen, indem sie deren Auswirkungen überwachen (aber nicht erzwingen).
+Dadurch können CSP-Verletzungen während der Testphase schnell erkannt und behoben werden.
-`Content-Security-Policy-Report-Only` wird auf die gleiche Weise wie {{httpheader("Content-Security-Policy")}} verwendet, aber Verstöße werden nicht durchgesetzt. Die CSP-Direktive {{CSP("report-to")}} muss angegeben werden, damit Berichte gesendet werden: Andernfalls hat die Operation keine Wirkung.
+`Content-Security-Policy-Report-Only` wird auf die gleiche Weise wie {{httpheader("Content-Security-Policy")}} verwendet, aber Verletzungen werden nicht durchgesetzt.
+Die CSP-Direktive {{CSP("report-to")}} muss angegeben werden, damit Berichte gesendet werden: Wenn nicht, hat die Operation keinen Effekt.
-Verstoßberichte werden unter Verwendung der [Reporting API](/de/docs/Web/API/Reporting_API) an Endpunkte gesendet, die im {{HTTPHeader("Reporting-Endpoints")}} HTTP-Antwort-Header definiert und mittels der CSP-Direktive {{CSP("report-to")}} ausgewählt werden.
+Verletzungsberichte werden mit der [Reporting API](/de/docs/Web/API/Reporting_API) an Endpunkte gesendet, die in einem {{HTTPHeader("Reporting-Endpoints")}} HTTP-Response-Header definiert und mit der CSP-Direktive {{CSP("report-to")}} ausgewählt werden.
-Für weitere Informationen lesen Sie bitte unseren Leitfaden zur [Content Security Policy (CSP)](/de/docs/Web/HTTP/CSP).
+Für weitere Informationen lesen Sie unseren [Content Security Policy (CSP)](/de/docs/Web/HTTP/CSP) Leitfaden.
> [!NOTE]
> Der Header kann auch mit der veralteten {{CSP("report-uri")}} Direktive verwendet werden (diese wird durch {{CSP("report-to")}} ersetzt).
-> Die Verwendung und das resultierende Berichtssyntax sind leicht unterschiedlich; siehe das Thema {{CSP("report-uri")}} für mehr Details.
+> Die Nutzung und die resultierende Berichtssyntax sind leicht unterschiedlich; sehen Sie sich das Thema {{CSP("report-uri")}} für weitere Details an.
-
Headertyp
+
Header-Typ
{{Glossary("Response header")}}
@@ -31,7 +33,7 @@ Für weitere Informationen lesen Sie bitte unseren Leitfaden zur [Content Securi
- Dieser Header wird nicht innerhalb eines {{HTMLElement("meta")}} Elementes unterstützt.
+ Dieser Header wird nicht innerhalb eines {{HTMLElement("meta")}} Elements unterstützt.
@@ -45,19 +47,21 @@ Content-Security-Policy-Report-Only: ; ...;
## Direktiven
-Die Direktiven des {{HTTPHeader("Content-Security-Policy")}} Headers können auch auf `Content-Security-Policy-Report-Only` angewendet werden, mit Ausnahme der `sandbox` Direktive, die ignoriert wird.
+Die Direktiven des {{HTTPHeader("Content-Security-Policy")}} Headers können auch auf `Content-Security-Policy-Report-Only` angewendet werden, außer der `sandbox` Direktive, die ignoriert wird.
-Die CSP-Direktive {{CSP("report-to")}} sollte mit diesem Header verwendet werden, sonst hat sie keine Wirkung.
+Die CSP-Direktive {{CSP("report-to")}} sollte mit diesem Header verwendet werden, sonst hat er keinen Effekt.
## Beispiele
-Um die {{CSP("report-to")}} Direktive zu verwenden, müssen Sie zuerst einen entsprechenden Endpunkt mit dem {{httpheader("Reporting-Endpoints")}} HTTP-Antwort-Header definieren. Im folgenden Beispiel definieren wir einen einzelnen Endpunkt namens `csp-endpoint`.
+Um die {{CSP("report-to")}} Direktive zu verwenden, müssen Sie zuerst einen entsprechenden Endpunkt mit dem {{httpheader("Reporting-Endpoints")}} HTTP-Response-Header definieren.
+Im unten stehenden Beispiel definieren wir einen einzelnen Endpunkt namens `csp-endpoint`.
```http
Reporting-Endpoints: csp-endpoint="https://example.com/csp-reports"
```
-Wir könnten dann das Ziel des Berichts mit {{CSP("report-to")}} und {{CSP("report-uri")}} definieren, wie unten gezeigt. Beachten Sie, dass dieser spezielle Bericht ausgelöst würde, wenn die Seite Ressourcen unsicher oder aus Inline-Code lädt.
+Wir könnten dann das Ziel des Berichts mit {{CSP("report-to")}} und {{CSP("report-uri")}} definieren, wie unten gezeigt.
+Beachten Sie, dass dieser spezielle Bericht ausgelöst würde, wenn die Seite unsicher geladene Ressourcen oder Inline-Code hätte.
```http
Content-Security-Policy-Report-Only: default-src https:;
@@ -66,13 +70,13 @@ Content-Security-Policy-Report-Only: default-src https:;
```
> [!NOTE]
-> Die `report-to` Direktive wird gegenüber der veralteten `report-uri` bevorzugt, aber wir deklarieren beide, da `report-to` noch keine vollständige Unterstützung über alle Browser hinweg hat.
+> Die `report-to` Direktive wird gegenüber der veralteten `report-uri` bevorzugt, aber wir deklarieren beide, da `report-to` noch keine vollständige plattformübergreifende Unterstützung hat.
## Spezifikationen
{{Specifications}}
-## Browserkompatibilität
+## Browser-Kompatibilität
{{Compat}}
diff --git a/files/de/web/http/headers/content-security-policy/base-uri/index.md b/files/de/web/http/headers/content-security-policy/base-uri/index.md
index 3b3f62209..40f82c869 100644
--- a/files/de/web/http/headers/content-security-policy/base-uri/index.md
+++ b/files/de/web/http/headers/content-security-policy/base-uri/index.md
@@ -7,7 +7,7 @@ l10n:
{{HTTPSidebar}}
-Die HTTP-Direktive {{HTTPHeader("Content-Security-Policy")}} **`base-uri`** beschränkt die URLs, die im {{HTMLElement("base")}}-Element eines Dokuments verwendet werden können. Ist dieser Wert nicht vorhanden, ist jede URI erlaubt. Fehlt diese Direktive, verwendet der Benutzeragent den Wert im {{HTMLElement("base")}}-Element.
+Die HTTP-{{HTTPHeader("Content-Security-Policy")}}-Direktive **`base-uri`** beschränkt die URLs, die im {{HTMLElement("base")}}-Element eines Dokuments verwendet werden können. Wenn dieser Wert fehlt, ist jede URI erlaubt. Wenn diese Direktive fehlt, verwendet der Benutzeragent den Wert im {{HTMLElement("base")}}-Element.
@@ -20,15 +20,15 @@ Die HTTP-Direktive {{HTTPHeader("Content-Security-Policy")}} **`base-uri`** besc
{{Glossary("Document directive")}}
-
{{CSP("default-src")}} Fallback
-
Nein. Wenn dies nicht festgelegt ist, erlaubt jede URL.
+
{{CSP("default-src")}} Rückfall
+
Nein. Wenn dies nicht festgelegt ist, ist jede URL erlaubt.
## Syntax
-Eine oder mehrere _Quellen_ können für die base-uri-Richtlinie erlaubt werden:
+Für die base-uri-Richtlinie können eine oder mehrere _Quellen_ erlaubt werden:
```http
Content-Security-Policy: base-uri ;
@@ -37,7 +37,7 @@ Content-Security-Policy: base-uri ;
### Quellen
-Diese Direktive verwendet die gleiche [CSP Source Values](/de/docs/Web/HTTP/Headers/Content-Security-Policy/Sources#sources) Syntax für Argumente wie andere CSP-Direktiven. Jedoch sind nur Werte, die URLs entsprechen, für `base-uri` sinnvoll, einschließlich ``, ``, `'self'` und `'none'`.
+Diese Direktive verwendet dieselbe Syntax für [CSP-Quellenwerte](/de/docs/Web/HTTP/Headers/Content-Security-Policy/Sources#sources) für Argumente wie andere CSP-Direktiven. Allerdings machen nur Werte, die URLs entsprechen, für `base-uri` Sinn, einschließlich ``, ``, `'self'` und `'none'`.
## Beispiele
@@ -63,16 +63,15 @@ add_header Content-Security-Policy "base-uri 'self';"
### Verstoßfall
-Da Ihre Domain nicht `example.com` ist, führt ein {{HTMLElement("base")}}-Element mit `href` auf `https://example.com` zu einem CSP-Verstoß.
+Da Ihre Domain nicht `example.com` ist, wird ein {{HTMLElement("base")}}-Element mit `href` auf `https://example.com` gesetzt zu einem CSP-Verstoß führen.
```html example-bad
```
diff --git a/files/de/web/http/headers/content-security-policy/block-all-mixed-content/index.md b/files/de/web/http/headers/content-security-policy/block-all-mixed-content/index.md
index a418504c4..b35238d82 100644
--- a/files/de/web/http/headers/content-security-policy/block-all-mixed-content/index.md
+++ b/files/de/web/http/headers/content-security-policy/block-all-mixed-content/index.md
@@ -8,16 +8,18 @@ l10n:
{{HTTPSidebar}}{{deprecated_header}}
> [!WARNING]
-> Diese Direktive ist in der Spezifikation als veraltet gekennzeichnet.
-> Diese Direktive wurde zuvor verwendet, um das unsichere Abrufen und Anzeigen von "optional blockierbarem" Mixed Content zu verhindern.
-> Inhalte, die nicht blockiert werden, werden jetzt immer zu einer sicheren Verbindung hochgestuft, daher wird diese Direktive nicht mehr benötigt.
+> Diese Richtlinie ist in der Spezifikation als veraltet markiert.
+> Diese Richtlinie wurde früher verwendet, um das unsichere Abrufen und Anzeigen von "optional blockierbaren" Mixed Content zu verhindern.
+> Inhalte, die nicht blockiert werden, werden jetzt immer auf eine sichere Verbindung aufgewertet, sodass diese Richtlinie nicht mehr erforderlich ist.
-Die HTTP {{HTTPHeader("Content-Security-Policy")}} (CSP) **`block-all-mixed-content`**-Direktive verhindert das Laden von Ressourcen über HTTP, wenn die Seite HTTPS verwendet.
+Die HTTP-{{HTTPHeader("Content-Security-Policy")}} (CSP) **`block-all-mixed-content`**-Direktive verhindert das Laden von Assets über HTTP, wenn die Seite HTTPS verwendet.
-Alle [Mixed Content](/de/docs/Web/Security/Mixed_content)-Ressourcenanfragen werden blockiert, einschließlich blockierbarer und hochstufbarer Mixed Content. Dies gilt auch für {{HTMLElement("iframe")}}-Dokumente und stellt sicher, dass die gesamte Seite frei von Mixed Content ist.
+Alle [Mixed Content](/de/docs/Web/Security/Mixed_content)-Ressourcenanfragen werden blockiert, einschließlich sowohl blockierbarer als auch aufwertbarer Mixed Content.
+Dies gilt auch für {{HTMLElement("iframe")}}-Dokumente, um sicherzustellen, dass die gesamte Seite frei von Mixed Content ist.
> [!NOTE]
-> Die {{CSP("upgrade-insecure-requests")}}-Direktive wird vor `block-all-mixed-content` ausgewertet. Wenn erstere gesetzt ist, bewirkt letztere nichts, daher setzen Sie eine der beiden Direktiven – nicht beide, es sei denn, Sie möchten HTTPS bei älteren Browsern erzwingen, die es nach einer Weiterleitung zu HTTP nicht erzwingen.
+> Die {{CSP("upgrade-insecure-requests")}}-Direktive wird vor `block-all-mixed-content` ausgewertet.
+> Wenn die erstgenannte eingestellt ist, bewirkt die letztgenannte nichts, daher sollten Sie eine der beiden Richtlinien setzen – nicht beide, es sei denn, Sie möchten HTTPS in älteren Browsern erzwingen, die es nach einer Umleitung zu HTTP nicht erzwingen.
## Syntax
@@ -33,7 +35,8 @@ Content-Security-Policy: block-all-mixed-content;
```
-Um HTTP-Ressourcen auf einer granulareren Ebene zu verbieten, können Sie auch individuelle Direktiven auf `https:` setzen. Beispiel: Um unsichere HTTP-Bilder zu verbieten:
+Um HTTP-Assets auf einer detaillierteren Ebene zu untersagen, können Sie auch einzelne Direktiven auf `https:` setzen.
+Beispielsweise, um unsichere HTTP-Bilder zu verbieten:
```http
Content-Security-Policy: img-src https:
@@ -41,7 +44,8 @@ Content-Security-Policy: img-src https:
## Spezifikationen
-Nicht Teil einer aktuellen Spezifikation. Früher definiert in der veralteten [Mixed Content Level 1](https://www.w3.org/TR/2015/CR-mixed-content-20150317/#strict-opt-in)-Spezifikation.
+Teil keiner aktuellen Spezifikation.
+Früher in der veralteten [Mixed Content Level 1](https://www.w3.org/TR/2015/CR-mixed-content-20150317/#strict-opt-in)-Spezifikation definiert.
## Browser-Kompatibilität
diff --git a/files/de/web/http/headers/content-security-policy/child-src/index.md b/files/de/web/http/headers/content-security-policy/child-src/index.md
index f507cba6b..758f30920 100644
--- a/files/de/web/http/headers/content-security-policy/child-src/index.md
+++ b/files/de/web/http/headers/content-security-policy/child-src/index.md
@@ -7,7 +7,8 @@ l10n:
{{HTTPSidebar}}
-Die HTTP-{{HTTPHeader("Content-Security-Policy")}} (CSP) **`child-src`** Direktive definiert die gültigen Quellen für [Web Workers](/de/docs/Web/API/Web_Workers_API) und eingebettete Browsing-Kontexte, die mit Elementen wie {{HTMLElement("frame")}} und {{HTMLElement("iframe")}} geladen werden. Für Workers werden nicht konforme Anfragen vom Benutzeragenten als fatale Netzwerkfehler behandelt.
+Die HTTP {{HTTPHeader("Content-Security-Policy")}} (CSP)
+**`child-src`** Direktive definiert die gültigen Quellen für [Web Worker](/de/docs/Web/API/Web_Workers_API) und verschachtelte Browsing-Kontexte, die mit Elementen wie {{HTMLElement("frame")}} und {{HTMLElement("iframe")}} geladen werden. Bei Workern werden nicht konforme Anfragen vom Benutzeragenten als fatale Netzwerkfehler behandelt.
@@ -20,7 +21,7 @@ Die HTTP-{{HTTPHeader("Content-Security-Policy")}} (CSP) **`child-src`** Direkti
{{Glossary("Fetch directive")}}
-
{{CSP("default-src")}} Fallback
+
{{CSP("default-src")}} Rückfall
Ja. Wenn diese Direktive fehlt, sucht der Benutzeragent nach der
default-src Direktive.
@@ -31,7 +32,7 @@ Die HTTP-{{HTTPHeader("Content-Security-Policy")}} (CSP) **`child-src`** Direkti
## Syntax
-Eine oder mehrere Quellen können für die `child-src`-Richtlinie erlaubt werden:
+Es können eine oder mehrere Quellen für die `child-src`-Richtlinie zugelassen werden:
```http
Content-Security-Policy: child-src ;
@@ -40,21 +41,21 @@ Content-Security-Policy: child-src ;
### Quellen
-`` kann einer der in [CSP-Quellenwerte](/de/docs/Web/HTTP/Headers/Content-Security-Policy/Sources#sources) aufgeführten Werte sein.
+`` kann einer der Werte sein, die in [CSP-Quellenwerte](/de/docs/Web/HTTP/Headers/Content-Security-Policy/Sources#sources) aufgelistet sind.
-Beachten Sie, dass dieses gleiche Set von Werten in allen {{Glossary("fetch directive", "fetch directives")}} (und einer [Anzahl anderer Direktiven](/de/docs/Web/HTTP/Headers/Content-Security-Policy/Sources#relevant_directives)) verwendet werden kann.
+Beachten Sie, dass dieses Set von Werten in allen {{Glossary("fetch directive", "fetch directives")}} verwendet werden kann (und in einer [Anzahl anderer Direktiven](/de/docs/Web/HTTP/Headers/Content-Security-Policy/Sources#relevant_directives)).
## Beispiele
### Verletzungsfälle
-Angenommen, dieser CSP-Header:
+Angenommen, folgender CSP-Header ist gegeben:
```http
Content-Security-Policy: child-src https://example.com/
```
-Dieses {{HTMLElement("iframe")}} und dieser Worker werden blockiert und nicht geladen:
+Dieses {{HTMLElement("iframe")}} und der Worker werden blockiert und nicht geladen:
```html
@@ -68,7 +69,7 @@ Dieses {{HTMLElement("iframe")}} und dieser Worker werden blockiert und nicht ge
{{Specifications}}
-## Browserkompatibilität
+## Browser-Kompatibilität
{{Compat}}
diff --git a/files/de/web/http/headers/content-security-policy/connect-src/index.md b/files/de/web/http/headers/content-security-policy/connect-src/index.md
index 29fe5952b..ee4f2f1d3 100644
--- a/files/de/web/http/headers/content-security-policy/connect-src/index.md
+++ b/files/de/web/http/headers/content-security-policy/connect-src/index.md
@@ -7,8 +7,8 @@ l10n:
{{HTTPSidebar}}
-Der HTTP-Header {{HTTPHeader("Content-Security-Policy")}} (CSP)
-**`connect-src`**-Direktive beschränkt die URLs, die über Skript-Schnittstellen geladen werden können. Die eingeschränkten APIs sind:
+Die HTTP-{{HTTPHeader("Content-Security-Policy")}} (CSP)
+**`connect-src`**-Direktive beschränkt die URLs, die mit Skript-Schnittstellen geladen werden können. Die eingeschränkten APIs sind:
- {{HTMLElement("a")}} [`ping`](/de/docs/Web/HTML/Element/a#ping),
- {{domxref("Window/fetch", "fetch()")}},
@@ -17,7 +17,7 @@ Der HTTP-Header {{HTTPHeader("Content-Security-Policy")}} (CSP)
- {{domxref("EventSource")}}, und
- {{domxref("Navigator.sendBeacon()")}}.
-> **Note:** `connect-src 'self'` führt in allen Browsern nicht zu WebSocket-Schemen, weitere Informationen finden Sie in diesem [Problem](https://github.com/w3c/webappsec-csp/issues/7).
+> **Note:** `connect-src 'self'` wird in allen Browsern nicht in Websocket-Schemata aufgelöst, mehr Informationen in diesem [Issue](https://github.com/w3c/webappsec-csp/issues/7).
@@ -26,13 +26,13 @@ Der HTTP-Header {{HTTPHeader("Content-Security-Policy")}} (CSP)
1
-
Direktivtyp
+
Direktiventyp
{{Glossary("Fetch directive")}}
{{CSP("default-src")}} Fallback
- Ja. Wenn diese Direktive nicht vorhanden ist, sucht der User-Agent nach der
+ Ja. Wenn diese Direktive fehlt, sucht der User-Agent nach der
default-src-Direktive.
@@ -41,7 +41,7 @@ Der HTTP-Header {{HTTPHeader("Content-Security-Policy")}} (CSP)
## Syntax
-Eine oder mehrere Quellen können für die connect-src-Richtlinie erlaubt werden:
+Eine oder mehrere Quellen können für die connect-src-Policy erlaubt werden:
```http
Content-Security-Policy: connect-src ;
@@ -50,15 +50,15 @@ Content-Security-Policy: connect-src ;
### Quellen
-`` kann einer der in [CSP-Quellenwerte](/de/docs/Web/HTTP/Headers/Content-Security-Policy/Sources#sources) aufgelisteten Werte sein.
+`` kann einer der Werte sein, die in [CSP-Quellenwerte](/de/docs/Web/HTTP/Headers/Content-Security-Policy/Sources#sources) aufgelistet sind.
-Beachten Sie, dass dieser gleiche Satz von Werten in allen {{Glossary("fetch directive", "fetch directives")}} (und einer [Reihe anderer Direktiven](/de/docs/Web/HTTP/Headers/Content-Security-Policy/Sources#relevant_directives)) verwendet werden kann.
+Beachten Sie, dass dieses gleiche Set von Werten in allen {{Glossary("fetch directive", "fetch directives")}} (und einer [Anzahl anderer Direktiven](/de/docs/Web/HTTP/Headers/Content-Security-Policy/Sources#relevant_directives)) verwendet werden kann.
## Beispiele
-### Verstoßfälle
+### Verletzungsfälle
-Angesichts dieses CSP-Headers:
+Angenommen, dieser CSP-Header:
```http
Content-Security-Policy: connect-src https://example.com/
@@ -90,7 +90,7 @@ Die folgenden Verbindungen werden blockiert und nicht geladen:
{{Specifications}}
-## Kompatibilität mit Browsern
+## Browser-Kompatibilität
{{Compat}}
diff --git a/files/de/web/http/headers/content-security-policy/default-src/index.md b/files/de/web/http/headers/content-security-policy/default-src/index.md
index a38c5ea01..9f059dac3 100644
--- a/files/de/web/http/headers/content-security-policy/default-src/index.md
+++ b/files/de/web/http/headers/content-security-policy/default-src/index.md
@@ -41,7 +41,7 @@ Die HTTP-{{HTTPHeader("Content-Security-Policy")}} (CSP) **`default-src`**-Direk
## Syntax
-Es können eine oder mehrere Quellen für die `default-src`-Richtlinie erlaubt werden:
+Eine oder mehrere Quellen können für die `default-src`-Richtlinie erlaubt werden:
```http
Content-Security-Policy: default-src ;
@@ -50,7 +50,7 @@ Content-Security-Policy: default-src ;
### Quellen
-`` kann jeder der in [CSP-Quellenwerte](/de/docs/Web/HTTP/Headers/Content-Security-Policy/Sources#sources) aufgeführten Werte sein.
+`` kann einer der Werte sein, die in [CSP-Quellenwerte](/de/docs/Web/HTTP/Headers/Content-Security-Policy/Sources#sources) aufgeführt sind.
Beachten Sie, dass dieses gleiche Set von Werten in allen {{Glossary("fetch directive", "fetch directives")}} (und einer [Anzahl anderer Direktiven](/de/docs/Web/HTTP/Headers/Content-Security-Policy/Sources#relevant_directives)) verwendet werden kann.
@@ -64,7 +64,7 @@ Wenn andere Direktiven angegeben sind, beeinflusst `default-src` diese nicht. De
Content-Security-Policy: default-src 'self'; script-src https://example.com
```
-ist dasselbe wie:
+entspricht:
```http
Content-Security-Policy: connect-src 'self';
@@ -79,15 +79,15 @@ Content-Security-Policy: connect-src 'self';
worker-src 'self'
```
-### Firefox-Problem mit `default-src: none` SVG Sprite-Blockierung
+### Firefox `default-src: none` SVG-Sprite-Blockierungsproblem
-CSP-Richtlinien empfehlen oft, mit `default-src 'none'` zu beginnen, um das Laden von Ressourcen zu blockieren, und dann weitere Direktiven hinzuzufügen, um die Richtlinie zu erweitern, sodass nur die benötigten Ressourcen geladen werden. Zum Beispiel, um das Laden von Bildern nur aus derselben Quelle zu erlauben:
+CSP-Richtlinien empfehlen oft, mit `default-src 'none'` zu beginnen, um das Laden aller Ressourcen zu sperren, und dann weitere Direktiven hinzuzufügen, um die Richtlinie zu öffnen, sodass Sie nur die Ressourcen laden, die Sie benötigen. Zum Beispiel, um das Laden von Bildern derselben Quelle zu erlauben:
```http
Content-Security-Policy: default-src 'none'; img-src 'self'
```
-Hier gibt es jedoch ein Problem. Wenn Sie SVG-Sprites aus externen Dateien über das [`
```
-Die Version der React-Bibliothek wird sich ändern, wenn Sie die Bibliothek aktualisieren, und `hero.png` wird sich auch ändern, wenn Sie das Bild bearbeiten. Diese sind also schwer im Cache mit `max-age` zu speichern.
+Die Version der React-Bibliothek ändert sich, wenn Sie die Bibliothek aktualisieren, und `hero.png` ändert sich ebenfalls, wenn Sie das Bild bearbeiten. Diese sind also schwierig in einem Cache mit `max-age` zu speichern.
-In einem solchen Fall könnten Sie die Caching-Bedürfnisse adressieren, indem Sie eine spezifische, nummerierte Version der Bibliothek verwenden und den Hash des Bildes in seine URL einschließen.
+In einem solchen Fall könnten Sie den Caching-Anforderungen durch die Verwendung einer spezifischen, nummerierten Version der Bibliothek gerecht werden und den Hash des Bildes in seine URL einfügen.
```html
@@ -383,51 +383,51 @@ In einem solchen Fall könnten Sie die Caching-Bedürfnisse adressieren, indem S
```
-Sie können einen langen `max-age` Wert und `immutable` hinzufügen, weil sich die Inhalte nie ändern werden.
+Sie können einen langen `max-age` Wert und `immutable` hinzufügen, weil der Inhalt sich nie ändern wird.
```http
# /assets/*
Cache-Control: max-age=31536000, immutable
```
-Wenn Sie die Bibliothek aktualisieren oder das Bild bearbeiten, sollten neue Inhalte eine neue URL haben, und Caches werden nicht wiederverwendet. Dies wird als "Cache-Busting" Muster bezeichnet.
+Wenn Sie die Bibliothek aktualisieren oder das Bild bearbeiten, sollte neuer Inhalt eine neue URL haben, und Caches werden nicht wiederverwendet. Das wird als "Cache Busting"-Muster bezeichnet.
-Verwenden Sie `no-cache`, um sicherzustellen, dass die HTML-Antwort selbst nicht gecacht wird. `no-cache` könnte eine Revalidierung verursachen, und der Client erhält korrekt eine neue Version der HTML-Antwort und der statischen Assets.
+Verwenden Sie ein `no-cache`, um sicherzustellen, dass die HTML-Antwort selbst nicht zwischengespeichert wird. `no-cache` könnte eine Neubeurteilung verursachen, und der Client wird korrekt eine neue Version der HTML-Antwort und der statischen Ressourcen erhalten.
```http
# /index.html
Cache-Control: no-cache
```
-Hinweis: Wenn `index.html` unter Basic Authentifizierung oder Digest Authentifizierung steht, werden Dateien unter `/assets` nicht im gemeinsamen Cache gespeichert. Wenn `/assets/`-Dateien geeignet sind, im gemeinsamen Cache gespeichert zu werden, benötigen Sie zusätzlich eines von `public`, `s-maxage` oder `must-revalidate`.
+Hinweis: Wenn `index.html` unter Basis-Authentifizierung oder Digest-Authentifizierung kontrolliert wird, werden Dateien unter `/assets` nicht im gemeinsamen Cache gespeichert. Wenn Dateien unter `/assets/` geeignet sind, im gemeinsamen Cache gespeichert zu werden, benötigen Sie auch eines der `public`, `s-maxage` oder `must-revalidate`.
### Immer aktuelle Inhalte
-Für Inhalte, die dynamisch erzeugt werden oder die statisch sind, aber häufig aktualisiert werden, wollen Sie, dass ein Benutzer immer die aktuellste Version erhält.
+Für Inhalte, die dynamisch generiert werden oder statisch sind, aber häufig aktualisiert werden, möchten Sie, dass ein Benutzer immer die aktuellste Version erhält.
-Wenn Sie kein `Cache-Control` Header hinzufügen, weil die Antwort nicht gecacht werden soll, könnte das zu einem unerwarteten Ergebnis führen. Cache-Speicher dürfen sie heuristisch cachen — also wenn Sie irgendwelche Anforderungen an das Caching haben, sollten Sie diese immer ausdrücklich im `Cache-Control` Header angeben.
+Wenn Sie keinen `Cache-Control` Header hinzufügen, weil die Antwort nicht zwischengespeichert werden soll, könnte das zu einem unerwarteten Ergebnis führen. Der Cache-Speicher darf dies heuristisch zwischenspeichern — wenn Sie also Anforderungen an das Caching haben, sollten Sie sie immer explizit in dem `Cache-Control` Header angeben.
-Das Hinzufügen von `no-cache` zur Antwort verursacht eine Revalidierung beim Server, sodass Sie jedes Mal eine [frische](/de/docs/Web/HTTP/Caching#fresh_and_stale_based_on_age) Antwort servieren — oder wenn der Client bereits eine neue hat, einfach mit `304 Not Modified` antworten.
+Das Hinzufügen von `no-cache` zur Antwort verursacht eine Neubeurteilung mit dem Server, sodass Sie jedes Mal eine [frische](/de/docs/Web/HTTP/Caching#fresh_and_stale_based_on_age) Antwort bereitstellen können — oder wenn der Client bereits eine neue hat, einfach `304 Not Modified` antworten.
```http
Cache-Control: no-cache
```
-Die meisten HTTP/1.0 Caches unterstützen die `no-cache` Direktiven nicht, daher wurde historisch `max-age=0` als Umgehungslösung verwendet. Aber nur `max-age=0` könnte dazu führen, dass eine [veraltete Antwort](/de/docs/Web/HTTP/Caching#fresh_and_stale_based_on_age) wiederverwendet wird, wenn Caches vom Ursprungsserver getrennt sind. `must-revalidate` behandelt das. Deshalb ist das folgende Beispiel gleichbedeutend mit `no-cache`.
+Die meisten HTTP/1.0-Caches unterstützen keine `no-cache` Direktiven, daher wurde historisch `max-age=0` als Workaround verwendet. Aber nur `max-age=0` könnte eine [veraltete Antwort](/de/docs/Web/HTTP/Caching#fresh_and_stale_based_on_age) verursachen, die wiederverwendet wird, wenn Caches vom Ursprungsserver getrennt sind. `must-revalidate` adressiert dies. Daher ist das folgende Beispiel gleichwertig zu `no-cache`.
```http
Cache-Control: max-age=0, must-revalidate
```
-Aber jetzt können Sie einfach `no-cache` verwenden.
+Aber im Moment können Sie einfach `no-cache` verwenden.
### Löschen eines bereits gespeicherten Caches
Leider gibt es keine Cache-Direktiven zum Löschen bereits gespeicherter Antworten aus Caches.
-Stellen Sie sich vor, dass Clients/Caches eine [frische](/de/docs/Web/HTTP/Caching#fresh_and_stale_based_on_age) Antwort für einen Pfad speichern, ohne dass eine Anfrage an den Server erfolgt. Es gibt nichts, was ein Server für diesen Pfad tun könnte.
+Stellen Sie sich vor, dass Clients/Caches eine [frische](/de/docs/Web/HTTP/Caching#fresh_and_stale_based_on_age) Antwort für einen Pfad speichern, ohne Anfrageflug zum Server. Es gibt nichts, was ein Server für diesen Pfad tun könnte.
-Alternativ kann `Clear-Site-Data` einen Browser-Cache für eine Site löschen. Aber Vorsicht: Das löscht jede gespeicherte Antwort für eine Seite — und nur in Browsern, nicht für einen gemeinsamen Cache.
+Alternativ kann `Clear-Site-Data` einen Browser-Cache für eine Seite löschen. Aber seien Sie vorsichtig: Dies löscht jede gespeicherte Antwort für eine Seite — und nur in Browsern, nicht für einen gemeinsamen Cache.
## Spezifikationen
@@ -440,8 +440,8 @@ Alternativ kann `Clear-Site-Data` einen Browser-Cache für eine Site löschen. A
## Siehe auch
- [HTTP-Caching](/de/docs/Web/HTTP/Caching)
-- [Caching-Tutorial für Webautoren und Webmaster](https://www.mnot.net/cache_docs/)
-- [Caching Best Practices & Max-Age Gotchas](https://jakearchibald.com/2016/caching-best-practices/)
+- [Caching-Tutorial für Web-Autoren und Webmaster](https://www.mnot.net/cache_docs/)
+- [Caching Best Practices & max-age Stolperfallen](https://jakearchibald.com/2016/caching-best-practices/)
- [Cache-Control für Zivilisten](https://csswizardry.com/2019/03/cache-control-for-civilians/)
- [RFC 9111 – HTTP Caching](https://httpwg.org/specs/rfc9111.html)
- [RFC 5861 – HTTP Cache-Control Erweiterungen für veraltete Inhalte](https://httpwg.org/specs/rfc5861.html)
diff --git a/files/de/web/http/headers/clear-site-data/index.md b/files/de/web/http/headers/clear-site-data/index.md
index 0560274d1..240c14c2c 100644
--- a/files/de/web/http/headers/clear-site-data/index.md
+++ b/files/de/web/http/headers/clear-site-data/index.md
@@ -7,12 +7,12 @@ l10n:
{{securecontext_header}}{{HTTPSidebar}}
-Der **`Clear-Site-Data`**-Header entfernt Browserdaten (Cookies, Speicherung, Cache), die mit der anfordernden Website verbunden sind. Er ermöglicht Webentwicklern, mehr Kontrolle über die von einem Client-Browser für ihre Ursprünge gespeicherten Daten zu haben.
+Der **`Clear-Site-Data`**-Header löscht Browsing-Daten (Cookies, Speicher, Cache), die mit der anfordernden Website verbunden sind. Er ermöglicht es Webentwicklern, mehr Kontrolle über die vom Client-Browser für ihre Ursprünge gespeicherten Daten zu haben.