initial commit

50 files changed, 5033 insertions, 0 deletions

diff --git a/files/de/web/http/basics_of_http/identifying_resources_on_the_web/index.html b/files/de/web/http/basics_of_http/identifying_resources_on_the_web/index.html
new file mode 100644
index 0000000000..9e435fa016
--- /dev/null
+++ b/files/de/web/http/basics_of_http/identifying_resources_on_the_web/index.html
@@ -0,0 +1,188 @@
+---
+title: Resourcen im Internet identifizieren
+slug: Web/HTTP/Basics_of_HTTP/Identifying_resources_on_the_Web
+tags:
+  - Anfrage
+  - Domain
+  - HTTP
+  - Internet
+  - Pfad
+  - Resourcen
+  - Schema
+  - Syntax
+  - URI
+  - URL
+  - URL Syntax
+  - fragment
+  - port
+translation_of: Web/HTTP/Basics_of_HTTP/Identifying_resources_on_the_Web
+---
+<div>{{HTTPSidebar}}</div>
+
+<p class="summary">Das Ziel einer HTTP Anfrage wird Resource genannt. Deren Eigenschaften ist nicht weiter definiert, sie könnte ein Dokument, ein Photo oder irgendwas anderes sein. Jede Resource ist identifiziert über einen Uniformen Resourcen Identifizierer ({{Glossary("URI")}}), welche überall in HTTP genutzt werden, um Resourcen zu identifizieren.</p>
+
+<p>Die Identität und der Ort von Resourcen im Internet sind meistens gegeben über eine einzelne URL (Uniform Resource Locator, eine Art der URI). Es gibt manchmal Gründe, dass Identitä und Ort nicht von der selben URI gegeben: HTTP benutzt einen spezifischen HTTP header, {{HTTPHeader("Alt-Svc")}} wenn die Resource will, dass der Client sie an einem anderen Ort anfragt.</p>
+
+<h2 id="URLs_und_URNs">URLs und URNs</h2>
+
+<h3 id="URLs">URLs</h3>
+
+<p>Die häufigste Form von URI ist der Uniform Resource Locator ({{Glossary("URL")}}),  welche als Web Adresse bekannt ist.</p>
+
+<pre>https://developer.mozilla.org
+https://developer.mozilla.org/en-US/docs/Learn/
+https://developer.mozilla.org/en-US/search?q=URL</pre>
+
+<p>Jede dieser URLs kann in einen Browser eingegeben werden um mit diesem die assoziierte Seite (auch eine Resource) zu laden.</p>
+
+<p>Eine URL besteht aus verschiedenen Teilen, manche werden benötigt, andere sind optional. Ein komplexeres Beispiel könnte so aussehen:</p>
+
+<pre>http://www.example.com:80/path/to/myfile.html?key1=value1&amp;key2=value2#SomewhereInTheDocument</pre>
+
+<h3 id="URNs">URNs</h3>
+
+<p>Ein Uniform Resource Name (URN) ist eine URI die eine Resource über einen namen in einem Namespace.</p>
+
+<pre>urn:isbn:9780141036144
+urn:ietf:rfc:7230
+</pre>
+
+<p>Die beiden URNs korrespondieren zu</p>
+
+<ul>
+ <li>Dem Buch Nineteen Eighty-Four von George Orwell,</li>
+ <li>Der IETF Spezifikation 7230, Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing.</li>
+</ul>
+
+<h2 id="Syntax_von_Uniform_Resource_Identifiers_URIs">Syntax von Uniform Resource Identifiers (URIs)</h2>
+
+<h3 id="Schema_oder_Protokoll">Schema oder Protokoll</h3>
+
+<dl>
+ <dt><img alt="Protocol" src="https://mdn.mozillademos.org/files/8013/mdn-url-protocol@x2.png" style="height: 70px; width: 440px;"></dt>
+ <dd><code>http://</code> ist das Protokoll. Es gibt an, welches Protokoll der Browser nutzen soll. Normalerweise ist das das HTTP Protokoll oder seine gesicherte version, HTTPS. Das Internet verlangt eines der beiden, aber Browser wissen auch wie andere Protokolle wie mailto: (um einen email Client zu öffnen) oder ftp: (für einen Datentransfer) zu behandeln sind, also sollte man nicht überrascht sein wenn man solche Protokolle sieht. Häufige Schemata sind:</dd>
+</dl>
+
+<table class="standard-table">
+ <thead>
+  <tr>
+   <th scope="col">Schema</th>
+   <th scope="col">Beschreibung</th>
+  </tr>
+ </thead>
+ <tbody>
+  <tr>
+   <td>data</td>
+   <td><a href="/en-US/docs/Web/HTTP/Basics_of_HTTP/Data_URIs">Daten URIs</a></td>
+  </tr>
+  <tr>
+   <td>file</td>
+   <td>Serverspezifische Dateinamen</td>
+  </tr>
+  <tr>
+   <td>ftp</td>
+   <td><a href="/en-US/docs/Glossary/FTP">File Transfer Protocol</a></td>
+  </tr>
+  <tr>
+   <td>http/https</td>
+   <td><a href="/en-US/docs/Glossary/HTTP">Hyper text transfer protocol (Secure)</a></td>
+  </tr>
+  <tr>
+   <td>mailto</td>
+   <td>email Adresse</td>
+  </tr>
+  <tr>
+   <td>ssh</td>
+   <td>Secure shell</td>
+  </tr>
+  <tr>
+   <td>tel</td>
+   <td>Telephon</td>
+  </tr>
+  <tr>
+   <td>urn</td>
+   <td>Uniform Resource Names</td>
+  </tr>
+  <tr>
+   <td>view-source</td>
+   <td>Source Code der Resource</td>
+  </tr>
+  <tr>
+   <td>ws/wss</td>
+   <td>(Verschlüsselte) <a href="/en-US/docs/Web/API/WebSockets_API">WebSocket</a> Verbindungen</td>
+  </tr>
+ </tbody>
+</table>
+
+<h3 id="Authorität">Authorität</h3>
+
+<dl>
+ <dt><img alt="Domaine Name" src="https://mdn.mozillademos.org/files/8015/mdn-url-domain@x2.png" style="height: 70px; width: 440px;"></dt>
+ <dd><code>www.example.com</code> ist der Domain Name oder Authorität die den Namespace verwaltet. Sie gibt an, welcher Server angefragt wird. Alternativ ist es möglich, direkt eine {{Glossary("IP address")}} anzugeben, aber da es weniger angenehm ist, wird es nicht häufig genutzt.</dd>
+</dl>
+
+<h3 id="Port">Port</h3>
+
+<dl>
+ <dt><img alt="Port" src="https://mdn.mozillademos.org/files/8017/mdn-url-port@x2.png" style="height: 70px; width: 440px;"></dt>
+ <dd><code>:80</code> ist der Port in diesem Fall. Er gibt das technologische "Tor" an, über welches die Resource auf dem Server angesprochen wird. Er wird in der Regel weggelassen wenn der Server die Standard Ports für das HTTP (80) oder HTTPS (443) Protokoll nutzt. Andernfalls wird die Portangabe benötigt.</dd>
+</dl>
+
+<h3 id="Pfad">Pfad</h3>
+
+<dl>
+ <dt><img alt="Path to the file" src="https://mdn.mozillademos.org/files/8019/mdn-url-path@x2.png" style="height: 70px; width: 440px;"></dt>
+ <dd><code>/path/to/myfile.html</code> ist der Pfad zu der Resource auf dem Server. Anfangs hat der Pfad einen Dateipfad auf dem Server angegeben, heutzutage ist er aber meist eine Abstraktion, die von dem Server verarbeitet wird</dd>
+</dl>
+
+<h3 id="Anfrage">Anfrage</h3>
+
+<dl>
+ <dt><img alt="Parameters" src="https://mdn.mozillademos.org/files/8021/mdn-url-parameters@x2.png" style="height: 70px; width: 440px;"></dt>
+ <dd><code>?schluessel1=wert1&amp;wśchluessel2=wert2</code> sind extra Parameter die dem Server übergeben werden. Diese Parameter sind eine Liste von Schlüssel/Wert paaren, die mit einem &amp; getrennt werden. Der Server kann diese Parameter nutzen um zusätzliche Sachen zu machen bevor die Resource dem Nutzer übergeben wird. Jeder Server hat eigene Regeln bezüglich Parametern und der einzig sichere Weg diese zu wissen, ist denn Besitzer des Servers zu fragen.</dd>
+</dl>
+
+<h3 id="Fragment">Fragment</h3>
+
+<dl>
+ <dt><img alt="Anchor" src="https://mdn.mozillademos.org/files/8023/mdn-url-anchor@x2.png" style="height: 70px; width: 440px;"></dt>
+ <dd><code>#SomewhereInTheDocument</code> ist ein Anker zu einem anderen Bereich der Resource selber. Ein Anker repräsentiert eine Art "Lesezeichen" innerhalb der Resource, damit der Browser den Inhalt an der Stelle des Ankers anzeigt. In einem HTML document wird der Browser zum Beispiel an die Stelle scrollen, an der der Anker definiert ist; in einem Video oder Audio Document wird der Browser zu der entsprechenden Zeit springen. Das Fragment selber wird allerdings nie zu dem Server gesendet, es wird allein von dem Browser verarbeitet.</dd>
+</dl>
+
+<h2 id="Nutzungshinweise">Nutzungshinweise</h2>
+
+<p>Wenn man URLs in einem {{Glossary("HTML")}} Inhalt nutzt sollte man generell nur ein paar dieser URL Schemata nutzen. Nutzt man Subresourcen — das heißt, Dateien die als Teil eines größeren Dokuments geladen werden —, sollte man nur die HTTP und HTTPS Schemata nutzen. Browser entfernen vermehrt den Support dafür, dass FTP Schema zu nutzen um Subresourcen zu laden, da dies eine Sicherheitslücker darstellt.</p>
+
+<p>FTP ist immernoch akzeptiert auf dem obersten Level (zum Beispiel direkt in der URL Leiste des Browsers eingegeben, oder das Ziel eines Links), wobei manche Browser FTP Inhalte an eine andere Anwendung delegieren.</p>
+
+<h2 id="Examples">Examples</h2>
+
+<pre>https://developer.mozilla.org/en-US/docs/Learn
+tel:+1-816-555-1212
+git@github.com:mdn/browser-compat-data.git
+ftp://example.org/resource.txt
+urn:isbn:9780141036144
+mailto:help@supercyberhelpdesk.info
+</pre>
+
+<h2 id="Spezifikationen">Spezifikationen</h2>
+
+<table class="standard-table">
+ <tbody>
+  <tr>
+   <th scope="col">Specification</th>
+   <th scope="col">Title</th>
+  </tr>
+  <tr>
+   <td>{{RFC("7230", "Uniform Resource Identifiers", "2.7")}}</td>
+   <td>Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="See_also">See also</h2>
+
+<ul>
+ <li><a href="/en-US/docs/Learn/Common_questions/What_is_a_URL">What is a URL?</a></li>
+ <li><a href="http://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml">IANA list of URI schemes</a></li>
+</ul>
diff --git a/files/de/web/http/basics_of_http/index.html b/files/de/web/http/basics_of_http/index.html
new file mode 100644
index 0000000000..237dda5f72
--- /dev/null
+++ b/files/de/web/http/basics_of_http/index.html
@@ -0,0 +1,51 @@
+---
+title: Basics of HTTP
+slug: Web/HTTP/Basics_of_HTTP
+tags:
+  - Guide
+  - HTTP
+  - NeedsTranslation
+  - Overview
+  - TopicStub
+translation_of: Web/HTTP/Basics_of_HTTP
+---
+<div>{{HTTPSidebar}}</div>
+
+<p>HTTP is a pretty extensible protocol. It relies on a few basic concepts like the notion of resources and URIs, a simple structure of messages, and a client-server structure for the communication flow. On top of these basic concepts, numerous extensions have appeared over the years, adding new functionality and new semantics by creating new HTTP methods or headers.</p>
+
+<h2 id="Articles">Articles</h2>
+
+<dl>
+ <dt><a href="/en-US/docs/Web/HTTP/Overview">Overview of HTTP</a></dt>
+ <dd>Describes what HTTP is and its role in the Web architecture, its position in the protocol stack.</dd>
+ <dt><a href="/en-US/docs/Web/HTTP/Basics_of_HTTP/Evolution_of_HTTP">Evolution of HTTP</a></dt>
+ <dd>HTTP was created in the early 1990s and has been extended several times. This article goes through its history and describes HTTP/0.9, HTTP/1.0, HTTP/1.1, and the modern HTTP/2 as well as minor novelties introduced over the years.</dd>
+ <dt><a href="/en-US/docs/Web/HTTP/Basics_of_HTTP/Negotiating)an_HTTP_version">Negotiating an HTTP version</a></dt>
+ <dd>Explains how a client and a server can negotiate a specific HTTP version and eventually upgrade the protocol version used.</dd>
+ <dt><a href="/en-US/docs/Web/HTTP/Resources_and_URIs">Resources and URIs</a></dt>
+ <dd>A brief introduction of the notion of resources, identifiers, and locations on the Web.</dd>
+ <dt><a href="/en-US/docs/Web/HTTP/Basics_of_HTTP/Identifying_resources_on_the_Web">Identifying resources on the Web</a></dt>
+ <dd>Describes how Web resources are referenced and how to locate them.</dd>
+ <dt><a href="/en-US/docs/Web/HTTP/Basics_of_HTTP/Data_URIs">Data URIs</a></dt>
+ <dd>A specific kind of URIs that directly embeds the resource it represents. Data URIs are very convenient, but have some caveats.</dd>
+ <dt><a href="/en-US/docs/Web/HTTP/Basics_of_HTTP/Resource_URLs">Resource URLs</a> {{Non-standard_Inline}}</dt>
+ <dd>Resource URLs, URLs prefixed with the <code>resource:</code> scheme, are used by Firefox and Firefox browser extensions to load resources internally, but some of the information is available to sites the browser connects to as well.</dd>
+ <dt>Separating identity and location of a resource: the Alt-Svc HTTP header</dt>
+ <dd>Most of the time identity and location of a Web resource are shared, this can be changed with the {{HTTPHeader("Alt-Svc")}} header.</dd>
+ <dt><a href="/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types">MIME types</a></dt>
+ <dd>Since HTTP/1.0, different types of content can be transmitted. This article explains how this is done using the {{HTTPHeader("Content-Type")}} header and the MIME standard.</dd>
+ <dt><a href="/en-US/docs/Web/HTTP/Basics_of_HTTP/Choosing_between_www_and_non-www_URLs">Choosing between www and non-www URLs</a></dt>
+ <dd>Advice on using a www-prefixed domain or not, this article explains the consequences of the choice as well as how to make it.</dd>
+ <dt><a href="/en-US/docs/Web/HTTP/Flow_of_an_HTTP_session">Flow of an HTTP session</a></dt>
+ <dd>This fundamental article describes a typical HTTP session: what happens under the hood when you click on a link in your browser…</dd>
+ <dt><a href="/en-US/docs/Web/HTTP/Messages">HTTP Messages</a></dt>
+ <dd>HTTP Messages transmitted during requests or responses have a very clear structure; this introductory article describes this structure, its purpose and its possibilities.</dd>
+ <dt><a href="/en-US/docs/Web/HTTP/Frame and message structure in HTTP_2">Frame and message structure in HTTP/2</a></dt>
+ <dd>HTTP/2 encapsulates and represents HTTP/1.x messages in a binary frame. This article explains the frame structure, its purpose and the way it is encoded.</dd>
+ <dt><a href="/en-US/docs/Web/HTTP/Connection_management_in_HTTP_1.x">Connection management in HTTP/1.x</a></dt>
+ <dd>HTTP/1.1 was the first version of HTTP to support persistent connection and pipelining. This article explains these two concepts.</dd>
+ <dt><a href="/en-US/docs/Web/HTTP/Connection_management_in_HTTP_2">Connection management in HTTP/2</a></dt>
+ <dd>HTTP/2 completely revisited how connections are created and maintained: this article explains how HTTP frames allow multiplexing and solve the 'head-of-line' blocking problem of former HTTP versions.</dd>
+ <dt><a href="/en-US/docs/Web/HTTP/Content_negotiation">Content Negotiation</a></dt>
+ <dd>HTTP introduces a set of headers, starting with <code>Accept-</code> as a way for a browser to announce the format, language, or encoding it prefers. This article explains how this advertisement happens, how the server is expected to react and how it will choose the most adequate response.</dd>
+</dl>
diff --git a/files/de/web/http/caching_faq/index.html b/files/de/web/http/caching_faq/index.html
new file mode 100644
index 0000000000..79aa913713
--- /dev/null
+++ b/files/de/web/http/caching_faq/index.html
@@ -0,0 +1,73 @@
+---
+title: HTTP Caching FAQ
+slug: Web/HTTP/Caching_FAQ
+tags:
+  - Cache
+  - HTTP
+  - Necko
+  - NeedsContent
+  - header
+translation_of: Web/HTTP/Caching
+---
+<h3 id="What_is_cached.3F" name="What_is_cached.3F">Was wird im Cache gespeichert?</h3>
+
+<p>Der Mozilla Cache beinhaltet alle Dokumente, die via <a href="/en/HTTP" title="en/HTTP">HTTP</a> vom Benutzer heruntergeladen wurden. Dies mag sich zunächst widersprüchlich anhören, dieses Verhalten ermöglicht jedoch das Vor- und Zurück-Navigieren, Speichern, sowie die Anzeige des Quelltextes etc. im Browser, ohne dabei zusätzliche Serveranfragen zu benötigen. Somit verbessert es auch die Offline-Nutzung von temporär gespeicherten Inhalten im Cache.</p>
+
+<h3 id="What_about_documents_sent_with_a_Cache-control:_no-cache_header.3F" name="What_about_documents_sent_with_a_Cache-control:_no-cache_header.3F">Was ist mit Dokumenten die mit "Cache-control: no-cache"  in der Kopfzeile (Header) gesendet werden?</h3>
+
+<p>Auch "no-cache" Dokumente werden von uns aufgrund der oben genannten Gründe im Cache gespeichert.</p>
+
+<h3 id="But_don.27t_you_end_up_serving_stale_content.3F" name="But_don.27t_you_end_up_serving_stale_content.3F">Sorgt das nicht dafür, dass abgelaufene Inhalte bereitgestellt werden?</h3>
+
+<p>Nein, denn jedes Dokument, das im Mozilla Cache gespeichert wird, erhält eine Gültigkeitsdauer. Lädt Mozilla dieses Dokument für eine normale Ansicht, wird die Gültigkeit berücksichtigt. Wenn nötig, wird ein aus dem Cache zu ladendes Dokument mit dem Server abgeglichen und gegebenenfalls neu geladen, bevor es dem Benutzer angezeigt wird.</p>
+
+<h3 id="How_are_expiration_times_calculated_.28since_not_every_response_includes_an_Expires_header.29.3F" name="How_are_expiration_times_calculated_.28since_not_every_response_includes_an_Expires_header.29.3F">Wie wird die Gültigkeitsdauer berechnet (da nicht jede Serverantwort eine Gültigkeit in der Kopfzeile enthält)?</h3>
+
+<p>Mozilla strebt danach, <a class="external" href="http://tools.ietf.org/html/rfc2616" title="http://tools.ietf.org/html/rfc2616">RFC 2616</a> zu implementieren (siehe speziell Abschnitt 13 für nähere Informationen). Jede der folgenden Antwort-Kopfzeilen generiert eine stets abgelaufene Gültigkeitsdauer, z.B. "00:00:00 UTC, January 1, 1970":</p>
+
+<pre>Cache-control: no-cache
+Cache-control: no-store
+Pragma: no-cache
+Expires: 0</pre>
+
+<p>Bemerkenswerter Weise sind die Werte <code>Expires: 0</code> und <code>Pragma: no-cache</code> technisch gesehen ungültige Werte in einer Antwort-Kopfzeile. Wenn keine dieser Angaben vorhanden ist, geschieht die Berechnung der Gültigkeitsdauer nach dem Algorithmus, welcher in <a class="external" href="http://tools.ietf.org/html/rfc2616" title="http://tools.ietf.org/html/rfc2616">RFC 2616</a>, Abschnitt 13.2. beschrieben wird. Wir ermitteln das gegenwärtige Alter der Antwort und seine Gültigkeit basierend auf den vorhandenen Informationen.</p>
+
+<p>Das gegenwärtige Alter entspricht für gewöhnlich fast Null, wird jedoch durch eine vorhandene <code>Age</code>-Angabe in der Antwort-Kopfzeile beeinflusst, die z.B. von Proxy Caches angeben wird um die Länge der Dauer anzugeben, die sich ein Dokument bereits in ihrem Cache befindet. Der exakte Algorithmus, der versucht, Fehler bei der Zeitverschiebung zu verhindern, wird in <a class="external" href="http://tools.ietf.org/html/rfc2616" title="http://tools.ietf.org/html/rfc2616">RFC 2616</a>, Abschnitt 13.2.3 beschrieben.</p>
+
+<p>Die Gültigkeit wird basierend auf mehreren Antwort-Kopfzeilen berechnet. Wenn die Kopfzeile <code>Cache-control: max-age=N</code> angegeben ist, entspricht die Gültigkeit des Dokumentes dem Wert N. Ist dieser Wert nicht vorhanden, was mitunter sehr oft der Fall ist, wird nach einer <code>Expires</code>-Angabe in der Kopfzeile gesucht. Existiert diese, ergibt sich die Gültigkeitsdauer aus dem darin enthaltenen Wert abzüglich des in <code>Date</code> enthaltenen Wertes. Sollte sich letztlich keine <code>Expires</code>-Angabe in den Antwort-Kopfzeilen befinden, wird nach einem <code>Last-Modified</code> Wert gesucht. Ist dieser Wert vorhanden, entspricht die Gültigkeitsdauer im Cache dem Wert <code>Date</code> abzüglich des Wertes <code>Last-Modified</code> geteilt durch 10. Dies ist die vereinfachte Darstellung des heuristischen Algorithmus, der in Abschnitt 13.2.4 des <a class="external" href="http://tools.ietf.org/html/rfc2616" title="http://tools.ietf.org/html/rfc2616">RFC 2616</a> vorgeschlagen wird. </p>
+
+<p>Die Gültigkeitsdauer berechnet sich somit folgendermaßen:</p>
+
+<pre>ablaufZeit = reaktionsZeit + neuheitsLebenszeit - aktuellesAlter</pre>
+
+<p>Wobei <code>reaktionsZeit</code> dem Zeitwert entspricht, zu dem der Browser die Antwort erhalten hat.</p>
+
+<h3 id="What_other_factors_influence_revalidation.3F" name="What_other_factors_influence_revalidation.3F">Gibt es weitere Faktoren, welche die Revalidation beinflussen?</h3>
+
+<p>Die Revalidation wird ausgelöst, sobald ein User die Seite neu lädt (z.B. mittels des Neu-Laden-Knopfes). Ebenso wird sie beim normalen browsen ausgelöst, wenn in den Antwort-Kopfzeilen <code>Cache-control: must-revalidate</code> enthalten ist. Ein weiterer Faktor sind die Einstellungen des Cache-Management im Bereich <code>Erweitert-&gt;Netzwerk</code> der Firefox-Einstellungen. Hier kann als Option gewählt werden, dass Dokumente bei jedem Laden neu validiert werden ("Nachfragen, wenn Websites Daten für die Verwendung im Offline-Modus speichern möchten").</p>
+
+<h3 id="How_does_cache_validation_work.3F" name="How_does_cache_validation_work.3F">Wie funktioniert die Cache-Valdiation?</h3>
+
+<p>Sobald die Gültigkeit eines Dokumentes im Cache abgelaufen ist, wird es entweder revalidiert oder gänzlich neu vom Server angefordert. Eine Validation kann nur dann angewendet werden, wenn der Server entweder eine <em>starke Valdiation</em> (strong validation) oder eine <em>schwache Valdiation</em> (weak validation) ermöglicht. Cache-Validatoren werden im Abschnitt 13.3.2 des <a class="external" href="http://tools.ietf.org/html/rfc2616" title="http://tools.ietf.org/html/rfc2616">RFC 2616</a> beschrieben.</p>
+
+<p>Der <code>ETag</code>-Wert in den Antwort-Kopfzeilen ist ein Wert, der nicht für den User Agent einsehbar ist (<em>opaque-to-the-useragent</em>) und als starker Validator genutzt werden kann (strong validator). Ist der <code>ETag</code>-Wert in den Antwort-Kopfzeilen vorhanden, kann der Browser einen <code>If-None-Match</code>-Wert in den Anfrage-Kopfzeilen ausgeben, um das Dokument im Cache zu validieren.</p>
+
+<p>Der <code>Last-Modified</code>-Wert in den Antwort-Kopfzeilen kann als schwacher Validator (weak validator) genutzt werden. Er wird als schwach eingestuft, da er nur eine 1-Sekunden-Lösung ermöglicht. Wenn der <code>Last-Modified</code>-Wert in den Antwort-Kopfzeilen enthalten ist, kann der Browser einen <code>If-Modified-Since</code>-Wert in den Anfrage-Kopfzeilen ausgeben, um das Dokument im Cache zu validieren.</p>
+
+<p>Sobald eine Validierungs-Anfrage gestellt wurde, kann der Server diese entweder ignorieren und mit einem normalen <code><a href="/en/HTTP/HTTP_response_codes#200" title="https://developer.mozilla.org/en/HTTP/HTTP_response_codes#200">200 OK</a></code>-Statuscode antworten, oder aber einen <code><a href="/en/HTTP/HTTP_response_codes#304" title="https://developer.mozilla.org/en/HTTP/HTTP_response_codes#304">304 Not Modified</a></code>-Statuscode zurückgeben um den Browser anzuweisen, die im Cache befindliche Kopie des Dokumentes zu verwenden. Letzere kann ebenfalls Werte in der Antwort-Kopfzeile enthalten, welche die Gültigkeit des Dokumentes im Cache aktualisieren.</p>
+
+<h3 id="What_about....3F" name="What_about....3F">Was ist mit...?</h3>
+
+<p>Ich beabsichtige, diese Dokumentation in Zukunft zu erweitern. Fühlen Sie sich frei, mir eine E-Mail mit Ihren Fragen oder Kommentaren zu schreiben.</p>
+
+<div class="originaldocinfo">
+<h2 id="Original_Document_Information" name="Original_Document_Information">Informationen zum Original-Dokument</h2>
+
+<ul>
+ <li>Autor(en): <a class="link-mailto" href="mailto:darin@meer.net">Darin Fisher</a></li>
+ <li>Zuletzt aktualisiert: 16. Juni 2004</li>
+ <li>Copyright Information: Teile des Inhaltes sind urheberrechtlich durch © 1998–2007 einzelne Mitwirkende von  mozilla.org; Inhalt lizensiert under einer Creative Commons Lizenz | <a class="external" href="http://www.mozilla.org/foundation/licensing/website-content.html">Details</a>.</li>
+</ul>
+</div>
+
+<p> </p>
diff --git a/files/de/web/http/cors/errors/corsdidnotsucceed/index.html b/files/de/web/http/cors/errors/corsdidnotsucceed/index.html
new file mode 100644
index 0000000000..ba44867384
--- /dev/null
+++ b/files/de/web/http/cors/errors/corsdidnotsucceed/index.html
@@ -0,0 +1,34 @@
+---
+title: 'Reason: CORS request did not succeed'
+slug: Web/HTTP/CORS/Errors/CORSDidNotSucceed
+tags:
+  - CORS
+  - CORSDidNotSucceed
+  - Cross-Origin
+  - Fehler
+  - Gründe
+  - HTTP
+  - HTTPS
+  - Konsole
+  - Nachrichten
+  - Sicherheit
+  - troubleshooting
+translation_of: Web/HTTP/CORS/Errors/CORSDidNotSucceed
+---
+<div>{{HTTPSidebar}}</div>
+
+<h2 id="Grund">Grund</h2>
+
+<pre class="syntaxbox">Grund: CORS-Anfrage schlug fehl</pre>
+
+<h2 id="Was_ist_schiefgelaufen">Was ist schiefgelaufen?</h2>
+
+<p>Die {{Glossary("HTTP")}}-Anfrage, die CORS benutzt hat, versagt, weil die HTTP-Verbindung entweder auf Netzwerk- oder Protokoll-Level versagt hat. Der Fehler hat nicht direkt etwas mit CORS zu tun, sondern ist ein unbestimmter fundamentaler Netzwerkfehler.</p>
+
+<h2 id="Siehe_auch">Siehe auch</h2>
+
+<ul>
+ <li><a href="/en-US/docs/Web/HTTP/CORS/Errors">CORS-Fehler</a></li>
+ <li>Glossar: {{Glossary("CORS")}}</li>
+ <li><a href="/en-US/docs/Web/HTTP/CORS">CORS-Einführung</a></li>
+</ul>
diff --git a/files/de/web/http/cors/errors/corsfehlenderallowheaderauspreflight/index.html b/files/de/web/http/cors/errors/corsfehlenderallowheaderauspreflight/index.html
new file mode 100644
index 0000000000..d40ac7b5b5
--- /dev/null
+++ b/files/de/web/http/cors/errors/corsfehlenderallowheaderauspreflight/index.html
@@ -0,0 +1,37 @@
+---
+title: >-
+  Grund: fehlendes Token ‘xyz’ in CORS-Kopfzeile 'Access-Control-Allow-Headers'
+  aus dem CORS-Preflight-Kanal
+slug: Web/HTTP/CORS/Errors/CORSFehlenderAllowHeaderAusPreflight
+tags:
+  - CORS
+  - CORSMissingAllowHeaderFromPreflight
+  - Cross-Origin
+  - Fehler
+  - HTTP
+  - HTTPS
+  - Meldungen
+  - Sicherheit
+  - Ursachen
+translation_of: Web/HTTP/CORS/Errors/CORSMissingAllowHeaderFromPreflight
+---
+<div>{{HTTPSidebar}}</div>
+
+<h2 id="Grund">Grund</h2>
+
+<pre class="syntaxbox">Grund: fehlendes Token ‘xyz’ in CORS-Kopfzeile ‘Access-Control-Allow-Headers’ aus dem CORS-Preflight-Kanal</pre>
+
+<h2 id="Was_ist_schiefgelaufen">Was ist schiefgelaufen?</h2>
+
+<p>Der <code>Access-Control-Allow-Headers</code> Header wird vom Server gesendet, damit der Client weiß welche Header er für {{Glossary("CORS")}} Requests unterstützt. Der Wert für <code>Access-Control-Allow-Headers</code> ist eine durch Komma getrennte Liste von Header-Namen, wie z.B. "<code>X-Custom-Information</code>" oder jeder der Standart-Header (aber kein Basic-Header, die immer erlaubt sind).</p>
+
+<p>Dieser Fehler tritt auf, wenn versucht wird einen Preflight auszuführen mit einem Header, der nicht ausdrücklich erlaubt ist, d.h. der nicht im <code>Access-Control-Allow-Headers</code> Header enthalten ist, der vom Server gesendet wird. Um dies zu beheben, muss der Server so angepasst werden, dass er den angegebenen Header zulässt, oder man vermeidet es diesen Header zu verwenden.</p>
+
+<h2 id="Siehe_auch">Siehe auch</h2>
+
+<ul>
+ <li><a href="/en-US/docs/Web/HTTP/CORS/Errors">CORS-Fehler</a></li>
+ <li>Glossar: {{Glossary("CORS")}}</li>
+ <li><a href="/en-US/docs/Web/HTTP/CORS">CORS-Einführung</a></li>
+ <li><a href="/en-US/docs/Web/HTTP/Headers">HTTP Header</a></li>
+</ul>
diff --git a/files/de/web/http/cors/errors/corsfehltquelleerlauben/index.html b/files/de/web/http/cors/errors/corsfehltquelleerlauben/index.html
new file mode 100644
index 0000000000..8ccb987535
--- /dev/null
+++ b/files/de/web/http/cors/errors/corsfehltquelleerlauben/index.html
@@ -0,0 +1,59 @@
+---
+title: >-
+  Grund: CORS header 'AccessGrund: CORS-Kopfzeile 'Access-Control-Allow-Origin'
+  fehlt
+slug: Web/HTTP/CORS/Errors/CORSFehltQuelleErlauben
+tags:
+  - CORS
+  - CORSMissingAllowOrigin
+  - Cross-Origin
+  - Error
+  - Fehler
+  - Gründe
+  - HTTP
+  - HTTPS
+  - Konsole
+  - Nachrichten
+  - Sicherheit
+  - troubleshooting
+translation_of: Web/HTTP/CORS/Errors/CORSMissingAllowOrigin
+---
+<div>{{HTTPSidebar}}</div>
+
+<h2 id="Grund">Grund</h2>
+
+<pre class="syntaxbox"> <span class="message-body-wrapper"><span class="message-flex-body"><span class="devtools-monospace message-body">Grund: CORS-Kopfzeile 'Access-Control-Allow-Origin' fehlt</span></span></span></pre>
+
+<h2 id="Was_ist_schief_gelaufen">Was ist schief gelaufen?</h2>
+
+<p>Der Antwort auf die {{Glossary("CORS")}}-Anfrage fehlt der benötigte {{HTTPHeader("Access-Control-Allow-Origin")}}-Header, welcher verwendet wird, um herauszufinden, ob die Ressource vom Inhalt, der im momentanen Origin arbeitet, verwendet werden kann oder nicht.</p>
+
+<p>Wenn der Server unter Ihrer Kontrolle steht, fügen Sie die Quelle der anfragenden Seite zu der Liste der Domains hinzu, die Zugriff haben, indem Sie Sie zum Header-Wert <code>Access-Control-Allow-Origin</code> ergänzen.</p>
+
+<p>Um zum Beispiel einer Seite unter https://amazing.site zu erlauben, auf die Ressource mithilfe von CORS zuzugreifen, sollte der Header lauten:</p>
+
+<pre>Access-Control-Allow-Origin: https://amazing.site</pre>
+
+<p>Mithilfe der <code>"*"</code>-Wildcard kann man eine Seite so konfigureren, dass Sie jeder anderen Webseite Zugriff gewährt. Dies sollte man ausschließlich für öffentliche APIs tun. Private APIs sollten niemals <code>"*"</code> verwenden, sondern stattdessen eine spezifische Domain oder eine Liste von Domains. Zudem funktioniert die Wildcard nur für Requests, die mit dem {{htmlattrxref("crossorigin")}}-Attribut, gesetzt auf <code>"anonymous"</code>, erstellt wurden.</p>
+
+<pre>Access-Control-Allow-Origin: *</pre>
+
+<div class="warning">
+<p><strong>Warnung:</strong> Die Wildcard dazu zu benutzen, um allen Websites Zugriff auf eine private API zu geben, ist - aus wohl offensichtlichen Gründen - keine gute Idee.</p>
+</div>
+
+<p>Fügen Sie z.B. in Apache eine Zeile wie die Folgende zur Konfiguration des Servers hinzu (im zugehörigen <code>&lt;Directory&gt;</code>, <code>&lt;Location&gt;</code>, <code>&lt;Files&gt;</code>, oder <code>&lt;VirtualHost&gt;</code>-Abschnitt). Die Konfigurationseinstellungen findet man üblicherweise in einer <code>.conf</code>-Datei (<code>httpd.conf</code> und <code>apache.conf</code> sind übliche Namen dafür), oder in einer <code>.htaccess</code>-Datei.</p>
+
+<pre>Header set Access-Control-Allow-Origin '<em>origin-list</em>'</pre>
+
+<p>Für Nginx lautet der Befehl, um den Header zu setzen:</p>
+
+<pre>add_header 'Access-Control-Allow-Origin' '<em>origin-list</em>'</pre>
+
+<h2 id="Siehe_auch">Siehe auch</h2>
+
+<ul>
+ <li><a href="/en-US/docs/Web/HTTP/CORS/Errors">CORS fehler</a></li>
+ <li>Glossar: {{Glossary("CORS")}}</li>
+ <li><a href="/en-US/docs/Web/HTTP/CORS">CORS-Einführung</a></li>
+</ul>
diff --git a/files/de/web/http/cors/errors/corsrequestnothttp/index.html b/files/de/web/http/cors/errors/corsrequestnothttp/index.html
new file mode 100644
index 0000000000..a3223da49a
--- /dev/null
+++ b/files/de/web/http/cors/errors/corsrequestnothttp/index.html
@@ -0,0 +1,25 @@
+---
+title: 'Ursache: CORS Anfrage nicht HTTP'
+slug: Web/HTTP/CORS/Errors/CORSRequestNotHttp
+translation_of: Web/HTTP/CORS/Errors/CORSRequestNotHttp
+---
+<div>{{HTTPSidebar}}</div>
+
+<h2 id="Ursache">Ursache</h2>
+
+<pre class="syntaxbox">Reason: CORS request not HTTP</pre>
+
+<h2 id="Was_ist_schief_gelaufen">Was ist schief gelaufen?</h2>
+
+<p>{{Glossary("CORS")}} Anfragen (requests) sollten nur das HTTPS URL Schema benutzen, aber die von der Anfrage spezifizierte URL ist von einem anderen Typ. Dies passiert oft, wenn die URL bspw. eine lokale URL, wie eine Datei beschreibt: <code>file:///</code> URL.</p>
+
+<p>Um das Problem zu beheben, stelle sicher, dass Du eine HTTPS URL verwendest, wenn CORS Anfragen involviert sind.</p>
+
+<h2 id="Siehe_auch">Siehe auch:</h2>
+
+<ul>
+ <li><a href="/en-US/docs/Web/HTTP/CORS/Errors">CORS errors</a></li>
+ <li>Glossary: {{Glossary("CORS")}}</li>
+ <li><a href="/en-US/docs/Web/HTTP/CORS">CORS introduction</a></li>
+ <li><a href="/en-US/docs/Learn/Common_questions/What_is_a_URL">What is a URL?</a></li>
+</ul>
diff --git a/files/de/web/http/cors/errors/index.html b/files/de/web/http/cors/errors/index.html
new file mode 100644
index 0000000000..d1dd12dc75
--- /dev/null
+++ b/files/de/web/http/cors/errors/index.html
@@ -0,0 +1,76 @@
+---
+title: CORS errors
+slug: Web/HTTP/CORS/Errors
+tags:
+  - CORS
+  - Errors
+  - HTTP
+  - HTTPS
+  - Messages
+  - NeedsTranslation
+  - Same-origin
+  - Security
+  - TopicStub
+  - console
+  - troubleshooting
+translation_of: Web/HTTP/CORS/Errors
+---
+<div>{{HTTPSidebar}}</div>
+
+<p><span class="seoSummary"><a href="/en-US/docs/Web/HTTP/CORS">Cross-Origin Resource Sharing</a> ({{Glossary("CORS")}}) is a standard that allows a server to relax the <a href="/en-US/docs/Web/Security/Same-origin_policy">same-origin policy</a>. This is used to explicitly allow some cross-origin requests while rejecting others.</span> For example, if a site offers an embeddable service, it may be necessary to relax certain restrictions. Setting up such a CORS configuration isn't necessarily easy and may present some challenges. In these pages, we'll look into some common CORS error messages and how to resolve them.</p>
+
+<p>If the CORS configuration isn't setup correctly, the browser console will present an error like <code>"Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at $somesite"</code> indicating that the request was blocked due to violating the CORS security rules. This might not necessarily be a set-up mistake, though. It's possible that the request is in fact intentionally being disallowed by the user's web application and remote external service. However, If the endpoint is meant to be available, some debugging is needed to succeed.</p>
+
+<h2 id="Identifying_the_issue">Identifying the issue</h2>
+
+<p>To understand the underlying issue with the CORS configuration, you need to find out which request is at fault and why. These steps may help you do so:</p>
+
+<ol>
+ <li>Navigate to the web site or web app in question and open the <a href="/en-US/docs/Tools">Developer Tools</a>.</li>
+ <li>Now try to reproduce the failing transaction and check the <a href="/en-US/docs/Tools/Web_Console">console</a> if you are seeing a CORS violation error message. It will probably look like this:</li>
+</ol>
+
+<p><img alt="Firefox console showing CORS error" src="https://mdn.mozillademos.org/files/16050/cors-error2.png"></p>
+
+<p>The text of the error message will be something similar to the following:</p>
+
+<pre>Cross<span class="message-body-wrapper"><span class="message-flex-body"><span class="devtools-monospace message-body">-Origin Request Blocked: The Same Origin Policy disallows
+reading the remote resource at <em>https://some-url-here</em>. (<em>Reason:
+additional information here</em>).</span></span></span></pre>
+
+<div class="note">
+<p><span class="message-body-wrapper"><span class="message-flex-body"><span class="devtools-monospace message-body"><strong>Note:</strong> For security reasons, specifics about what went wrong with a CORS request <em>are not available to JavaScript code</em>. All the code knows is that an error occurred. The only way to determine what specifically went wrong is to look at the browser's console for details.</span></span></span></p>
+</div>
+
+<h2 id="CORS_error_messages">CORS error messages</h2>
+
+<p>Firefox's console displays messages in its console when requests fail due to CORS. Part of the error text is a "reason" message that provides added insight into what went wrong.  The reason messages are listed below; click the message to open an article explaining the error in more detail and offering possible solutions.</p>
+
+<ul>
+ <li><a href="/en-US/docs/Web/HTTP/CORS/Errors/CORSDisabled">Reason: CORS disabled</a></li>
+ <li><a href="/en-US/docs/Web/HTTP/CORS/Errors/CORSDidNotSucceed">Reason: CORS request did not succeed</a></li>
+ <li><a href="/en-US/docs/Web/HTTP/CORS/Errors/CORSOriginHeaderNotAdded">Reason: CORS header ‘Origin’ cannot be added</a></li>
+ <li><a href="/en-US/docs/Web/HTTP/CORS/Errors/CORSExternalRedirectNotAllowed">Reason: CORS request external redirect not allowed</a></li>
+ <li><a href="/en-US/docs/Web/HTTP/CORS/Errors/CORSRequestNotHttp">Reason: CORS request not http</a></li>
+ <li><a href="/en-US/docs/Web/HTTP/CORS/Errors/CORSMissingAllowOrigin">Reason: CORS header ‘Access-Control-Allow-Origin’ missing</a></li>
+ <li><a href="/en-US/docs/Web/HTTP/CORS/Errors/CORSAllowOriginNotMatchingOrigin">Reason: CORS header ‘Access-Control-Allow-Origin’ does not match ‘xyz’</a></li>
+ <li><a href="/en-US/docs/Web/HTTP/CORS/Errors/CORSNotSupportingCredentials">Reason: Credential is not supported if the CORS header ‘Access-Control-Allow-Origin’ is ‘*’</a></li>
+ <li><a href="/en-US/docs/Web/HTTP/CORS/Errors/CORSMethodNotFound">Reason: Did not find method in CORS header ‘Access-Control-Allow-Methods’</a></li>
+ <li><a href="/en-US/docs/Web/HTTP/CORS/Errors/CORSMissingAllowCredentials">Reason: expected ‘true’ in CORS header ‘Access-Control-Allow-Credentials’</a></li>
+ <li><a href="/en-US/docs/Web/HTTP/CORS/Errors/CORSPreflightDidNotSucceed">Reason: CORS preflight channel did not succeed</a></li>
+ <li><a href="/en-US/docs/Web/HTTP/CORS/Errors/CORSInvalidAllowMethod">Reason: invalid token ‘xyz’ in CORS header ‘Access-Control-Allow-Methods’</a></li>
+ <li><a href="/en-US/docs/Web/HTTP/CORS/Errors/CORSInvalidAllowHeader">Reason: invalid token ‘xyz’ in CORS header ‘Access-Control-Allow-Headers’</a></li>
+ <li><a href="/en-US/docs/Web/HTTP/CORS/Errors/CORSMissingAllowHeaderFromPreflight">Reason: missing token ‘xyz’ in CORS header ‘Access-Control-Allow-Headers’ from CORS preflight channel</a></li>
+ <li><a href="/en-US/docs/Web/HTTP/CORS/Errors/CORSMultipleAllowOriginNotAllowed">Reason: Multiple CORS header ‘Access-Control-Allow-Origin’ not allowed</a></li>
+</ul>
+
+<h2 id="See_also">See also</h2>
+
+<ul>
+ <li>Glossary: {{Glossary("CORS")}}</li>
+ <li><a href="/en-US/docs/Web/HTTP/CORS">CORS introduction</a></li>
+ <li><a href="/en-US/docs/Web/HTTP/Server-Side_Access_Control">Server-side CORS settings</a></li>
+ <li><a href="/en-US/docs/Web/HTML/CORS_enabled_image">CORS enabled image</a></li>
+ <li><a href="/en-US/docs/Web/HTML/CORS_settings_attributes">CORS settings attributes</a></li>
+ <li><a href="https://www.test-cors.org">https://www.test-cors.org</a> – page to test CORS requests</li>
+</ul>
diff --git a/files/de/web/http/cors/index.html b/files/de/web/http/cors/index.html
new file mode 100644
index 0000000000..ff57fe7c88
--- /dev/null
+++ b/files/de/web/http/cors/index.html
@@ -0,0 +1,567 @@
+---
+title: Cross-Origin Resource Sharing (CORS)
+slug: Web/HTTP/CORS
+tags:
+  - AJAX
+  - CORS
+  - Cross-Origin Resource Sharing
+  - Fetch
+  - Fetch API
+  - HTTP
+  - HTTP Access Controls
+  - NeedsTranslation
+  - Same-origin policy
+  - Security
+  - TopicStub
+  - XMLHttpRequest
+  - 'l10n:priority'
+translation_of: Web/HTTP/CORS
+---
+<div>{{HTTPSidebar}}</div>
+
+<p><span class="seoSummary"><strong>Cross-Origin Resource Sharing</strong> ({{Glossary("CORS")}}) ist ein Mechanismus, der zusätzliche {{Glossary("HTTP")}} Header verwendet um einem Browser mitzuteilen, dass er einer Webanwendung, die auf einer anderen Domain(Origin) läuft, die Berechtigung erteilt auf ausgewählte Ressourcen von einem Server eines anderen Ursprungs(Origin) zuzugreifen.</span> Eine Webanwendung stellt eine <strong>cross-origin HTTP-Anfage, </strong>wenn sie<strong> </strong>eine Ressource anfordert, die einen anderen Ursprung(Domain, Protokoll und Port) hat, als ihren eigenen.</p>
+
+<p>Ein Beispiel für cross-origin Anfragen: Der Frontend-JavaScript-Code für eine von <code>http://domain-a.com</code> bereitgestellte Webanwendung verwendet {{domxref("XMLHttpRequest")}} um eine Anfrage an <code>http://api.domain-b.com/data.json</code>zu stellen</p>
+
+<p>Aus Sicherheitsgründen beschränken Browser die aus Skripten heraus initiierten HTTP-Anfragen mit unterschiedlichen Herkunftsbezeichnungen. Beispielsweise folgen XMLHttpRequest und die<a href="/de-DE/docs/Web/API/Fetch_API">Fetch-API</a> der <a href="/en-US/docs/Web/Security/Same-origin_policy">Richtlinie gleichen Ursprungs</a>. Das bedeutet, dass eine Webanwendung, die diese APIs verwendet, nur HTTP-Ressourcen aus der gleichen Herkunft anfordern kann, aus der die Anwendung geladen wurde, es sei denn, die Antwort aus der anderen Herkunft enthält die richtigen CORS-Header.</p>
+
+<p><img alt="" src="https://mdn.mozillademos.org/files/14295/CORS_principle.png" style="height: 305px; width: 440px;"></p>
+
+<p>Der CORS-Mechanismus unterstützt sichere Cross-Origin-Anfragen und Datenübertragungen zwischen Browsern und Webservern. Moderne Browser verwenden CORS in einem API-Container wie <code>XMLHttpRequest</code> oder <a href="/en-US/docs/Web/API/Fetch_API">Fetch</a>, um das Risiko von Cross-Origin-HTTP-Anfragen zu minimieren.</p>
+
+<h2 id="Wer_sollte_diesen_Artikel_lesen">Wer sollte diesen Artikel lesen?</h2>
+
+<p>Wirklich jeder.</p>
+
+<p>Genauer gesagt richtet sich dieser Artikel an Webadministratoren, Server- und Frontend-Entwickler. Moderne Browser handhaben die clientseitigen Komponenten von Cross-Origin Sharing, einschließlich Header und Richtliniendurchsetzung. Dieser neue Standard bedeutet jedoch, dass Server neue Anfrage- und Antwortheader verarbeiten müssen. Ein weiterer Artikel für Server-Entwickler, in dem <a href="/de-US/docs/Web/HTTP/Server-Side_Access_Control">cross-origin sharing aus der Server-Perspektive (mit PHP-Code-Snippets)</a> diskutiert wird, ist eine ergänzende Lektüre.</p>
+
+<h2 id="Welche_Requests_benutzen_CORS">Welche Requests benutzen CORS?</h2>
+
+<p>Der <a class="external" href="https://fetch.spec.whatwg.org/#http-cors-protocol">cross-origin sharing standard</a> wird benutzt um cross-site HTTP Requests für die:</p>
+
+<ul>
+ <li>Invocations of the {{domxref("XMLHttpRequest")}} or <a href="/en-US/docs/Web/API/Fetch_API">Fetch</a> APIs in a cross-site manner, as discussed above.</li>
+ <li>Web Fonts (for cross-domain font usage in <code>@font-face</code> within CSS), <a class="external" href="https://www.w3.org/TR/css-fonts-3/#font-fetching-requirements">so that servers can deploy TrueType fonts that can only be cross-site loaded and used by web sites that are permitted to do so.</a></li>
+ <li><a href="/en-US/docs/Web/API/WebGL_API/Tutorial/Using_textures_in_WebGL">WebGL textures</a>.</li>
+ <li>Images/video frames drawn to a canvas using {{domxref("CanvasRenderingContext2D.drawImage()", "drawImage()")}}.</li>
+</ul>
+
+<p>This article is a general discussion of Cross-Origin Resource Sharing and includes a discussion of the necessary HTTP headers.</p>
+
+<h2 id="Functional_overview">Functional overview</h2>
+
+<p>The Cross-Origin Resource Sharing standard works by adding new <a href="/en-US/docs/Web/HTTP/Headers">HTTP headers</a> that allow servers to describe the set of origins that are permitted to read that information using a web browser. Additionally, for HTTP request methods that can cause side-effects on server's data (in particular, for HTTP methods other than {{HTTPMethod("GET")}}, or for {{HTTPMethod("POST")}} usage with certain <a href="/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types">MIME types</a>), the specification mandates that browsers "preflight" the request, soliciting supported methods from the server with an HTTP {{HTTPMethod("OPTIONS")}} request method, and then, upon "approval" from the server, sending the actual request with the actual HTTP request method. Servers can also notify clients whether "credentials" (including <a href="/en-US/docs/Web/HTTP/Cookies">Cookies</a> and HTTP Authentication data) should be sent with requests.</p>
+
+<p>CORS failures result in errors, but for security reasons, specifics about what went wrong <em>are not available to JavaScript code</em>. All the code knows is that an error occurred. The only way to determine what specifically went wrong is to look at the browser's console for details.</p>
+
+<p>Subsequent sections discuss scenarios, as well as provide a breakdown of the HTTP headers used.</p>
+
+<h2 id="Examples_of_access_control_scenarios">Examples of access control scenarios</h2>
+
+<p>Here, we present three scenarios that illustrate how Cross-Origin Resource Sharing works. All of these examples use the {{domxref("XMLHttpRequest")}} object, which can be used to make cross-site invocations in any supporting browser.</p>
+
+<p>The JavaScript snippets included in these sections (and running instances of the server-code that correctly handles these cross-site requests) can be found "in action" at <a class="external" href="http://arunranga.com/examples/access-control/">http://arunranga.com/examples/access-control/</a>, and will work in browsers that support cross-site <code>XMLHttpRequest</code>.</p>
+
+<p>A discussion of Cross-Origin Resource Sharing from a server perspective (including PHP code snippets) can be found in the <a class="internal" href="/en-US/docs/Web/HTTP/Server-Side_Access_Control">Server-Side Access Control (CORS)</a> article.</p>
+
+<h3 id="Simple_requests">Simple requests</h3>
+
+<p>Some requests don’t trigger a <a href="#Preflighted_requests">CORS preflight</a>. Those are called “simple requests” in this article, though the {{SpecName('Fetch')}} spec (which defines CORS) doesn’t use that term. A request that doesn’t trigger a <a href="#Preflighted_requests">CORS preflight</a>—a so-called “simple request”—is one that meets all the following conditions:</p>
+
+<ul>
+ <li>The only allowed methods are:
+  <ul>
+   <li>{{HTTPMethod("GET")}}</li>
+   <li>{{HTTPMethod("HEAD")}}</li>
+   <li>{{HTTPMethod("POST")}}</li>
+  </ul>
+ </li>
+ <li>Apart from the headers set automatically by the user agent (for example, {{HTTPHeader("Connection")}}, {{HTTPHeader("User-Agent")}}, or <a href="https://fetch.spec.whatwg.org/#forbidden-header-name">any of the other headers with names defined in the Fetch spec as a “forbidden header name”</a>), the only headers which are allowed to be manually set are <a href="https://fetch.spec.whatwg.org/#cors-safelisted-request-header">those which the Fetch spec defines as being a “CORS-safelisted request-header”</a>, which are:
+  <ul>
+   <li>{{HTTPHeader("Accept")}}</li>
+   <li>{{HTTPHeader("Accept-Language")}}</li>
+   <li>{{HTTPHeader("Content-Language")}}</li>
+   <li>{{HTTPHeader("Content-Type")}} (but note the additional requirements below)</li>
+   <li><code><a href="http://httpwg.org/http-extensions/client-hints.html#dpr">DPR</a></code></li>
+   <li>{{HTTPHeader("Downlink")}}</li>
+   <li><code><a href="http://httpwg.org/http-extensions/client-hints.html#save-data">Save-Data</a></code></li>
+   <li><code><a href="http://httpwg.org/http-extensions/client-hints.html#viewport-width">Viewport-Width</a></code></li>
+   <li><code><a href="http://httpwg.org/http-extensions/client-hints.html#width">Width</a></code></li>
+  </ul>
+ </li>
+ <li>The only allowed values for the {{HTTPHeader("Content-Type")}} header are:
+  <ul>
+   <li><code>application/x-www-form-urlencoded</code></li>
+   <li><code>multipart/form-data</code></li>
+   <li><code>text/plain</code></li>
+  </ul>
+ </li>
+ <li>No event listeners are registered on any {{domxref("XMLHttpRequestUpload")}} object used in the request; these are accessed using the {{domxref("XMLHttpRequest.upload")}} property.</li>
+ <li>No {{domxref("ReadableStream")}} object is used in the request.</li>
+</ul>
+
+<div class="note"><strong>Note:</strong> These are the same kinds of cross-site requests that web content can already issue, and no response data is released to the requester unless the server sends an appropriate header. Therefore, sites that prevent cross-site request forgery have nothing new to fear from HTTP access control.</div>
+
+<div class="note"><strong>Note:</strong> WebKit Nightly and Safari Technology Preview place additional restrictions on the values allowed in the {{HTTPHeader("Accept")}}, {{HTTPHeader("Accept-Language")}}, and {{HTTPHeader("Content-Language")}} headers. If any of those headers have ”non-standard” values, WebKit/Safari does not consider the request to meet the conditions for a “simple request”. What WebKit/Safari considers “non-standard” values for those headers is not documented except in the following WebKit bugs: <a href="https://bugs.webkit.org/show_bug.cgi?id=165178" rel="nofollow noreferrer">Require preflight for non-standard CORS-safelisted request headers Accept, Accept-Language, and Content-Language</a>, <a href="https://bugs.webkit.org/show_bug.cgi?id=165566" rel="nofollow noreferrer">Allow commas in Accept, Accept-Language, and Content-Language request headers for simple CORS</a>, and <a href="https://bugs.webkit.org/show_bug.cgi?id=166363" rel="nofollow noreferrer">Switch to a blacklist model for restricted Accept headers in simple CORS requests</a>. No other browsers implement those extra restrictions, because they’re not part of the spec.</div>
+
+<p>For example, suppose web content on domain <code class="plain">http://foo.example</code> wishes to invoke content on domain <code class="plain">http://bar.other</code>. Code of this sort might be used within JavaScript deployed on foo.example:</p>
+
+<pre class="brush: js notranslate" id="line1">var invocation = new XMLHttpRequest();
+var url = 'http://bar.other/resources/public-data/';
+
+function callOtherDomain() {
+  if(invocation) {
+    invocation.open('GET', url, true);
+    invocation.onreadystatechange = handler;
+    invocation.send();
+  }
+}
+</pre>
+
+<p>This will lead to a simple exchange between the client and the server, using CORS headers to handle the privileges:</p>
+
+<p><img alt="" src="https://mdn.mozillademos.org/files/14293/simple_req.png" style="height: 224px; width: 521px;"></p>
+
+<p>Let us look at what the browser will send to the server in this case, and let's see how the server responds:</p>
+
+<pre class="brush: shell;highlight:[10,16] notranslate">GET /resources/public-data/ HTTP/1.1
+Host: bar.other
+User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081130 Minefield/3.1b3pre
+Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
+Accept-Language: en-us,en;q=0.5
+Accept-Encoding: gzip,deflate
+Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
+Connection: keep-alive
+Referer: http://foo.example/examples/access-control/simpleXSInvocation.html
+Origin: http://foo.example
+
+
+HTTP/1.1 200 OK
+Date: Mon, 01 Dec 2008 00:23:53 GMT
+Server: Apache/2.0.61
+Access-Control-Allow-Origin: *
+Keep-Alive: timeout=2, max=100
+Connection: Keep-Alive
+Transfer-Encoding: chunked
+Content-Type: application/xml
+
+[XML Data]
+</pre>
+
+<p>Lines 1 - 10 are headers sent. The main HTTP request header of note here is the {{HTTPHeader("Origin")}} header on line 10 above, which shows that the invocation is coming from content on the domain <code class="plain">http://foo.example</code>.</p>
+
+<p>Lines 13 - 22 show the HTTP response from the server on domain <code class="plain">http://bar.other</code>. In response, the server sends back an {{HTTPHeader("Access-Control-Allow-Origin")}} header, shown above in line 16. The use of the {{HTTPHeader("Origin")}} header and of {{HTTPHeader("Access-Control-Allow-Origin")}} show the access control protocol in its simplest use. In this case, the server responds with a <code>Access-Control-Allow-Origin: *</code> which means that the resource can be accessed by <strong>any</strong> domain in a cross-site manner. If the resource owners at <code class="plain">http://bar.other</code> wished to restrict access to the resource to requests only from <code class="plain">http://foo.example</code>, they would send back:</p>
+
+<p><code class="plain">Access-Control-Allow-Origin: http://foo.example</code></p>
+
+<p>Note that now, no domain other than <code class="plain">http://foo.example</code> (identified by the ORIGIN: header in the request, as in line 10 above) can access the resource in a cross-site manner. The <code>Access-Control-Allow-Origin</code> header should contain the value that was sent in the request's <code>Origin</code> header.</p>
+
+<h3 id="Preflighted_requests">Preflighted requests</h3>
+
+<p>Unlike <a href="#Simple_requests">“simple requests” (discussed above)</a>, "preflighted" requests first send an HTTP request by the {{HTTPMethod("OPTIONS")}} method to the resource on the other domain, in order to determine whether the actual request is safe to send. Cross-site requests are preflighted like this since they may have implications to user data.</p>
+
+<p>In particular, a request is preflighted if <strong>any of the following conditions</strong> is true:</p>
+
+<ul>
+ <li><strong>If</strong> the request uses any of the following methods:
+
+  <ul>
+   <li>{{HTTPMethod("PUT")}}</li>
+   <li>{{HTTPMethod("DELETE")}}</li>
+   <li>{{HTTPMethod("CONNECT")}}</li>
+   <li>{{HTTPMethod("OPTIONS")}}</li>
+   <li>{{HTTPMethod("TRACE")}}</li>
+   <li>{{HTTPMethod("PATCH")}}</li>
+  </ul>
+ </li>
+ <li><strong>Or if</strong>, apart from the headers set automatically by the user agent (for example, {{HTTPHeader("Connection")}}, {{HTTPHeader("User-Agent")}}, or <a href="https://fetch.spec.whatwg.org/#forbidden-header-name">any of the other header with a name defined in the Fetch spec as a “forbidden header name”</a>), the request includes any headers other than <a href="https://fetch.spec.whatwg.org/#cors-safelisted-request-header">those which the Fetch spec defines as being a “CORS-safelisted request-header”</a>, which are the following:
+  <ul>
+   <li>{{HTTPHeader("Accept")}}</li>
+   <li>{{HTTPHeader("Accept-Language")}}</li>
+   <li>{{HTTPHeader("Content-Language")}}</li>
+   <li>{{HTTPHeader("Content-Type")}} (but note the additional requirements below)</li>
+   <li><code><a href="http://httpwg.org/http-extensions/client-hints.html#dpr">DPR</a></code></li>
+   <li>{{HTTPHeader("Downlink")}}</li>
+   <li><code><a href="http://httpwg.org/http-extensions/client-hints.html#save-data">Save-Data</a></code></li>
+   <li><code><a href="http://httpwg.org/http-extensions/client-hints.html#viewport-width">Viewport-Width</a></code></li>
+   <li><code><a href="http://httpwg.org/http-extensions/client-hints.html#width">Width</a></code></li>
+  </ul>
+ </li>
+ <li><strong>Or if</strong> the {{HTTPHeader("Content-Type")}} header has a value other than the following:
+  <ul>
+   <li><code>application/x-www-form-urlencoded</code></li>
+   <li><code>multipart/form-data</code></li>
+   <li><code>text/plain</code></li>
+  </ul>
+ </li>
+ <li><strong>Or if</strong> one or more event listeners are registered on an {{domxref("XMLHttpRequestUpload")}} object used in the request.</li>
+ <li><strong>Or if</strong> a {{domxref("ReadableStream")}} object is used in the request.</li>
+</ul>
+
+<div class="note"><strong>Note:</strong> WebKit Nightly and Safari Technology Preview place additional restrictions on the values allowed in the {{HTTPHeader("Accept")}}, {{HTTPHeader("Accept-Language")}}, and {{HTTPHeader("Content-Language")}} headers. If any of those headers have ”non-standard” values, WebKit/Safari preflights the request. What WebKit/Safari considers “non-standard” values for those headers is not documented except in the following WebKit bugs: <a href="https://bugs.webkit.org/show_bug.cgi?id=165178" rel="nofollow noreferrer">Require preflight for non-standard CORS-safelisted request headers Accept, Accept-Language, and Content-Language</a>, <a href="https://bugs.webkit.org/show_bug.cgi?id=165566" rel="nofollow noreferrer">Allow commas in Accept, Accept-Language, and Content-Language request headers for simple CORS</a>, and <a href="https://bugs.webkit.org/show_bug.cgi?id=166363" rel="nofollow noreferrer">Switch to a blacklist model for restricted Accept headers in simple CORS requests</a>. No other browsers implement those extra restrictions, because they’re not part of the spec.</div>
+
+<p>The following is an example of a request that will be preflighted.</p>
+
+<pre class="brush: js notranslate" id="line1">var invocation = new XMLHttpRequest();
+var url = 'http://bar.other/resources/post-here/';
+var body = '&lt;?xml version="1.0"?&gt;&lt;person&gt;&lt;name&gt;Arun&lt;/name&gt;&lt;/person&gt;';
+
+function callOtherDomain(){
+  if(invocation)
+    {
+      invocation.open('POST', url, true);
+      invocation.setRequestHeader('X-PINGOTHER', 'pingpong');
+      invocation.setRequestHeader('Content-Type', 'application/xml');
+      invocation.onreadystatechange = handler;
+      invocation.send(body);
+    }
+}
+
+......
+</pre>
+
+<p>In the example above, line 3 creates an XML body to send with the <code>POST</code> request in line 8. Also, on line 9, a "customized" (non-standard) HTTP request header is set (<code>X-PINGOTHER: pingpong</code>). Such headers are not part of the HTTP/1.1 protocol, but are generally useful to web applications. Since the request uses a Content-Type of <code>application/xml</code>, and since a custom header is set, this request is preflighted.</p>
+
+<p><img alt="" src="https://mdn.mozillademos.org/files/16753/preflight_correct.png" style="height: 553px; width: 521px;"></p>
+
+<p>(Note: as described below, the actual POST request does not include the Access-Control-Request-* headers; they are needed only for the OPTIONS request.)</p>
+
+<p>Let's take a look at the full exchange between client and server. The first exchange is the <em>preflight request/response</em>:</p>
+
+<pre class="brush: none;highlight:[1,10,11,17-20] notranslate">OPTIONS /resources/post-here/ HTTP/1.1
+Host: bar.other
+User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081130 Minefield/3.1b3pre
+Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
+Accept-Language: en-us,en;q=0.5
+Accept-Encoding: gzip,deflate
+Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
+Connection: keep-alive
+Origin: http://foo.example
+Access-Control-Request-Method: POST
+Access-Control-Request-Headers: X-PINGOTHER, Content-Type
+
+
+HTTP/1.1 200 OK
+Date: Mon, 01 Dec 2008 01:15:39 GMT
+Server: Apache/2.0.61 (Unix)
+Access-Control-Allow-Origin: http://foo.example
+Access-Control-Allow-Methods: POST, GET, OPTIONS
+Access-Control-Allow-Headers: X-PINGOTHER, Content-Type
+Access-Control-Max-Age: 86400
+Vary: Accept-Encoding, Origin
+Content-Encoding: gzip
+Content-Length: 0
+Keep-Alive: timeout=2, max=100
+Connection: Keep-Alive
+Content-Type: text/plain
+</pre>
+
+<p>Once the preflight request is complete, the real request is sent:</p>
+
+<pre class="brush: none; notranslate">POST /resources/post-here/ HTTP/1.1
+Host: bar.other
+User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081130 Minefield/3.1b3pre
+Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
+Accept-Language: en-us,en;q=0.5
+Accept-Encoding: gzip,deflate
+Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
+Connection: keep-alive
+X-PINGOTHER: pingpong
+Content-Type: text/xml; charset=UTF-8
+Referer: http://foo.example/examples/preflightInvocation.html
+Content-Length: 55
+Origin: http://foo.example
+Pragma: no-cache
+Cache-Control: no-cache
+
+&lt;?xml version="1.0"?&gt;&lt;person&gt;&lt;name&gt;Arun&lt;/name&gt;&lt;/person&gt;
+
+
+HTTP/1.1 200 OK
+Date: Mon, 01 Dec 2008 01:15:40 GMT
+Server: Apache/2.0.61 (Unix)
+Access-Control-Allow-Origin: http://foo.example
+Vary: Accept-Encoding, Origin
+Content-Encoding: gzip
+Content-Length: 235
+Keep-Alive: timeout=2, max=99
+Connection: Keep-Alive
+Content-Type: text/plain
+
+[Some GZIP'd payload]
+</pre>
+
+<p>Lines 1 - 12 above represent the preflight request with the {{HTTPMethod("OPTIONS")}} method. The browser determines that it needs to send this based on the request parameters that the JavaScript code snippet above was using, so that the server can respond whether it is acceptable to send the request with the actual request parameters. OPTIONS is an HTTP/1.1 method that is used to determine further information from servers, and is a {{Glossary("safe")}} method, meaning that it can't be used to change the resource. Note that along with the OPTIONS request, two other request headers are sent (lines 10 and 11 respectively):</p>
+
+<pre class="brush: none notranslate">Access-Control-Request-Method: POST
+Access-Control-Request-Headers: X-PINGOTHER, Content-Type
+</pre>
+
+<p>The {{HTTPHeader("Access-Control-Request-Method")}} header notifies the server as part of a preflight request that when the actual request is sent, it will be sent with a <code>POST</code> request method. The {{HTTPHeader("Access-Control-Request-Headers")}} header notifies the server that when the actual request is sent, it will be sent with a <code>X-PINGOTHER</code> and Content-Type custom headers. The server now has an opportunity to determine whether it wishes to accept a request under these circumstances.</p>
+
+<p>Lines 14 - 26 above are the response that the server sends back indicating that the request method (<code>POST</code>) and request headers (<code>X-PINGOTHER</code>) are acceptable. In particular, let's look at lines 17-20:</p>
+
+<pre class="brush: none notranslate">Access-Control-Allow-Origin: http://foo.example
+Access-Control-Allow-Methods: POST, GET
+Access-Control-Allow-Headers: X-PINGOTHER, Content-Type
+Access-Control-Max-Age: 86400</pre>
+
+<p>The server responds with <code>Access-Control-Allow-Methods</code> and says that <code>POST</code> and <code>GET</code> are viable methods to query the resource in question. Note that this header is similar to the {{HTTPHeader("Allow")}} response header, but used strictly within the context of access control.</p>
+
+<p>The server also sends <code>Access-Control-Allow-Headers</code> with a value of "<code>X-PINGOTHER, Content-Type</code>", confirming that these are permitted headers to be used with the actual request. Like <code>Access-Control-Allow-Methods</code>, <code>Access-Control-Allow-Headers</code> is a comma separated list of acceptable headers.</p>
+
+<p>Finally, {{HTTPHeader("Access-Control-Max-Age")}} gives the value in seconds for how long the response to the preflight request can be cached for without sending another preflight request. In this case, 86400 seconds is 24 hours. Note that each browser has a <a href="/en-US/docs/Web/HTTP/Headers/Access-Control-Max-Age">maximum internal value</a> that takes precedence when the <code>Access-Control-Max-Age</code> is greater.</p>
+
+<h4 id="Preflighted_requests_and_redirects">Preflighted requests and redirects</h4>
+
+<p>Not all browsers currently support following redirects after a preflighted request. If a redirect occurs after a preflighted request, some browsers currently will report an error message such as the following.</p>
+
+<blockquote>
+<p>The request was redirected to 'https://example.com/foo', which is disallowed for cross-origin requests that require preflight</p>
+</blockquote>
+
+<blockquote>
+<p>Request requires preflight, which is disallowed to follow cross-origin redirect</p>
+</blockquote>
+
+<p>The CORS protocol originally required that behavior but <a href="https://github.com/whatwg/fetch/commit/0d9a4db8bc02251cc9e391543bb3c1322fb882f2">was subsequently changed to no longer require it</a>. However, not all browsers have implemented the change, and so still exhibit the behavior that was originally required.</p>
+
+<p>So until all browsers catch up with the spec, you may be able to work around this limitation by doing one or both of the following:</p>
+
+<ul>
+ <li>change the server-side behavior to avoid the preflight and/or to avoid the redirect—if you have control over the server the request is being made to</li>
+ <li>change the request such that it is a <a href="#Simple_requests">simple request</a> that doesn’t cause a preflight</li>
+</ul>
+
+<p>But if it’s not possible to make those changes, then another way that may be possible is to this:</p>
+
+<ol>
+ <li>Make a <a href="#Simple_requests">simple request</a> (using {{domxref("Response.url")}} for the Fetch API, or {{domxref("XMLHttpRequest.responseURL")}}) to determine what URL the real preflighted request would end up at.</li>
+ <li>Make another request (the “real” request) using the URL you obtained from <code>Response.url</code> or <code>XMLHttpRequest.responseURL</code> in the first step.</li>
+</ol>
+
+<p>However, if the request is one that triggers a preflight due to the presence of the <code>Authorization</code> header in the request, you won’t be able to work around the limitation using the steps above. And you won’t be able to work around it at all unless you have control over the server the request is being made to.</p>
+
+<h3 id="Requests_with_credentials">Requests with credentials</h3>
+
+<p>The most interesting capability exposed by both {{domxref("XMLHttpRequest")}} or <a href="/en-US/docs/Web/API/Fetch_API">Fetch</a> and CORS is the ability to make "credentialed" requests that are aware of <a href="/en-US/docs/Web/HTTP/Cookies">HTTP cookies</a> and HTTP Authentication information. By default, in cross-site <code>XMLHttpRequest"</code> or <a href="/en-US/docs/Web/API/Fetch_API">Fetch</a> invocations, browsers will <strong>not</strong> send credentials. A specific flag has to be set on the <code>XMLHttpRequest"</code> object or the {{domxref("Request")}} constructor when it is invoked.</p>
+
+<p>In this example, content originally loaded from <code class="plain">http://foo.example</code> makes a simple GET request to a resource on <code class="plain">http://bar.other</code> which sets Cookies. Content on foo.example might contain JavaScript like this:</p>
+
+<pre class="brush: js notranslate" id="line1">var invocation = new XMLHttpRequest();
+var url = 'http://bar.other/resources/credentialed-content/';
+
+function callOtherDomain(){
+  if(invocation) {
+    invocation.open('GET', url, true);
+    invocation.withCredentials = true;
+    invocation.onreadystatechange = handler;
+    invocation.send();
+  }
+}</pre>
+
+<p>Line 7 shows the flag on {{domxref("XMLHttpRequest")}} that has to be set in order to make the invocation with Cookies, namely the <code>withCredentials</code> boolean value. By default, the invocation is made without Cookies. Since this is a simple <code>GET</code> request, it is not preflighted, but the browser will <strong>reject</strong> any response that does not have the {{HTTPHeader("Access-Control-Allow-Credentials")}}<code>: true</code> header, and <strong>not</strong> make the response available to the invoking web content.</p>
+
+<p><img alt="" src="https://mdn.mozillademos.org/files/14291/cred-req.png" style="height: 223px; width: 521px;"></p>
+
+<p>Here is a sample exchange between client and server:</p>
+
+<pre class="brush: none notranslate">GET /resources/access-control-with-credentials/ HTTP/1.1
+Host: bar.other
+User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081130 Minefield/3.1b3pre
+Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
+Accept-Language: en-us,en;q=0.5
+Accept-Encoding: gzip,deflate
+Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
+Connection: keep-alive
+Referer: http://foo.example/examples/credential.html
+Origin: http://foo.example
+Cookie: pageAccess=2
+
+
+HTTP/1.1 200 OK
+Date: Mon, 01 Dec 2008 01:34:52 GMT
+Server: Apache/2.0.61 (Unix) PHP/4.4.7 mod_ssl/2.0.61 OpenSSL/0.9.7e mod_fastcgi/2.4.2 DAV/2 SVN/1.4.2
+X-Powered-By: PHP/5.2.6
+Access-Control-Allow-Origin: http://foo.example
+Access-Control-Allow-Credentials: true
+Cache-Control: no-cache
+Pragma: no-cache
+Set-Cookie: pageAccess=3; expires=Wed, 31-Dec-2008 01:34:53 GMT
+Vary: Accept-Encoding, Origin
+Content-Encoding: gzip
+Content-Length: 106
+Keep-Alive: timeout=2, max=100
+Connection: Keep-Alive
+Content-Type: text/plain
+
+
+[text/plain payload]
+</pre>
+
+<p>Although line 11 contains the Cookie destined for the content on <code class="plain">http://bar.other</code>, if bar.other did not respond with an {{HTTPHeader("Access-Control-Allow-Credentials")}}<code>: true</code> (line 19) the response would be ignored and not made available to web content.</p>
+
+<h4 id="Credentialed_requests_and_wildcards">Credentialed requests and wildcards</h4>
+
+<p>When responding to a credentialed request, the server <strong>must</strong> specify an origin in the value of the <code>Access-Control-Allow-Origin</code> header, instead of specifying the "<code>*</code>" wildcard.</p>
+
+<p>Because the request headers in the above example include a <code>Cookie</code> header, the request would fail if the value of the <code>Access-Control-Allow-Origin</code> header were "*". But it does not fail: Because the value of the <code>Access-Control-Allow-Origin</code> header is "<code class="plain">http://foo.example</code>" (an actual origin) rather than the "<code>*</code>" wildcard, the credential-cognizant content is returned to the invoking web content.</p>
+
+<p>Note that the <code>Set-Cookie</code> response header in the example above also sets a further cookie. In case of failure, an exception—depending on the API used—is raised.</p>
+
+<h4 id="Third-party_cookies">Third-party cookies</h4>
+
+<p>Note that cookies set in CORS responses are subject to normal third-party cookie policies. In the example above, the page is loaded from <code>foo.example</code>, but the cookie on line 22 is sent by <code>bar.other</code>, and would thus not be saved if the user has configured their browser to reject all third-party cookies.</p>
+
+<h2 id="The_HTTP_response_headers">The HTTP response headers</h2>
+
+<p>This section lists the HTTP response headers that servers send back for access control requests as defined by the Cross-Origin Resource Sharing specification. The previous section gives an overview of these in action.</p>
+
+<h3 id="Access-Control-Allow-Origin">Access-Control-Allow-Origin</h3>
+
+<p>A returned resource may have one {{HTTPHeader("Access-Control-Allow-Origin")}} header, with the following syntax:</p>
+
+<pre class="brush: none notranslate">Access-Control-Allow-Origin: &lt;origin&gt; | *
+</pre>
+
+<p><code>Access-Control-Allow-Origin</code> specifies either a single origin, which tells browsers to allow that origin to access the resource; or else — for requests <strong>without</strong> credentials — the "<code>*</code>" wildcard, to tell browsers to allow any origin to access the resource.</p>
+
+<p>For example, to allow code from the origin <code>http://mozilla.org</code> to access the resource, you can specify:</p>
+
+<pre class="brush: none notranslate">Access-Control-Allow-Origin: http://mozilla.org</pre>
+
+<p>If the server specifies a single origin rather than the "<code>*</code>" wildcard, then the server should also include <code>Origin</code> in the {{HTTPHeader("Vary")}} response header — to indicate to clients that server responses will differ based on the value of the {{HTTPHeader("Origin")}} request header.</p>
+
+<h3 id="Access-Control-Expose-Headers">Access-Control-Expose-Headers</h3>
+
+<p>The {{HTTPHeader("Access-Control-Expose-Headers")}} header lets a server whitelist headers that browsers are allowed to access. For example:</p>
+
+<pre class="brush: none notranslate">Access-Control-Expose-Headers: X-My-Custom-Header, X-Another-Custom-Header
+</pre>
+
+<p>This allows the <code>X-My-Custom-Header</code> and <code>X-Another-Custom-Header</code> headers to be exposed to the browser.</p>
+
+<h3 id="Access-Control-Max-Age">Access-Control-Max-Age</h3>
+
+<p>The {{HTTPHeader("Access-Control-Max-Age")}} header indicates how long the results of a preflight request can be cached. For an example of a preflight request, see the above examples.</p>
+
+<pre class="brush: none notranslate">Access-Control-Max-Age: &lt;delta-seconds&gt;
+</pre>
+
+<p>The <code>delta-seconds</code> parameter indicates the number of seconds the results can be cached.</p>
+
+<h3 id="Access-Control-Allow-Credentials">Access-Control-Allow-Credentials</h3>
+
+<p>The {{HTTPHeader("Access-Control-Allow-Credentials")}} header Indicates whether or not the response to the request can be exposed when the <code>credentials</code> flag is true. When used as part of a response to a preflight request, this indicates whether or not the actual request can be made using credentials. Note that simple <code>GET</code> requests are not preflighted, and so if a request is made for a resource with credentials, if this header is not returned with the resource, the response is ignored by the browser and not returned to web content.</p>
+
+<pre class="brush: none notranslate">Access-Control-Allow-Credentials: true
+</pre>
+
+<p><a class="internal" href="#Requests_with_credentials">Credentialed requests</a> are discussed above.</p>
+
+<h3 id="Access-Control-Allow-Methods">Access-Control-Allow-Methods</h3>
+
+<p>The {{HTTPHeader("Access-Control-Allow-Methods")}} header specifies the method or methods allowed when accessing the resource. This is used in response to a preflight request. The conditions under which a request is preflighted are discussed above.</p>
+
+<pre class="brush: none notranslate">Access-Control-Allow-Methods: &lt;method&gt;[, &lt;method&gt;]*
+</pre>
+
+<p>An example of a <a class="internal" href="#Preflighted_requests">preflight request is given above</a>, including an example which sends this header to the browser.</p>
+
+<h3 id="Access-Control-Allow-Headers">Access-Control-Allow-Headers</h3>
+
+<p>The {{HTTPHeader("Access-Control-Allow-Headers")}} header is used in response to a <a class="internal" href="#Preflighted_requests">preflight request</a> to indicate which HTTP headers can be used when making the actual request.</p>
+
+<pre class="brush: none notranslate">Access-Control-Allow-Headers: &lt;field-name&gt;[, &lt;field-name&gt;]*
+</pre>
+
+<h2 id="The_HTTP_request_headers">The HTTP request headers</h2>
+
+<p>This section lists headers that clients may use when issuing HTTP requests in order to make use of the cross-origin sharing feature. Note that these headers are set for you when making invocations to servers. Developers using cross-site {{domxref("XMLHttpRequest")}} capability do not have to set any cross-origin sharing request headers programmatically.</p>
+
+<h3 id="Origin">Origin</h3>
+
+<p>The {{HTTPHeader("Origin")}} header indicates the origin of the cross-site access request or preflight request.</p>
+
+<pre class="brush: none notranslate">Origin: &lt;origin&gt;
+</pre>
+
+<p>The origin is a URI indicating the server from which the request initiated. It does not include any path information, but only the server name.</p>
+
+<div class="note"><strong>Note:</strong> The <code>origin</code> can be the empty string; this is useful, for example, if the source is a <code>data</code> URL.</div>
+
+<p>Note that in any access control request, the {{HTTPHeader("Origin")}} header is <strong>always</strong> sent.</p>
+
+<h3 id="Access-Control-Request-Method">Access-Control-Request-Method</h3>
+
+<p>The {{HTTPHeader("Access-Control-Request-Method")}} is used when issuing a preflight request to let the server know what HTTP method will be used when the actual request is made.</p>
+
+<pre class="brush: none notranslate">Access-Control-Request-Method: &lt;method&gt;
+</pre>
+
+<p>Examples of this usage can be <a class="internal" href="#Preflighted_requests">found above.</a></p>
+
+<h3 id="Access-Control-Request-Headers">Access-Control-Request-Headers</h3>
+
+<p>The {{HTTPHeader("Access-Control-Request-Headers")}} header is used when issuing a preflight request to let the server know what HTTP headers will be used when the actual request is made.</p>
+
+<pre class="brush: none notranslate">Access-Control-Request-Headers: &lt;field-name&gt;[, &lt;field-name&gt;]*
+</pre>
+
+<p>Examples of this usage can be <a class="internal" href="#Preflighted_requests">found above</a>.</p>
+
+<h2 id="Specifications">Specifications</h2>
+
+<table class="standard-table">
+ <tbody>
+  <tr>
+   <th scope="col">Specification</th>
+   <th scope="col">Status</th>
+   <th scope="col">Comment</th>
+  </tr>
+  <tr>
+   <td>{{SpecName('Fetch', '#cors-protocol', 'CORS')}}</td>
+   <td>{{Spec2('Fetch')}}</td>
+   <td>New definition; supplants <a href="https://www.w3.org/TR/cors/">W3C CORS</a> specification.</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Browser_compatibility">Browser compatibility</h2>
+
+<p class="hidden">The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> and send us a pull request.</p>
+
+<p>{{Compat("http.headers.Access-Control-Allow-Origin")}}</p>
+
+<h3 id="Compatibility_notes">Compatibility notes</h3>
+
+<ul>
+ <li>Internet Explorer 8 and 9 expose CORS via the <code>XDomainRequest</code> object, but have a full implementation in IE 10.</li>
+ <li>While Firefox 3.5 introduced support for cross-site <code>XMLHttpRequests</code> and Web Fonts, certain requests were limited until later versions. Specifically, Firefox 7 introduced the ability for cross-site HTTP requests for WebGL Textures, and Firefox 9 added support for Images drawn on a canvas using <code>drawImage()</code>.</li>
+</ul>
+
+<h2 id="See_also">See also</h2>
+
+<ul>
+ <li><a href="/en-US/docs/Web/HTTP/CORS/Errors">CORS errors</a></li>
+ <li><a href="https://enable-cors.org/server.html">Enable CORS: I want to add CORS support to my server</a></li>
+ <li>{{domxref("XMLHttpRequest")}}</li>
+ <li><a href="/en-US/docs/Web/API/Fetch_API">Fetch API</a></li>
+ <li><a class="external" href="http://www.kendoui.com/blogs/teamblog/posts/11-10-03/using_cors_with_all_modern_browsers.aspx">Using CORS with All (Modern) Browsers</a></li>
+ <li><a href="http://www.html5rocks.com/en/tutorials/cors/">Using CORS - HTML5 Rocks</a>
+  <ul>
+  </ul>
+ </li>
+ <li><a class="external" href="https://arunranga.com/examples/access-control/">Code Samples Showing <code>XMLHttpRequest</code> and Cross-Origin Resource Sharing</a></li>
+ <li><a href="https://github.com/jackblackevo/cors-jsonp-sample">Client-Side &amp; Server-Side (Java) sample for Cross-Origin Resource Sharing (CORS)</a></li>
+ <li><a class="internal" href="/en-US/docs/Web/HTTP/Server-Side_Access_Control">Cross-Origin Resource Sharing From a Server-Side Perspective (PHP, etc.)</a></li>
+ <li><a href="https://stackoverflow.com/questions/43871637/no-access-control-allow-origin-header-is-present-on-the-requested-resource-whe/43881141#43881141">Stack Overflow answer with “how to” info for dealing with common problems</a>:
+  <ul>
+   <li>How to avoid the CORS preflight</li>
+   <li>How to use a CORS proxy to get around <em>“No Access-Control-Allow-Origin header”</em></li>
+   <li>How to fix <em>“Access-Control-Allow-Origin header must not be the wildcard”</em></li>
+  </ul>
+ </li>
+</ul>
+
+<div>{{HTTPSidebar}}</div>
diff --git a/files/de/web/http/headers/accept/index.html b/files/de/web/http/headers/accept/index.html
new file mode 100644
index 0000000000..072e1bebd3
--- /dev/null
+++ b/files/de/web/http/headers/accept/index.html
@@ -0,0 +1,96 @@
+---
+title: Accept
+slug: Web/HTTP/Headers/Accept
+tags:
+  - Anfrage-Header
+  - HTTP
+  - HTTP Header
+translation_of: Web/HTTP/Headers/Accept
+---
+<div>{{HTTPSidebar}}</div>
+
+<p>Der <strong><code>Accept</code></strong> Anfrage-HTTP-Header drückt aus, welche Inhaltstypen, ausgedrückt als <a href="/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types">MIME-Typen (MIME-Types)</a>, der anfragende Client unterstützt. Durch <a href="/en-US/docs/Web/HTTP/Content_negotiation">Inhalts-Aushandlung (Content negotiation)</a> wählt der Ziel-Server einen Inhalts-Typen aus, verwendet diesen für den Inhalt und teilt dem Client diesen über den Antwort-HTTP-Header {{HTTPHeader("Content-Type")}} mit. Browser setzen entsprechende Inhalts-Typen automatisch, je nachdem in welchem Kontext die Anfrage stattfindet: Wenn ein CSS-Stylesheet angefragt wird, wird ein anderer Inhalts-Typ verwendet wie wenn ein Bild, Video oder Script angefragt wird.</p>
+
+<table class="properties">
+ <tbody>
+  <tr>
+   <th scope="row">Header-Typ</th>
+   <td>{{Glossary("Request header")}}</td>
+  </tr>
+  <tr>
+   <th scope="row">{{Glossary("Forbidden header name")}}</th>
+   <td>Nein</td>
+  </tr>
+  <tr>
+   <th scope="row">{{Glossary("CORS-safelisted request header")}}</th>
+   <td>Ja, mit der zusätzlichen Restriktion dass die Werte keine <em>CORS-unsicheren Anfrage-Header-Bytes</em> enthalten dürfen: <code>"():&lt;&gt;?@[\]{}</code>, Delete, Tab und Kontrollzeichen: 0x00 to 0x19.</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Syntax">Syntax</h2>
+
+<pre class="syntaxbox">Accept: &lt;MIME_type&gt;/&lt;MIME_subtype&gt;
+Accept: &lt;MIME_type&gt;/*
+Accept: */*
+
+// Mehrere Werte, gewichtet mit der {{glossary("quality values", "quality value")}} Syntax:
+Accept: text/html, application/xhtml+xml, application/xml;q=0.9, image/webp, */*;q=0.8
+</pre>
+
+<h2 id="Direktiven">Direktiven</h2>
+
+<dl>
+ <dt><code>&lt;MIME_type&gt;/&lt;MIME_subtype&gt;</code></dt>
+ <dd>Ein einfacher, präziser <a href="/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types">MIME-Type</a> wie <code>text/html</code>.</dd>
+ <dt><code>&lt;MIME_type&gt;/*</code></dt>
+ <dd>Ein Mime-Type, aber ohne einen Untertypen. <code>image/*</code> z.B. stimmt mit <code>image/png</code>, <code>image/svg</code>, <code>image/gif</code> und allen anderen Bild-Typen überein.</dd>
+ <dt><code>*/*</code></dt>
+ <dd>Irgend ein MIME-Type</dd>
+ <dt><code>;q=</code> (q-Faktor Gewichtung)</dt>
+ <dd>Jeder verwendete Wert definiert eine Ordnung der Präferenzen durch einen relativen <a href="/en-US/docs/Glossary/Quality_values">Qualitätswert (Quality value)</a>, auch als <strong>Gewichtung</strong> bezeichnet.</dd>
+</dl>
+
+<h2 id="Beispiele">Beispiele</h2>
+
+<pre>Accept: text/html
+
+Accept: image/*
+
+// Standard für allgemeine Anfragen
+Accept: */*
+
+// Standard für Navigations-Anfragen im Browser
+Accept: text/html, application/xhtml+xml, application/xml;q=0.9, */*;q=0.8
+</pre>
+
+<h2 id="Spezifikationen">Spezifikationen</h2>
+
+<table class="standard-table">
+ <thead>
+  <tr>
+   <th scope="col">Specification</th>
+   <th scope="col">Title</th>
+  </tr>
+ </thead>
+ <tbody>
+  <tr>
+   <td>{{RFC("7231", "Accept", "5.3.2")}}</td>
+   <td>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Context</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Browserkompatibilität">Browserkompatibilität</h2>
+
+<p class="hidden">The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> and send us a pull request.</p>
+
+<p>{{Compat("http.headers.Accept")}}</p>
+
+<h2 id="Siehe_auch">Siehe auch</h2>
+
+<ul>
+ <li>HTTP <a href="/en-US/docs/Web/HTTP/Content_negotiation">Inhalts-Aushandlung (Content negotiation)</a></li>
+ <li>Header, der das Ergebnis der Aushandlung enthält: {{HTTPHeader("Content-Type")}}</li>
+ <li>Andere, ähnliche Header: {{HTTPHeader("TE")}}, {{HTTPHeader("Accept-Encoding")}}, {{HTTPHeader("Accept-Charset")}}, {{HTTPHeader("Accept-Language")}}</li>
+</ul>
diff --git a/files/de/web/http/headers/age/index.html b/files/de/web/http/headers/age/index.html
new file mode 100644
index 0000000000..1f7190fc36
--- /dev/null
+++ b/files/de/web/http/headers/age/index.html
@@ -0,0 +1,80 @@
+---
+title: Age
+slug: Web/HTTP/Headers/Age
+tags:
+  - Caching
+  - HTTP
+  - Response
+  - header
+translation_of: Web/HTTP/Headers/Age
+---
+<div>{{HTTPSidebar}}</div>
+
+<p><code><strong>Age</strong></code> nennt die Dauer in Sekunden, die das angefragte Objekt bereits in einem Proxy-Cache zwischengespeichert ist.</p>
+
+<p>Die Dauer versteht sich üblicherweise als Differenz zwischen der aktuellen Uhrzeit und der Angabe {{HTTPHeader("Date")}}, die den Zeitpunkt anzeigt, an dem das Objekt ursprünglich erstellt wurde.</p>
+
+<p>Der Wert 0 deutet darauf hin, dass das Objekt gerade durch den Cache vom eigentlichen Server geholt wurde, mithin aktuell ist.</p>
+
+<table class="properties">
+ <tbody>
+  <tr>
+   <th scope="row">Typ</th>
+   <td>{{Glossary("Response header", "Antwort")}}</td>
+  </tr>
+  <tr>
+   <th scope="row">{{Glossary("Forbidden header name", "Verboten")}}</th>
+   <td>Nein</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Syntax">Syntax</h2>
+
+<pre class="syntaxbox">Age: &lt;delta-seconds&gt;
+</pre>
+
+<h2 id="Argument">Argument</h2>
+
+<dl>
+ <dt>&lt;delta-seconds&gt;</dt>
+ <dd>
+ <p>Eine positive Ganzzahl, die der Dauer in Sekunden entspricht, die das Objekt von einem Proxy-Cache zum Zeitpunkt des Abrufs bereits zwischengespeichert wurde.</p>
+ </dd>
+</dl>
+
+<h2 id="Beispiele">Beispiele</h2>
+
+<pre>Age: 24
+Date: Tue, 15 Nov 1994 08:12:31 GMT
+</pre>
+
+<p>Das Objekt befindet sich seit 24 Sekunden im Cache. Die aktuelle Uhrzeit müsste demnach 8:12:55 sein, 8:12:31 + 24s.</p>
+
+<h2 id="Spezifikationen">Spezifikationen</h2>
+
+<table class="standard-table">
+ <tbody>
+  <tr>
+   <th scope="col">Spezifikation</th>
+   <th scope="col">Titel</th>
+  </tr>
+  <tr>
+   <td>{{RFC("7234", "Age", "5.1")}}</td>
+   <td>Hypertext Transfer Protocol (HTTP/1.1): Caching</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Browserkompatibilität">Browserkompatibilität</h2>
+
+<p class="hidden">The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> and send us a pull request.</p>
+
+<p>{{Compat("http.headers.Age")}}</p>
+
+<h2 id="Siehe_auch">Siehe auch</h2>
+
+<ul>
+ <li>{{HTTPHeader("Cache-Control")}}</li>
+ <li>{{HTTPHeader("Expires")}}</li>
+</ul>
diff --git a/files/de/web/http/headers/cache-control/index.html b/files/de/web/http/headers/cache-control/index.html
new file mode 100644
index 0000000000..6606bcabd7
--- /dev/null
+++ b/files/de/web/http/headers/cache-control/index.html
@@ -0,0 +1,176 @@
+---
+title: Cache-Control
+slug: Web/HTTP/Headers/Cache-Control
+tags:
+  - Allgemeine Header
+  - HTTP
+  - HTTP-Header
+  - Referenz
+translation_of: Web/HTTP/Headers/Cache-Control
+---
+<div>{{HTTPSidebar}}</div>
+
+<p>Das allgemeine Header-Feld <strong><code>Cache-Control</code></strong> wird benutzt um Direktiven für Caching-Mechanismen, sowohl für Requests als auch für Responses, zu spezifizieren. Caching-Direktiven sind unidirektional, das bedeutet dass eine Direktive in einem Request nicht impliziert, dass die gleiche Direktive auch in einem Response zurückkommen muss.</p>
+
+<table class="properties">
+ <tbody>
+  <tr>
+   <th scope="row">Header type</th>
+   <td>{{Glossary("General header")}}</td>
+  </tr>
+  <tr>
+   <th scope="row">{{Glossary("Forbidden header name")}}</th>
+   <td>nein</td>
+  </tr>
+  <tr>
+   <th scope="row">{{Glossary("Simple response header", "CORS-safelisted response-header")}}</th>
+   <td>ja</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Syntax">Syntax</h2>
+
+<p>Die Direktiven beachten Groß- und Kleinschreibung und haben optionale Argumente, die sowohl Token-Syntax als auch Zeichenketten mit Anführungszeichen verwenden. Mehrere Direktiven werden kommasepariert.</p>
+
+<h3 id="Cache_Request_Direktiven">Cache Request Direktiven</h3>
+
+<p>Standard <code>Cache-Control</code> Direktiven, die vom Client in einem HTTP Request verwendet werden können.</p>
+
+<pre class="syntaxbox">Cache-Control: max-age=&lt;seconds&gt;
+Cache-Control: max-stale[=&lt;seconds&gt;]
+Cache-Control: min-fresh=&lt;seconds&gt;
+Cache-Control: no-cache
+Cache-Control: no-store
+Cache-Control: no-transform
+Cache-Control: only-if-cached
+</pre>
+
+<h3 id="Cache_Response_Direktiven">Cache Response Direktiven</h3>
+
+<p>Standard <code>Cache-Control</code> Direktiven, die vom Server in einer HTTP Response verwendet werden können.</p>
+
+<pre class="syntaxbox">Cache-Control: must-revalidate
+Cache-Control: no-cache
+Cache-Control: no-store
+Cache-Control: no-transform
+Cache-Control: public
+Cache-Control: private
+Cache-Control: proxy-revalidate
+Cache-Control: max-age=&lt;seconds&gt;
+Cache-Control: s-maxage=&lt;seconds&gt;
+</pre>
+
+<h3 id="Erweiterungs_Cache-Control_Direktiven">Erweiterungs <code>Cache-Control</code> Direktiven</h3>
+
+<p>Erweiterungs <code>Cache-Control</code> Direktiven sind nicht Teil des Kern HTTP Caching Standard-Dokuments. Prüfen Sie die Unterstützung in der <a href="#Browser_compatibility">Kompatibilitätstabelle</a>.</p>
+
+<pre class="syntaxbox">Cache-Control: immutable
+Cache-Control: stale-while-revalidate=&lt;seconds&gt;
+Cache-Control: stale-if-error=&lt;seconds&gt;
+</pre>
+
+<h2 id="Direktiven">Direktiven</h2>
+
+<h3 id="Cachebarkeit">Cachebarkeit</h3>
+
+<dl>
+ <dt><code>public</code></dt>
+ <dd>Kennzeichen dass die Response von jedem Cache gecached werden dürfen.</dd>
+ <dt><code>private</code></dt>
+ <dd>Kennzeichen dass die Response für einen einzigen Benutzer gedacht ist, und nicht von einem geteilten Cache gespeichert werden dürfen. Ein privater Cache darf die Response speichern.</dd>
+ <dt><code>no-cache</code></dt>
+ <dd>Zwingt Caches den Request dem Ursprungs-Server zuzustellen, um die Gültigkeit zu validieren, bevor eine gecachte Kopie freigegeben wird.</dd>
+ <dt><code>only-if-cached</code></dt>
+ <dd>Gibt an, dass keine neue Daten abgerufen werden sollen. Der Client möchte nur eine gecachte Response erhalten und sollte nicht den Ursprungs-Server kontaktieren, um zu prüfen, ob eine neuere Kopie existiert.</dd>
+</dl>
+
+<h3 id="Cache-Verfall">Cache-Verfall</h3>
+
+<dl>
+ <dt><code>max-age=&lt;seconds&gt;</code></dt>
+ <dd>Spezifiziert die maximale Zeitdauer, die eine Ressource als aktuell betrachtet wird. Im Gegensatz zu <code>Expires</code>, ist diese Direktive relativ zum Zeitpunkt des Requests.</dd>
+ <dt><code>s-maxage=&lt;seconds&gt;</code></dt>
+ <dd>Überschreibt <code>max-age</code> oder den <code>Expires</code> Header, bezieht sich allerdings nur auf geteilte Caches (z.B. Proxyserver) und wird von einem privaten Cachen ignoriert.</dd>
+ <dt><code>max-stale[=&lt;seconds&gt;]</code></dt>
+ <dd>Gibt an, dass der Client bereit ist eine Response zu akzeptieren, die ihre Ablaufzeit überschritten hat. Optional können Sie einen Wert in Sekunden angeben, der die Zeit angibt, die eine Response höchstens abgelaufen sein darf.</dd>
+ <dt><code>min-fresh=&lt;seconds&gt;</code></dt>
+ <dd>Gibt an, dass der Client eine Response erwartet, die mindestens noch für die angegebene Zeit aktuell ist.</dd>
+ <dt><code>stale-while-revalidate=&lt;seconds&gt;</code> {{experimental_inline}}</dt>
+ <dd>Gibt an, dass der Client bereit ist eine abgelaufene Response zu akzeptieren, während im Hintergrund asynchron auf eine Aktualisierung geprüft wird. Der zweite Wert gibt an für wie lange der Client bereit ist die abgelaufene Response zu akzeptieren.</dd>
+ <dt><code>stale-if-error=&lt;seconds&gt;</code> {{experimental_inline}}</dt>
+ <dd>...</dd>
+</dl>
+
+<h3 id="Revalidierung_und_Neuladen">Revalidierung und Neuladen</h3>
+
+<dl>
+ <dt><code>must-revalidate</code></dt>
+ <dd>Der Cache muss den Status der abgelaufenen Ressource überprüfen bevor sie verwendet wird. Abgelaufene Ressourcen sollten nicht verwendet werden.</dd>
+ <dt><code>proxy-revalidate</code></dt>
+ <dd>Gleich wie <code>must-revalidate</code>, aber bezieht sich nur auf geteilte Caches (z.B. Proxyserver) und wird von einem privaten Cache ignoriert.</dd>
+ <dt><code>immutable</code></dt>
+ <dd>Gibt an, dass der Response-Body sich nicht im Laufe der Zeit ändern wird. Falls die Ressource noch nicht abgelaufen ist, ist sie auf dem Server unverändert und daher sollte der Client, selbst wenn der Benutzer die Seite explizit aktualisiert, nicht eine bedingte Revalidierung schicken (z.B. <code>If-None-Match</code> oder <code>If-Modified-Since</code>) , um auf Aktualisierungen zu prüfen Die Ressource . Clients, denen diese Erweiterung unbekannt ist, müssen sie nach der HTTP-Spezifikation ignorieren. In Firefox, <code>immutable</code> wird nur bei <code>https://</code> Transaktionen beachtet. Für mehr Informationen, siehe auch diesen <a href="http://bitsup.blogspot.de/2016/05/cache-control-immutable.html">Blogpost</a>.</dd>
+</dl>
+
+<h3 id="Weitere">Weitere</h3>
+
+<dl>
+ <dt><code>no-store</code></dt>
+ <dd>Der Cache sollte nichts über den Client-Request oder die Server-Response speichern.</dd>
+ <dt><code>no-transform</code></dt>
+ <dd>Es sollte keinerlei Transformation oder Konvertierung der Ressoruce durchgeführt werden. Die Content-Encoding, Content-Range, Content-Type Headers dürfen nicht durch einen Proxyserver verändert werden. Ein nicht-transparenter Proxy könnte beispielsweise zwischen Bildformaten konvertieren, um Speicherplatz im Cache zu sparen oder den Datenverkehr bei einer langsamen Verbindung zu reduzieren. Die <code>no-transform</code> Direktive verbietet dies.</dd>
+</dl>
+
+<h2 id="Beispiele">Beispiele</h2>
+
+<h3 id="Caching_verhindern">Caching verhindern</h3>
+
+<p>Um Caching abzuschalten können Sie den folgenden Response Header schicken. Beachten Sie ggf. zusätzlich die <code>Expires</code> und <code>Pragma</code> Header.</p>
+
+<pre class="brush: bash">Cache-Control: no-cache, no-store, must-revalidate
+</pre>
+
+<h3 id="Statische_Assets_cachen">Statische Assets cachen</h3>
+
+<p>Für die Dateien einer Anwendung, die sich nicht ändern werden, können Sie normalerweise aggressives Caching nutzen, indem Sie den untenstehenden Response-Header senden. Dies schließt statische Dateien ein, die von der Anwendung bereitgestellt werden, wie z.B. Bilder, CSS- und JavaScript-Dateien. Beachten Sie außerdem den <code>Expires</code> Header.</p>
+
+<pre class="brush: bash">Cache-Control: public, max-age=31536000</pre>
+
+<h2 id="Spezifikationen">Spezifikationen</h2>
+
+<table class="standard-table">
+ <tbody>
+  <tr>
+   <th scope="col">Specification</th>
+   <th scope="col">Title</th>
+  </tr>
+  <tr>
+   <td>{{RFC("7234")}}</td>
+   <td>Hypertext Transfer Protocol (HTTP/1.1): Caching</td>
+  </tr>
+  <tr>
+   <td>{{RFC("5861")}}</td>
+   <td>HTTP Cache-Control Extensions for Stale Content</td>
+  </tr>
+  <tr>
+   <td>{{RFC("8246")}}</td>
+   <td>HTTP Immutable Responses</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Browser_Kompatibilität">Browser Kompatibilität</h2>
+
+<p class="hidden">The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> and send us a pull request.</p>
+
+<p>{{Compat("http.headers.Cache-Control")}}</p>
+
+<h2 id="Siehe_auch">Siehe auch</h2>
+
+<ul>
+ <li><a href="/en-US/docs/Web/HTTP/Caching_FAQ">HTTP Caching FAQ</a></li>
+ <li>{{HTTPHeader("Age")}}</li>
+ <li>{{HTTPHeader("Expires")}}</li>
+ <li>{{HTTPHeader("Pragma")}}</li>
+</ul>
diff --git a/files/de/web/http/headers/connection/index.html b/files/de/web/http/headers/connection/index.html
new file mode 100644
index 0000000000..8c4000ac5c
--- /dev/null
+++ b/files/de/web/http/headers/connection/index.html
@@ -0,0 +1,48 @@
+---
+title: Connection
+slug: Web/HTTP/Headers/Connection
+translation_of: Web/HTTP/Headers/Connection
+---
+<div>{{HTTPSidebar}}</div>
+
+<p>The <strong><code>Connection</code></strong> general header controls whether or not the network connection stays open after the current transaction finishes. If the value sent is <code>keep-alive</code>, the connection is persistent and not closed, allowing for subsequent requests to the same server to be done.</p>
+
+<div class="blockIndicator warning">
+<p>Connection-specific header fields such as {{HTTPHeader("Connection")}} and {{HTTPHeader("Keep-Alive")}} are <a href="https://tools.ietf.org/html/rfc7540#section-8.1.2.2">prohibited in HTTP/2</a>. Chrome and Firefox ignore them in HTTP/2 responses, but Safari conforms to the HTTP/2 spec requirements and won’t load any response which contains them.</p>
+</div>
+
+<p>Except for the standard hop-by-hop headers ({{HTTPHeader("Keep-Alive")}}, {{HTTPHeader("Transfer-Encoding")}}, {{HTTPHeader("TE")}}, {{HTTPHeader("Connection")}}, {{HTTPHeader("Trailer")}}, {{HTTPHeader("Upgrade")}}, {{HTTPHeader("Proxy-Authorization")}} and {{HTTPHeader("Proxy-Authenticate")}}), any hop-by-hop headers used by the message must be listed in the <code>Connection</code> header, so that the first proxy knows it has to consume them and not forward them further. Standard hop-by-hop headers can be listed too (it is often the case of {{HTTPHeader("Keep-Alive")}}, but this is not mandatory).</p>
+
+<table class="properties">
+ <tbody>
+  <tr>
+   <th scope="row">Header type</th>
+   <td>{{Glossary("General header")}}</td>
+  </tr>
+  <tr>
+   <th scope="row">{{Glossary("Forbidden header name")}}</th>
+   <td>yes</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Syntax">Syntax</h2>
+
+<pre class="syntaxbox notranslate">Connection: keep-alive
+Connection: close
+</pre>
+
+<h2 id="Directives">Directives</h2>
+
+<dl>
+ <dt><code>close</code></dt>
+ <dd>Indicates that either the client or the server would like to close the connection. This is the default on HTTP/1.0 requests.</dd>
+ <dt>any comma-separated list of HTTP headers [Usually <code>keep-alive</code> only]</dt>
+ <dd>Indicates that the client would like to keep the connection open. Having a persistent connection is the default on HTTP/1.1 requests. The list of headers are the name of the header to be removed by the first non-transparent proxy or cache in-between: these headers define the connection between the emitter and the first entity, not the destination node.</dd>
+</dl>
+
+<h2 id="Browser_compatibility">Browser compatibility</h2>
+
+<p class="hidden">The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> and send us a pull request.</p>
+
+<p>{{Compat("http.headers.Connection")}}</p>
diff --git a/files/de/web/http/headers/cookie/index.html b/files/de/web/http/headers/cookie/index.html
new file mode 100644
index 0000000000..71552da494
--- /dev/null
+++ b/files/de/web/http/headers/cookie/index.html
@@ -0,0 +1,72 @@
+---
+title: Cookie
+slug: Web/HTTP/Headers/Cookie
+tags:
+  - Cookies
+  - HTTP
+  - Reference
+  - header
+  - request
+translation_of: Web/HTTP/Headers/Cookie
+---
+<div>{{HTTPSidebar}}</div>
+
+<p>Der <strong><code>Cookie</code></strong> HTTP Request Header enthält gespeicherte <a href="/en-US/docs/Web/HTTP/Cookies">HTTP Cookies</a> welche zuvor vom Server mit dem {{HTTPHeader("Set-Cookie")}} Header gesendet wurden.</p>
+
+<p>Der <code>Cookie</code> Header ist optional und kann weggelassen werden falls z.B. die Einstellungen für Privatsphäre im Browser keine Cookies zulassen.</p>
+
+<table class="properties">
+ <tbody>
+  <tr>
+   <th scope="row">Header Typ</th>
+   <td>{{Glossary("Request Header")}}</td>
+  </tr>
+  <tr>
+   <th scope="row">{{Glossary( "Forbidden header name" , "Verbotener Header-Name")}}</th>
+   <td>Ja</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Syntax">Syntax</h2>
+
+<pre class="syntaxbox">Cookie: &lt;cookie-list&gt;
+Cookie: name=value
+Cookie: name=value; name2=value2; name3=value3</pre>
+
+<dl>
+ <dt>&lt;cookie-list&gt;</dt>
+ <dd>Eine Liste von Name/Wert-Paaren von folgender Form <code>&lt;cookie-name&gt;=&lt;cookie-value&gt;</code>. Mehrere Einträge in der Liste werden durch ein Semikolon gefolgt von einem Leerzeichen getrennt (<code>'; '</code>).</dd>
+</dl>
+
+<h2 id="Beispiele">Beispiele</h2>
+
+<pre>Cookie: PHPSESSID=298zf09hf012fh2; csrftoken=u32t4o3tb3gg43; _gat=1;</pre>
+
+<h2 id="Spezifikationen">Spezifikationen</h2>
+
+<table class="standard-table">
+ <tbody>
+  <tr>
+   <th scope="col">Spezifikationen</th>
+   <th scope="col">Titel</th>
+  </tr>
+  <tr>
+   <td>{{RFC("6265", "Cookie", "5.4")}}</td>
+   <td>HTTP State Management Mechanism</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Browser_Kompatibilität">Browser Kompatibilität</h2>
+
+<p class="hidden">The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> and send us a pull request.</p>
+
+<p>{{Compat("http.headers.Cookie")}}</p>
+
+<h2 id="Siehe_auch">Siehe auch</h2>
+
+<ul>
+ <li>{{HTTPHeader("Set-Cookie")}}</li>
+ <li>{{domxref("Document.cookie")}}</li>
+</ul>
diff --git a/files/de/web/http/headers/dnt/index.html b/files/de/web/http/headers/dnt/index.html
new file mode 100644
index 0000000000..861c398c92
--- /dev/null
+++ b/files/de/web/http/headers/dnt/index.html
@@ -0,0 +1,88 @@
+---
+title: DNT
+slug: Web/HTTP/Headers/DNT
+tags:
+  - DNT
+  - HTTP
+  - Refernz
+  - header
+translation_of: Web/HTTP/Headers/DNT
+---
+<div>{{HTTPSidebar}}</div>
+
+<p>Der <strong><code>DNT</code></strong> (<strong>D</strong>o <strong>N</strong>ot <strong>T</strong>rack, engl. "Bitte nicht Tracken") Anfragenheader indiziert, die Tracking-Präferenz des Nutzers. Er lässt den Nutzer indizieren, ob dieser lieber Privatsphäre als personalisierten Kontent hätte.</p>
+
+<table class="properties">
+ <tbody>
+  <tr>
+   <th scope="row">Header-Typ</th>
+   <td>{{Glossary("Request header")}}</td>
+  </tr>
+  <tr>
+   <th scope="row">{{Glossary("Forbidden header name")}}</th>
+   <td>Ja</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Syntax">Syntax</h2>
+
+<pre class="syntaxbox">DNT: 0
+DNT: 1
+</pre>
+
+<h2 id="Directives">Directives</h2>
+
+<dl>
+ <dt>0</dt>
+ <dd>Der Nutzer erlaubt das Tracking auf der Zielseite.</dd>
+ <dt>1</dt>
+ <dd>Der Nutze möchte auf der Zielseite lieber nicht getrackt werden.</dd>
+</dl>
+
+<h2 id="Examples">Examples</h2>
+
+<h3 id="Die_DNT-Präferenz_per_JavaScript_auslesen">Die DNT-Präferenz per JavaScript auslesen</h3>
+
+<p>Die DNT-Präferenz des Nutzers kann auch per JavaScript, dank dem {{domxref("Navigator.doNotTrack")}} Wert, ausgelesen werden:</p>
+
+<pre class="brush: js">navigator.doNotTrack; // "0" oder "1"</pre>
+
+<h2 id="Specifikationen">Specifikationen</h2>
+
+<table class="standard-table">
+ <tbody>
+  <tr>
+   <th scope="col">Specification</th>
+   <th scope="col">Status</th>
+   <th scope="col">Comment</th>
+  </tr>
+  <tr>
+   <td>{{SpecName('Tracking','#dnt-header-field', 'DNT Header Field for HTTP Requests')}}</td>
+   <td>{{Spec2("Tracking")}}</td>
+   <td>Erstmalige Definition.</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Browser_compatibility">Browser compatibility</h2>
+
+<p class="hidden">The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> and send us a pull request.</p>
+
+<p>{{Compat("http.headers.DNT")}}</p>
+
+<h2 id="Siehe_auch">Siehe auch</h2>
+
+<ul>
+ <li>{{domxref("Navigator.doNotTrack")}}</li>
+ <li>{{HTTPHeader("Tk")}} header</li>
+ <li><a href="https://en.wikipedia.org/wiki/Do_Not_Track">Do Not Track on Wikipedia</a></li>
+ <li><a href="https://www.eff.org/deeplinks/2011/02/what-does-track-do-not-track-mean">What Does the "Track" in "Do Not Track" Mean? – EFF</a></li>
+ <li><a href="http://donottrack.us/">donottrack.us</a></li>
+ <li>DNT Browsereinstellungen:
+  <ul>
+   <li><a href="https://www.mozilla.org/en-US/firefox/dnt/">Firefox</a></li>
+   <li><a href="https://support.google.com/chrome/answer/2790761">Chrome</a></li>
+  </ul>
+ </li>
+</ul>
diff --git a/files/de/web/http/headers/expect-ct/index.html b/files/de/web/http/headers/expect-ct/index.html
new file mode 100644
index 0000000000..15ec892562
--- /dev/null
+++ b/files/de/web/http/headers/expect-ct/index.html
@@ -0,0 +1,113 @@
+---
+title: Expect-CT
+slug: Web/HTTP/Headers/Expect-CT
+tags:
+  - HTTP
+  - Reference
+  - Referenz
+  - Security
+  - Sicherheit
+  - Verschlüsselung
+  - header
+translation_of: Web/HTTP/Headers/Expect-CT
+---
+<p>{{HTTPSidebar}}</p>
+
+<p><span class="seoSummary">Der <code>Expect-CT</code> HTTP Header erlaubt es Webseiten, die Anforderungen der <a href="/en-US/docs/Web/Security/Certificate_Transparency">Certificate Transparency</a> (kurz: CT) zu aktivieren und/oder zu erzwingen, um so der (unbemerkten) Verwendung falsch ausgestellter Zertifikate vorzubeugen.</span></p>
+
+<p>CT-Anforderungen können erfüllt werden über einen der nachstehenden Mechanismen:</p>
+
+<ul>
+ <li>X.509v3 certificate extension: signierte SCTs (SCT=<em>signed certificate timestamp)</em> werden direkt in das Zertifikat einbettet</li>
+ <li>Eine TLS-Erweiterung des Typs <code>signed_certificate_timestamp</code> wird während des handshakes gesendet</li>
+ <li>OCSP stapling (über die <code>status_request</code> TLS-Erweiterung) und das Bereitstellen einer <code>SignedCertificateTimestampList</code> mit einem oder mehreren SCTs</li>
+</ul>
+
+<div class="note">
+<p>Wenn eine Webseite die Verwendung des <code>Expect-CT</code> Headers aktiviert, fordert sie den Browser darüber auf, jedes im Zusammenhang mit der Webseite verwendete Zertifikat in <strong><a href="https://www.certificate-transparency.org/known-logs">öffentlichen CT Protokollen</a> </strong>nachzuschlagen.</p>
+</div>
+
+<div class="note">
+<p>Browsers <strong>ignorieren</strong> den <code>Expect-CT</code> Header bei HTTP-Verbindungen; der Header hat nur bei HTTPS-Verbindungen einen Effekt.</p>
+</div>
+
+<div class="note">
+<p><code>Expect-CT</code> wird im Juni 2021 voraussichtlich obsolet werden. Seit Mai 2018 ist es erforderlich, dass neue ausgestellte Zertifikate standardmäßig SCTs unterstützen. Ältere Zertifikate, vor März 2018 ausgestellt, können eine Gültigkeitsdauer von 39 Monaten haben, wodurch sie alle im Juni 2021 ablaufen.</p>
+</div>
+
+<table class="properties">
+ <tbody>
+  <tr>
+   <th scope="row">Header type</th>
+   <td>{{Glossary("Response header")}}</td>
+  </tr>
+  <tr>
+   <th scope="row">{{Glossary("Forbidden header name")}}</th>
+   <td>yes</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Syntax">Syntax</h2>
+
+<pre>Expect-CT: report-uri="&lt;uri&gt;",
+           enforce,
+           max-age=&lt;age&gt;</pre>
+
+<h2 id="Direktiven"> Direktiven</h2>
+
+<dl>
+ <dt><code>max-age</code></dt>
+ <dd>
+ <p>Die Anzahl der Sekunden nach dem Empfang des <code>Expect-CT</code>-Header-Feldes, während der der User-Agent den Host der empfangenen Nachricht als bekannten <code>Expect-CT</code> Host betrachten sollte.</p>
+
+ <p>Falls ein Cache einen Wert enthält der größer ist, als dieser abbilden kann oder seine nachfolgenden Berechnungen überlaufen, dann verwendet der Cache automatisch den für ihn größtmöglichen positiven Ganzzahlwert (integer) bzw. 2,147,483,648 (2<sup>31</sup>).</p>
+ </dd>
+ <dt><code>report-uri="&lt;uri&gt;"</code> {{optional_inline}}</dt>
+ <dd>
+ <p>Die URI wohin der Browser <code>Expect-CT</code> Fehler melden soll.</p>
+ In Kombination mit der <code>enforce</code> Direktive wird die Konfiguration als sogenannte "enforce-and-report" (erzwinge und melde) gewertet, wodurch dem user agent signalisiert wird, dass sowohl die Einhaltung der Certificate Transparency Richtlinien erzwungen als auch jede Verletzung berichtet werden soll.</dd>
+ <dt><code>enforce</code> {{optional_inline}}</dt>
+ <dd>
+ <p>Verlangt vom user agent, dass die Einhaltung der Certificate Transparency Richtlinien erzwungen werden soll (anstatt diese nur zu berichten). Gleichzeitig verweigert der user agent zukünftige Verbindungen, die gegen die Certificate Transparency Richtlinien verstoßen.</p>
+
+ <p>In Kombination mit den Direktiven <code>enforce</code> und <code>report-uri</code> wird die Konfiguration als sogenannte "enforce-and-report" (erzwinge und melde) gewertet, wodurch dem user agent signalisiert wird, dass sowohl die Einhaltung der Certificate Transparency Richtlinien erzwungen als auch jede Verletzung berichtet werden soll.</p>
+ </dd>
+</dl>
+
+<h2 id="Beispiel">Beispiel</h2>
+
+<p>Dieses Beispiel legt fest, dass die Certificate Transparency für den Zeitraum von 24 Stunden erzwungen werden soll und jede Verletzung in dem Zusammenhang wird gemeldet an die angegebene URL unter <code>foo.example</code>.</p>
+
+<pre>Expect-CT: max-age=86400, enforce, report-uri="https://foo.example/report"</pre>
+
+<h2 id="Hinweise">Hinweise</h2>
+
+<p>Root CAs, die manuell als vertrauenswürdig festgelegt werden, übersteuern und verhindern <code>Expect-CT</code> Berichte/Durchsetzung.</p>
+
+<p>Browser merken sich eine <code>Expect-CT</code> Richtlinie nicht, außer eine Webseite hat bewiesen, dass sie Zertifikate bereitstellt, die den Certificate Transparency Anforderungen genügen. Browser implementieren ihre eigenen Modelle darüber, welche CT-Protokolle diese für die Bewertung der Vertrauenswürdigkeit heranziehen.</p>
+
+<p>Google Chrome beispielsweise erzwingt eine <code>Expect-CT</code> Richtlinie nur für einen Zeitraum von 10 Wochen nach dem Build Datum.</p>
+
+<h2 id="Spezifikationen">Spezifikationen</h2>
+
+<table class="standard-table">
+ <thead>
+  <tr>
+   <th scope="col">Specification</th>
+   <th scope="col">Title</th>
+  </tr>
+ </thead>
+ <tbody>
+  <tr>
+   <td><a href="https://tools.ietf.org/html/draft-ietf-httpbis-expect-ct-08">Internet Draft</a></td>
+   <td>Expect-CT Erweiterung für HTTP</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Browser_Unterstützung">Browser Unterstützung</h2>
+
+<div class="hidden">Diese Kompatibilitätstabelle auf dieser Seite wird aus strukturierten Daten erstellt. Wenn du an diesen Daten mitwirken möchtest, besuche bitte die URL <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> und sende uns einen Pull Request.</div>
+
+<p>{{Compat("http.headers.Expect-CT")}}</p>
diff --git a/files/de/web/http/headers/expires/index.html b/files/de/web/http/headers/expires/index.html
new file mode 100644
index 0000000000..994fb342c9
--- /dev/null
+++ b/files/de/web/http/headers/expires/index.html
@@ -0,0 +1,75 @@
+---
+title: Expires
+slug: Web/HTTP/Headers/Expires
+translation_of: Web/HTTP/Headers/Expires
+---
+<div>{{HTTPSidebar}}</div>
+
+<p>Der <code><strong>Expires</strong></code> header enthält das Datum/Zeit nach dem die Response als abgelaufen angesehen wird.</p>
+
+<p>Invalide Datumsangaben, wie ein Date=0, stellen ein Datum in der Vergangenheit dar, dementsprechend ist die Resource bereits abgelaufen.</p>
+
+<p>Falls ein  {{HTTPHeader("Cache-Control")}} header mit der "max-age" oder "s-maxage" Direktive in der Response gesetzt ist, wird  der <code>Expires</code> Header ignoriert.</p>
+
+<table class="properties">
+ <tbody>
+  <tr>
+   <th scope="row">Header type</th>
+   <td>{{Glossary("Response header")}}</td>
+  </tr>
+  <tr>
+   <th scope="row">{{Glossary("Forbidden header name")}}</th>
+   <td>nein</td>
+  </tr>
+  <tr>
+   <th scope="row">{{Glossary("Simple response header", "CORS-safelisted response-header")}}</th>
+   <td>Ja</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Syntax">Syntax</h2>
+
+<pre class="syntaxbox">Expires: &lt;http-date&gt;
+</pre>
+
+<h2 id="Direktiven">Direktiven</h2>
+
+<dl>
+ <dt>&lt;http-date&gt;</dt>
+ <dd>
+ <p>Ein HTTP-date timestamp.</p>
+ </dd>
+</dl>
+
+<h2 id="Beispiel">Beispiel</h2>
+
+<pre>Expires: Wed, 21 Oct 2015 07:28:00 GMT</pre>
+
+<h2 id="Spezifikationen">Spezifikationen</h2>
+
+<table class="standard-table">
+ <tbody>
+  <tr>
+   <th scope="col">Spezifikation</th>
+   <th scope="col">Titel</th>
+  </tr>
+  <tr>
+   <td>{{RFC("7234", "Expires", "5.3")}}</td>
+   <td>Hypertext Transfer Protocol (HTTP/1.1): Caching</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Browserkompatibilität">Browserkompatibilität</h2>
+
+<p class="hidden">Die Kompabilitätstabelle wird aus Strukturierten Datensätzen generiert. Falls Sie zum Datenbestand beitragen wolllen, finden Sie ihn auf <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> und können uns einen Pullrequest stellen</p>
+
+<p>{{Compat("http.headers.Expires")}}</p>
+
+<h2 id="See_also">See also</h2>
+
+<ul>
+ <li>{{HTTPHeader("Cache-Control")}}</li>
+ <li>{{HTTPHeader("Age")}}</li>
+</ul>
diff --git a/files/de/web/http/headers/index.html b/files/de/web/http/headers/index.html
new file mode 100644
index 0000000000..2f2c145e6b
--- /dev/null
+++ b/files/de/web/http/headers/index.html
@@ -0,0 +1,441 @@
+---
+title: HTTP Header
+slug: Web/HTTP/Headers
+translation_of: Web/HTTP/Headers
+---
+<div>{{HTTPSidebar}}</div>
+
+<p>HTTP Header (Kopfzeilen) erlauben es dem Client und Server zusätzliche Informationen an eine Anfrage oder eine Antwort zu übergeben. Ein HTTP Header besteht aus seinem Namen (Groß-/Kleinschreibung unwichtig), gefolgt von einem Doppelpunkt '<code>:</code>' und dem Wert (ohne Zeilenumbrüche). Führender Leerraum vor dem Wert wird ignoriert.</p>
+
+<p>Benutzerdefinierte, proprietäre Header können mit einem 'X-' Präfix hinzugefügt werden, diese Konvention wurde jedoch im Juni 2012 missbilligt, da es Unannehmlichkeiten verursachte, als nicht standardisierte Felder in {{rfc(6648)}} standardisiert wurden; andere sind im <a href="https://www.iana.org/assignments/message-headers/perm-headers.html">IANA Register</a> aufgeführt, dessen ursprünglicher Inhalt in {{rfc(4229)}} definiert wurde. Die IANA pflegt auch ein <a href="https://www.iana.org/assignments/message-headers/prov-headers.html">Register mit Vorschlägen für neue HTTP Header</a>.</p>
+
+<p>Header können gemäß ihres Kontexts gruppiert werden:</p>
+
+<ul>
+ <li>{{Glossary("General header")}}: Header die sowohl für Anfragen als auch für Antworten zutreffen, jedoch keinen Bezug zu den Daten haben, die eventuell im Body übertragen werden.</li>
+ <li>{{Glossary("Request header")}}: Header die weitere Informationen über die angeforderte Ressource oder den Client selbst enthalten.</li>
+ <li>{{Glossary("Response header")}}: Header mit weiteren Informationen zur Antwort, wie etwa ihres Orts oder den Server selbst (Name und Version etc.)</li>
+ <li>{{Glossary("Entity header")}}: Header die weitere Informationen über den Body der Entität enthalten, wie etwa der Inhaltslänge oder ihren MIME-Type.</li>
+</ul>
+
+<p>Header können auch danach gruppiert werden, wie Proxys sie verarbeiten:</p>
+
+<dl>
+ <dt>End-to-end Header</dt>
+ <dd>Diese Header müssen an den endgültigen Empfänger der Nachricht übermittelt werden, d. h. den Server für eine Anfrage oder den Client für eine Antwort. Zwischen-Proxys müssen unmodifizierte End-to-end-Header erneut übertragen und zwischenspeichern.</dd>
+ <dt>Hop-by-hop Header</dt>
+ <dd>Diese Header sind nur für eine einzelne Verbindung auf Transportebene von Bedeutung und dürfen nicht von Proxys erneut übertragen oder zwischengespeichert werden. Solche Header sind: {{httpheader("Connection")}}, {{httpheader("Keep-Alive")}}, {{httpheader("ProxyAuthenticate")}}, {{httpheader("Proxy-Authorization")}}, {{httpheader("TE")}}, {{httpheader("Trailer")}}, {{httpheader("Transfer-Encoding")}} und {{httpheader("Upgrade")}}. Beachten Sie, dass nur Hop-by-hop Header mit dem allgemeinen Header {{httpheader("Connection")}} festgelegt werden können.</dd>
+</dl>
+
+<p>In der folgenden Liste werden die HTTP Header nach ihrer Verwendungskategorie zusammengefasst. Eine alphabetische Liste finden Sie in der Navigation auf der linken Seite.</p>
+
+<h2 id="Authentifizierung">Authentifizierung</h2>
+
+<dl>
+ <dt>{{HTTPHeader("WWW-Authenticate")}}</dt>
+ <dd>Definiert die Authentifizierungsmethode, die verwendet werden soll, um Zugriff auf eine Ressource zu erhalten.</dd>
+ <dt>{{HTTPHeader("Authorization")}}</dt>
+ <dd>Enthält die Anmeldeinformationen zum Authentifizieren eines Benutzer-Agenten an einem Server.</dd>
+ <dt>{{HTTPHeader("Proxy-Authenticate")}}</dt>
+ <dd>Definiert die Authentifizierungsmethode, die verwendet werden soll, um Zugriff auf eine Ressource hinter einem Proxyserver zu erhalten.</dd>
+ <dt>{{HTTPHeader("Proxy-Authorization")}}</dt>
+ <dd>Enthält die Anmeldeinformationen zum Authentifizieren eines Benutzer-Agenten an einem Proxyserver.</dd>
+</dl>
+
+<h2 id="Caching">Caching</h2>
+
+<dl>
+ <dt>{{HTTPHeader("Age")}}</dt>
+ <dd>Die Zeit in Sekunden, die sich das Objekt in einem Proxy-Cache befunden hat.</dd>
+ <dt>{{HTTPHeader("Cache-Control")}}</dt>
+ <dd>Gibt Anweisungen für Cache-Mechanismen in Anfragen und Antworten an.</dd>
+ <dt>{{HTTPHeader("Clear-Site-Data")}}</dt>
+ <dd>Löscht Browsing-Daten (z. B. Cookies, Storage, Cache), die der anfragenden Website zugeordnet sind.</dd>
+ <dt>{{HTTPHeader("Expires")}}</dt>
+ <dd>Das Datum und die Uhrzeit, nach der die Antwort als veraltet gilt.</dd>
+ <dt>{{HTTPHeader("Pragma")}}</dt>
+ <dd>Implementierungsspezifischer Header, der entlang der Anfrage-Antwort-Kette verschiedene Auswirkungen haben kann. Wird für die Abwärtskompatibilität mit HTTP/1.0 Caches verwendet, bei denen der <code>Cache-Control</code>-Header noch nicht vorhanden ist.</dd>
+ <dt>{{HTTPHeader("Warning")}}</dt>
+ <dd>Ein allgemeines Warnfeld, das Informationen zu möglichen Problemen enthält.</dd>
+</dl>
+
+<h2 id="Client_Hints">Client Hints</h2>
+
+<p>HTTP Client Hints befinden sich noch in der Entwicklung. Dokumentation hierzu befindet sich auf der <a href="https://httpwg.org/http-extensions/client-hints.html">Webseite der HTTP Working Group</a>.</p>
+
+<dl>
+ <dt>{{HTTPHeader("Accept-CH")}} {{experimental_inline}}</dt>
+ <dd>Server können Unterstützung für Clienthinweise unter Verwendung des Headerfelds Accept-CH oder eines entsprechenden HTML {{htmlelement("meta")}} Element mit dem Attribut http-equiv attribute (<a href="https://httpwg.org/http-extensions/client-hints.html#HTML5"><cite>[HTML5]</cite></a>) ankündigen.</dd>
+ <dt>{{HTTPHeader("Accept-CH-Lifetime")}} {{experimental_inline}}</dt>
+ <dd><span class="tlid-translation translation">Server können den Client auffordern, sich an die vom Client für einen bestimmten Zeitraum unterstützten Client Hints zu erinnern, um die Zustellung von Client hints für nachfolgende Anfragen an den Ursprung des Servers zu ermöglichen</span> (<a href="https://httpwg.org/http-extensions/client-hints.html#RFC6454"><cite>[RFC6454]</cite></a>).</dd>
+ <dt>{{HTTPHeader("Early-Data")}} {{experimental_inline}}</dt>
+ <dd><span class="tlid-translation translation">Gibt an, dass die Anforderung in frühen Daten übermittelt wurde.</span></dd>
+ <dt>{{HTTPHeader("Content-DPR")}} {{experimental_inline}}</dt>
+ <dd><span class="tlid-translation translation">Das <code>Content-DPR</code> Antwort Header-Feld ist eine Zahl, die das Verhältnis zwischen physischen Pixeln und CSS Pixeln des ausgewählten Bilds als Antwort angibt.</span></dd>
+ <dt>{{HTTPHeader("DPR")}} {{experimental_inline}}</dt>
+ <dd>Das <code>DPR</code> Anfrage-Header-Feld ist eine Zahl, die das aktuelle Geräte-Pixelverhältnis (Device Pixel Ratio (DPR)) des Clients angibt. Hierbei handelt es sich um das Verhältnis der physischen Pixel zu CSS Pixeln (Abschnitt 5.2 von <a href="https://httpwg.org/http-extensions/client-hints.html#CSSVAL"><cite>[CSSVAL]</cite></a>) des Layout Viewport (Abschnitt 9.1.1 <cite>von </cite><a href="https://httpwg.org/http-extensions/client-hints.html#CSS2"><cite>[CSS2]</cite></a>) auf dem Gerät.</dd>
+ <dt>{{HTTPHeader("Save-Data")}} {{experimental_inline}}</dt>
+ <dd>Das <a class="internalDFN" href="https://wicg.github.io/netinfo/#dom-networkinformation-savedata"><code>SaveData</code></a> [<cite><a class="bibref" href="https://wicg.github.io/netinfo/#bib-client-hints">CLIENT-HINTS</a></cite>] Anfrage-Header-Feld besteht aus einem oder mehreren Token, die die Präferenz des Benutzer-Agenten für eine reduzierte Datennutzung angeben.</dd>
+ <dt>{{HTTPHeader("Viewport-Width")}} {{experimental_inline}}</dt>
+ <dd>
+ <div id="rfc.section.3.3.p.1">
+ <p>Das <code>Viewport-Width</code> Anfrage-Header-Feld ist eine Zahl, die die Breite des Layout Viewport in CSS Pixeln angibt. Der gegebene CSS Pixel Wert ist eine Zahl, die auf die kleinste folgende Ganzzahl (d. h. den Höchstwert) gerundet wird.</p>
+ </div>
+
+ <div id="rfc.section.3.3.p.2">
+ <p>Wenn <code>Viewport-Width</code> mehr als einmal in einer Nachricht vorkommt, dann überschreibt der letzte Wert alle vorherigen.</p>
+ </div>
+ </dd>
+ <dt>{{HTTPHeader("Width")}} {{experimental_inline}}</dt>
+ <dd>
+ <div id="rfc.section.3.2.p.1">
+ <p>Das <code>Width</code> Anfrage-Header-Feld ist eine Zahl, die die gewünschte Ressourcenbreite in physischen Pixeln angibt (d. h. eigentliche Größe eines Bildes). Der gegebene physikalische Pixel Wert ist eine Zahl, die auf die kleinste folgende Ganzzahl (d. h. den Höchstwert) gerundet ist.</p>
+
+ <p>Wenn die gewünschte Ressourcenbreite zum Zeitpunkt der Anforderung nicht bekannt ist oder die Ressource keine Anzeigebreite aufweist, kann das Header-Feld <code>Width</code> weggelassen werden. Wenn <code>Width</code> mehr als einmal in einer Nachricht vorkommt, dann überschreibt der letzte Wert alle vorherigen.</p>
+ </div>
+ </dd>
+</dl>
+
+<dl>
+ <dt>{{HTTPHeader("Accept-CH")}} {{experimental_inline}}</dt>
+ <dd>Server können Support für Client Hints bekanntgeben, indem das Accept-CH Header-Feld oder das entsprechende HTML {{htmlelement("meta")}} Element mit http-equiv Attribut benutzt wird (<a href="https://httpwg.org/http-extensions/client-hints.html#HTML5"><cite>[HTML5]</cite></a>).</dd>
+</dl>
+
+<dl>
+ <dt>{{HTTPHeader("Accept-CH-Lifetime")}} {{experimental_inline}}</dt>
+ <dd>Servers can ask the client to remember the set of Client Hints that the server supports for a specified period of time, to enable delivery of Client Hints on subsequent requests to the server’s origin (<a href="https://httpwg.org/http-extensions/client-hints.html#RFC6454"><cite>[RFC6454]</cite></a>).</dd>
+ <dt>{{HTTPHeader("Early-Data")}} {{experimental_inline}}</dt>
+ <dd>Indicates that the request has been conveyed in early data.</dd>
+</dl>
+
+<h2 id="Bedingungen">Bedingungen</h2>
+
+<dl>
+ <dt>{{HTTPHeader("Last-Modified")}}</dt>
+ <dd>Ein Validator mit dem letzten Änderungsdatum der Ressource, mit welchem mehrere Versionen derselben Ressource miteinander verglichen werden. Es ist weniger genau als {{HTTPHeader("ETag")}}, aber in einigen Umgebungen einfacher zu berechnen. Bedingte Anforderungen, die {{HTTPHeader("If-Modified-Since")}} und {{HTTPHeader("If-Unmodified-Since")}} verwenden, verwenden diesen Wert, um das Verhalten der Anforderung zu ändern.</dd>
+ <dt>{{HTTPHeader("ETag")}}</dt>
+ <dd>Ein Validator für eine eindeutige Zeichenfolge, die die Version der Ressource identifiziert. Bedingte Anforderungen, die {{HTTPHeader("If-Match")}} und {{HTTPHeader("If-None-Match")}} verwenden, nutzen diesen Wert um das Verhalten der Anfrage zu verändern.</dd>
+ <dt>{{HTTPHeader("If-Match")}}</dt>
+ <dd>Knüpft die Anfrage an eine Bedingung und wendet die Methode nur dann an, wenn die gespeicherte Ressource einem der gegebenen ETags entspricht.</dd>
+ <dt>{{HTTPHeader("If-None-Match")}}</dt>
+ <dd>Knüpft die Anfrage an eine Bedingung und wendet die Methode nur dann an, wenn die gespeicherte Ressource keinem der gegebenen ETags entspricht. Dies kann dazu benutzt werden, um Caches zu aktualisieren (für sichere Anfragen) oder um zu verhindern, eine neue Ressource hochzuladen, wenn bereits eine existiert.</dd>
+ <dt>{{HTTPHeader("If-Modified-Since")}}</dt>
+ <dd>Knüpft die Anfrage an eine Bedingung und erwartet, dass die Entität nur dann übertragen wird, wenn sie nach einem gegebenem Datum modifiziert wurde. Dies kann dazu benutzt werden, nur dann Daten zu übertragen, wenn der Cache veraltet ist.</dd>
+ <dt>{{HTTPHeader("If-Unmodified-Since")}}</dt>
+ <dd>Knüpft die Anfrage an eine Bedingung und erwartet, dass die Entität nur dann übertragen wird, wenn sie nach einem gegebenem Datum nicht modifiziert wurde. Dies kann dazu benutzt werden, um die Stimmigkeit eines neuen Fragments eines bestimmten Bereichs mit vorherigen zu gewährleisten oder ein optimistisches Parallelitätskontrollsystem beim Modifizieren existierender Dokumente zu implementieren.</dd>
+ <dt>{{HTTPHeader("Vary")}}</dt>
+ <dd>Legt fest, wie zukünftige Anfrage Header abgeglichen werden sollen, um zu entscheiden, ob eine zwischengespeicherte Antwort verwendet werden kann, anstatt eine neue vom Ursprungsserver anzufordern.</dd>
+</dl>
+
+<h2 id="Verbindungsverwaltung">Verbindungsverwaltung</h2>
+
+<dl>
+ <dt>{{HTTPHeader("Connection")}}</dt>
+ <dd>Steuert, ob die Netzwerkverbindung geöffnet bleiben soll, nachdem die aktuelle Transaktion beendet ist.</dd>
+ <dt>{{HTTPHeader("Keep-Alive")}}</dt>
+ <dd>Steuert, wie lange eine dauerhafte Verbindung geöffnet bleiben soll.</dd>
+</dl>
+
+<h2 id="Inhaltsverhandlung"><a href="/en-US/docs/Web/HTTP/Content_negotiation">Inhaltsverhandlung</a></h2>
+
+<dl>
+ <dt>{{HTTPHeader("Accept")}}</dt>
+ <dd>Setzt den Server darüber in Kenntnis, welche Art Daten zurückgesendet werden können (als MIME-Type).</dd>
+ <dt>{{HTTPHeader("Accept-Charset")}}</dt>
+ <dd>Setzt den Server darüber in Kenntnis, welchen Zeichensatz der Client versteht.</dd>
+ <dt>{{HTTPHeader("Accept-Encoding")}}</dt>
+ <dd>Setzt den Server über den Kodierungs-Algorithmus in Kenntnis, üblicherweise ein Kompressionsalgorithmus, der bei Rücksendung einer Ressource benutzt werden kann.</dd>
+ <dt>{{HTTPHeader("Accept-Language")}}</dt>
+ <dd>Setzt den Server über die Sprache in Kenntnis, in welcher er zurücksenden soll. Dies ist ein Hinweis und nicht zwangsweise unter vollständiger Kontrolle des Benutzers: der Server sollte stets darauf achten eine explizite Benutzerauswahl nicht zu überschreiben (etwa die ausgewählte Sprache einer Dropdown-Liste).</dd>
+</dl>
+
+<h2 id="Steuerung">Steuerung</h2>
+
+<dl>
+ <dt>{{HTTPHeader("Expect")}}</dt>
+ <dd>Gibt an, welchen Anforderungen der Server erfüllen muss, um die Anfrage ordnungsgemäß bearbeiten zu können.</dd>
+ <dt>{{HTTPHeader("Max-Forwards")}}</dt>
+ <dd>Eine Ganzzahl, welche die maximal erlaubte Anzahl an Weiterleitungen festlegt. Bei jeder Weiterleitung durch ein Gateway oder einen Proxy wird der Wert um 1 reduziert. Erreicht er 0 bevor die Anfrage ihr Ziel erreicht wird diese verworfen.</dd>
+</dl>
+
+<h2 id="Cookies">Cookies</h2>
+
+<dl>
+ <dt>{{HTTPHeader("Cookie")}}</dt>
+ <dd>Enthält gespeicherte <a href="/de/docs/Web/HTTP/Cookies">HTTP Cookies</a>, die zuvor vom Server mit dem Header {{HTTPHeader("Set-Cookie")}} gesendet wurden.</dd>
+ <dt>{{HTTPHeader("Set-Cookie")}}</dt>
+ <dd>Sendet Cookies vom Server an den Benutzer-Agenten.</dd>
+ <dt>{{HTTPHeader("Cookie2")}} {{obsolete_inline}}</dt>
+ <dd>Enthielt ein HTTP-Cookie, welches zuvor vom Server mit dem Header {{HTTPHeader("Set-Cookie2")}} gesendet wurde, gilt durch die Spezifikation jedoch mittlerweile als veraltet. Benutzen Sie stattdessen {{HTTPHeader("Cookie")}}.</dd>
+ <dt>{{HTTPHeader("Set-Cookie2")}} {{obsolete_inline}}</dt>
+ <dd>Sendete Cookies vom Server an den Benutzer-Agenten, gilt durch die Spezifikation jedoch mittlerweile als veraltet. Benutzen Sie stattdessen {{HTTPHeader("Set-Cookie")}}.</dd>
+</dl>
+
+<h2 id="Cross-origin_Resource_Sharing_(CORS)">Cross-origin Resource Sharing (CORS)</h2>
+
+<p><em>Erfahren Sie <a href="/de/docs/Web/HTTP/CORS">hier</a> mehr zu Cross-origin Resource Sharing (CORS).</em></p>
+
+<dl>
+ <dt>{{HTTPHeader("Access-Control-Allow-Origin")}}</dt>
+ <dd>Gibt an, ob die Antwort geteilt werden kann.</dd>
+ <dt>{{HTTPHeader("Access-Control-Allow-Credentials")}}</dt>
+ <dd>Gibt an, ob die Antwort auf die Anfrage verfügbar gemacht werden kann, wenn das Kennzeichen für Anmeldedaten wahr ist.</dd>
+ <dt>{{HTTPHeader("Access-Control-Allow-Headers")}}</dt>
+ <dd>Wird als Antwort auf eine Vor-Anfrage verwendet, um anzugeben, welche HTTP-Header bei der tatsächlichen Anfrage verwendet werden können.</dd>
+ <dt>{{HTTPHeader("Access-Control-Allow-Methods")}}</dt>
+ <dd>Gibt die Methode(n) an, die beim Zugriff auf die Ressource als Antwort auf eine Vor-Anfrage zulässig sind.</dd>
+ <dt>{{HTTPHeader("Access-Control-Expose-Headers")}}</dt>
+ <dd>Gibt an, welche Header als Teil der Antwort verfügbar gemacht werden können, indem ihre Namen aufgelistet werden.</dd>
+ <dt>{{HTTPHeader("Access-Control-Max-Age")}}</dt>
+ <dd>Gibt an, wie lange die Ergebnisse einer Vor-Anfrage zwischengespeichert werden können.</dd>
+ <dt>{{HTTPHeader("Access-Control-Request-Headers")}}</dt>
+ <dd>Wird verwendet, wenn eine Vor-Anfrage ausgegeben wird, um dem Server mitzuteilen, welche HTTP-Header bei der tatsächlichen Anforderung verwendet werden.</dd>
+ <dt>{{HTTPHeader("Access-Control-Request-Method")}}</dt>
+ <dd>Wird bei der Ausgabe einer Vor-Anfrage verwendet, um dem Server mitzuteilen, welche <a href="/de/docs/Web/HTTP/Methods">HTTP-Methode</a> bei der tatsächlichen Anforderung verwendet wird.</dd>
+ <dt>{{HTTPHeader("Cross-Origin-Resource-Policy")}}</dt>
+ <dd>Der Header <a href="https://fetch.spec.whatwg.org/#cross-origin-resource-policy-header">Cross-Origin-Resource-Policy</a> verhindert, dass andere Domänen die Ressourcen laden.</dd>
+</dl>
+
+<dl>
+ <dt>{{HTTPHeader("Origin")}}</dt>
+ <dd>Gibt an, woher ein Abruf stammt.</dd>
+ <dt>{{HTTPHeader("Timing-Allow-Origin")}}</dt>
+ <dd>Gibt die Ursprünge an, die Werte von Attributen anzeigen dürfen, die über Funktionen der <a href="/de/docs/Web/API/Resource_Timing_API">Resource Timing API</a> abgerufen werden, die andernfalls aufgrund von Ursprungsbeschränkungen als Null gemeldet werden.</dd>
+ <dt>{{HTTPHeader("X-Permitted-Cross-Domain-Policies")}}</dt>
+ <dd>Gibt an, ob eine domänenübergreifende Richtliniendatei (XML) zulässig ist. In der Datei kann eine Richtlinie definiert werden, mit der Web-Clients wie Adobe Flash Player oder Adobe Acrobat (z. B. PDF) die Erlaubnis erteilt werden darf, Daten zwischen Domänen zu verarbeiten.</dd>
+</dl>
+
+<h2 id="Do_Not_Track">Do Not Track</h2>
+
+<dl>
+ <dt>{{HTTPHeader("DNT")}}</dt>
+ <dd>Wird verwendet, um die Tracking-Einstellung des Benutzers auszudrücken.</dd>
+ <dt>{{HTTPHeader("Tk")}}</dt>
+ <dd>Gibt den Tracking-Status an, der auf die entsprechende Anfrage angewendet wurde.</dd>
+</dl>
+
+<h2 id="Downloads">Downloads</h2>
+
+<dl>
+ <dt>{{HTTPHeader("Content-Disposition")}}</dt>
+ <dd>Gibt an, ob die übertragene Ressource inline angezeigt (Standardverhalten, wenn der Header nicht vorhanden ist) oder als Download behandelt werden und der Browser einen "Speichern unter" Dialog anzeigen soll.</dd>
+</dl>
+
+<h2 id="Informationen_zum_Nachrichtenrumpf_(Body)">Informationen zum Nachrichtenrumpf (Body)</h2>
+
+<dl>
+ <dt>{{HTTPHeader("Content-Length")}}</dt>
+ <dd>Gibt die Größe des Body der Entität in Oktetten (Anzahl an 8-Bit Bytes) an, die an den Empfänger gesendet werden.</dd>
+ <dt>{{HTTPHeader("Content-Type")}}</dt>
+ <dd>Gibt den Inhaltstyp der Ressource an.</dd>
+ <dt>{{HTTPHeader("Content-Encoding")}}</dt>
+ <dd>Gibt den Kompressionsalgortihmus an.</dd>
+ <dt>{{HTTPHeader("Content-Language")}}</dt>
+ <dd>Beschreibt die Sprache(n), die für das Publikum bestimmt ist/sind, damit der Benutzer nach seiner bevorzugten Sprache unterscheiden kann.</dd>
+ <dt>{{HTTPHeader("Content-Location")}}</dt>
+ <dd>Gibt einen alternativen Ort für die zurückgegebenen Daten an.</dd>
+</dl>
+
+<h2 id="Proxys">Proxys</h2>
+
+<dl>
+ <dt>{{HTTPHeader("Forwarded")}}</dt>
+ <dd>Enthält Informationen Client zugewandten Seite von Proxyservern, die geändert oder verloren geht, wenn ein Proxy am Pfad der Anfrage beteiligt ist.</dd>
+ <dt>{{HTTPHeader("X-Forwarded-For")}} {{non-standard_inline}}</dt>
+ <dd>Gibt die ursprünglichen IP-Adressen eines Clients an, der über einen HTTP-Proxy oder einen Load Balancer eine Verbindung zu einem Webserver herstellt.</dd>
+ <dt>{{HTTPHeader("X-Forwarded-Host")}} {{non-standard_inline}}</dt>
+ <dd>Gibt den ursprünglichen Host an, den ein Client angefragt hat, um eine Verbindung zu Ihrem Proxy oder Load Balancer herzustellen.</dd>
+ <dt>{{HTTPHeader("X-Forwarded-Proto")}} {{non-standard_inline}}</dt>
+ <dd>Gibt das Protokoll (HTTP oder HTTPS) an, mit dem ein Client eine Verbindung zu Ihrem Proxy oder Load Balancer herstellt.</dd>
+ <dt>{{HTTPHeader("Via")}}</dt>
+ <dd>Wird durch sowohl durch Vorwärts- als auch Rückwärtsproxys hinzugefügt und kann in den Anfrage Headern als auch den Antwort Headern erscheinen und gibt die Proxys an, über die die Nachricht versendet wurde.</dd>
+</dl>
+
+<h2 id="Umleitungen">Umleitungen</h2>
+
+<dl>
+ <dt>{{HTTPHeader("Location")}}</dt>
+ <dd>Gibt die URL an, zu der eine Seite umgeleitet werden soll.</dd>
+</dl>
+
+<h2 id="Anfragenkontext">Anfragenkontext</h2>
+
+<dl>
+ <dt>{{HTTPHeader("From")}}</dt>
+ <dd>Enthält eine Internet-E-Mail-Adresse für einen Benutzer, der den anfordernden Benutzer-Agenten steuert.</dd>
+ <dt>{{HTTPHeader("Host")}}</dt>
+ <dd>Gibt den Domänennamen des Servers (für virtuelles Hosting) und (optional) die TCP-Portnummer an, auf welcher der Server lauscht.</dd>
+ <dt>{{HTTPHeader("Referer")}}</dt>
+ <dd>Die Adresse der vorherigen Webseite, von der aus ein Link auf die aktuell angeforderte Seite folgt.</dd>
+ <dt>{{HTTPHeader("Referrer-Policy")}}</dt>
+ <dd>Gibt an, welche Referrer-Informationen im Header {{HTTPHeader("Referer")}} mit den gesendeten Anfragen enthalten sein sollen.</dd>
+ <dt>{{HTTPHeader("User-Agent")}}</dt>
+ <dd>Enthält einen charakteristischen String, mit der die Netzwerkprotokollpartner den Anwendungstyp, das Betriebssystem, den Softwareanbieter oder die Softwareversion des anfragenden Benutzer-Agenten bestimmen können. Siehe auch die <a href="/de/docs/Web/HTTP/Headers/User-Agent/Firefox">Benutzer-Agenten-String Referenz von Firefox</a>.</dd>
+</dl>
+
+<h2 id="Antwortkontext">Antwortkontext</h2>
+
+<dl>
+ <dt>{{HTTPHeader("Allow")}}</dt>
+ <dd>Listet die von einer Ressource unterstützten HTTP-Anfragemethoden auf.</dd>
+ <dt>{{HTTPHeader("Server")}}</dt>
+ <dd>Enthält Informationen zu der Software, die der Ursprungsserver zur Bearbeitung der Anfrage verwendet.</dd>
+</dl>
+
+<h2 id="Bereichsanfragen">Bereichsanfragen</h2>
+
+<dl>
+ <dt>{{HTTPHeader("Accept-Ranges")}}</dt>
+ <dd>Gibt an, ob der Server Bereichsanfragen unterstützt und wenn ja, in welcher Einheit der Bereich ausgedrückt werden kann.</dd>
+ <dt>{{HTTPHeader("Range")}}</dt>
+ <dd>Gibt den Teil eines Dokuments an, den der Server zurückgeben soll.</dd>
+ <dt>{{HTTPHeader("If-Range")}}</dt>
+ <dd>Erzeugt eine bedingte Bereichanfrage, die nur erfüllt wird, wenn das gegebene ETag oder Datum mit der entfernten Ressource übereinstimmt. Kann verwendet werden, um das Herunterladen von zwei Bereichen von einer inkompatiblen Version der Ressource zu verhindern.</dd>
+ <dt>{{HTTPHeader("Content-Range")}}</dt>
+ <dd>Gibt an, welchem Bereich des Body der gesendete Inhalt angehört.</dd>
+</dl>
+
+<h2 id="Sicherheit">Sicherheit</h2>
+
+<dl>
+ <dt>{{HTTPHeader("Content-Security-Policy")}} ({{Glossary("CSP")}})</dt>
+ <dd>Steuert Ressourcen, die der Benutzer-Agent für eine bestimmte Seite laden darf.</dd>
+ <dt>{{HTTPHeader("Content-Security-Policy-Report-Only")}}</dt>
+ <dd>Webentwickler können mit Richtlinien experimentieren, indem sie ihre Auswirkungen überwachen, jedoch nicht durchsetzen. Berichte über Verstöße bestehen aus {{Glossary("JSON")}}-Dokumenten, die über eine HTTP <code>POST</code> Anfrage an die angegebene URI gesendet werden.</dd>
+ <dt>{{HTTPHeader("Expect-CT")}}</dt>
+ <dd>Erlaubt es Websites, sich für die Berichterstellung und/oder Durchsetzung der Zertifikattransparenzanforderungen zu entscheiden. Dadurch wird verhindert, dass falsch ausgestellte Zertifikate für eine Seite unbemerkt bleiben. Wenn eine Seite den Expect-CT-Header aktiviert, fordert sie den Browser auf zu überprüfen, ob alle Zertifikate für diese Seite in öffentlichen CT-Protokollen angezeigt werden.</dd>
+ <dt>{{HTTPHeader("Feature-Policy")}}</dt>
+ <dd>Stellt einen Mechanismus bereit, um die Verwendung von Browserfunktionen in seinem eigenen Frame und in eingebetteten iFrames zuzulassen und zu verbieten.</dd>
+</dl>
+
+<dl>
+ <dt>{{HTTPHeader("Public-Key-Pins")}} ({{Glossary("HPKP")}})</dt>
+ <dd>Ordnet einen bestimmten kryptografischen öffentlichen Schlüssel einem bestimmten Webserver zu, um das Risiko von {{Glossary("MITM", "Man-in-the-Middle")}}-Angriffen mit gefälschten Zertifikaten zu verringern.</dd>
+ <dt>{{HTTPHeader("Public-Key-Pins-Report-Only")}}</dt>
+ <dd>Sendet Berichte an die im Header angegebene URI zur Protokollierung, während Clients weiterhin eine Verbindung zum Server herstellen können, selbst wenn gegen das Pinning verstoßen wurde.</dd>
+</dl>
+
+<dl>
+ <dt>{{HTTPHeader("Strict-Transport-Security")}} ({{Glossary("HSTS")}})</dt>
+ <dd>Erzwingt die Kommunikation über HTTPS statt HTTP.</dd>
+ <dt>{{HTTPHeader("Upgrade-Insecure-Requests")}}</dt>
+ <dd>Sendet ein Signal an den Server, dass der Client eine verschlüsselte und authentifizierte Antwort bevorzugt und dass die Anweisung {{CSP("upgrade-insecure-request")}} erfolgreich verarbeitet werden kann.</dd>
+</dl>
+
+<dl>
+ <dt>{{HTTPHeader("X-Content-Type-Options")}}</dt>
+ <dd>Deaktiviert das Erraten des MIME-Types durch den Browser und zwingt ihn den MIME-Type im Header {{HTTPHeader("Content-Type")}} zu benutzen.</dd>
+</dl>
+
+<dl>
+ <dt>{{HTTPHeader("X-Download-Options")}}</dt>
+ <dd>Gibt an, dass der Browser (Internet Explorer) nicht die Option zum "Öffnen" einer aus einer Anwendung heruntergeladenen Datei anzeigen sollte, um Phishing-Angriffe zu verhindern, da die Datei sonst im Kontext der Anwendung ausgeführt werden kann.</dd>
+</dl>
+
+<dl>
+ <dt>{{HTTPHeader("X-Frame-Options")}} (XFO)</dt>
+ <dd>Gibt an, ob es einem Browser erlaubt wird eine Seite in einem {{HTMLElement("frame")}}, {{HTMLElement("iframe")}}, {{HTMLElement("embed")}} oder {{HTMLElement("object")}} Element darzustellen.</dd>
+ <dt>{{HTTPHeader("X-Powered-By")}}</dt>
+ <dd>Kann durch Hosting-Umgebungen oder andere Frameworks festgelegt werden und enthält Informationen zu diesen, ohne der Anwendung oder ihren Besuchern einen Nutzen zu bieten. Heben Sie diesen Header auf, um zu verhindern mögliche Schwachstellen preiszugeben.</dd>
+ <dt>{{HTTPHeader("X-XSS-Protection")}}</dt>
+ <dd>Aktiviert Seiten-übergreifende Skript-Filterung.</dd>
+</dl>
+
+<h2 id="Vom_Server_gesendete_Ereignisse">Vom Server gesendete Ereignisse</h2>
+
+<dl>
+ <dt>{{HTTPHeader("Last-Event-ID")}}</dt>
+ <dd>...</dd>
+ <dt>{{HTTPHeader("NEL")}} {{experimental_inline}}</dt>
+ <dd>Definiert einen Mechanismus, mit dem Entwickler eine Netzwerkfehler-Berichterstattungs-Richtlinie deklarieren können.</dd>
+ <dt>{{HTTPHeader("Ping-From")}}</dt>
+ <dd>...</dd>
+ <dt>{{HTTPHeader("Ping-To")}}</dt>
+ <dd>...</dd>
+ <dt>{{HTTPHeader("Report-To")}}</dt>
+ <dd>Kann verwendet werden, um einen Server-Endpunkt anzugeben, an den der Browser Warnmeldungen und Fehlerberichte senden soll.</dd>
+</dl>
+
+<h2 id="Übertragungskodierung">Übertragungskodierung</h2>
+
+<dl>
+ <dt>{{HTTPHeader("Transfer-Encoding")}}</dt>
+ <dd>Gibt die Form der Kodierung an, die zum sicheren Übertragen der Entität an den Benutzer verwendet wird.</dd>
+ <dt>{{HTTPHeader("TE")}}</dt>
+ <dd>Gibt die Übertragungskodierungen an, die der Benutzer-Agent akzeptiert.</dd>
+ <dt>{{HTTPHeader("Trailer")}}</dt>
+ <dd>Ermöglicht dem Absender, am Ende einer Nachricht in mehreren Teilen zusätzliche Felder einzufügen.</dd>
+</dl>
+
+<h2 id="WebSockets">WebSockets</h2>
+
+<dl>
+ <dt>{{HTTPHeader("Sec-WebSocket-Key")}}</dt>
+ <dd>...</dd>
+ <dt>{{HTTPHeader("Sec-WebSocket-Extensions")}}</dt>
+ <dd>...</dd>
+ <dt>{{HTTPHeader("Sec-WebSocket-Accept")}}</dt>
+ <dd>...</dd>
+ <dt>{{HTTPHeader("Sec-WebSocket-Protocol")}}</dt>
+ <dd>...</dd>
+ <dt>{{HTTPHeader("Sec-WebSocket-Version")}}</dt>
+ <dd>...</dd>
+</dl>
+
+<h2 id="Sonstiges">Sonstiges</h2>
+
+<dl>
+ <dt>{{HTTPHeader("Accept-Push-Policy")}} {{experimental_inline}}</dt>
+ <dd>Ein Client kann die gewünschte Push-Richtlinie für eine Anfrage ausdrücken, indem er ein Header-Feld <code><a href="https://tools.ietf.org/html/draft-ruellan-http-accept-push-policy-00#section-3.1">Accept-Push-Policy</a></code> mitsendet.</dd>
+ <dt>{{HTTPHeader("Accept-Signature")}} {{experimental_inline}}</dt>
+ <dd>Ein Client kann das Header-Feld <code><a href="https://wicg.github.io/webpackage/draft-yasskin-http-origin-signed-responses.html#rfc.section.3.7">Accept-Signature</a></code> senden, um anzugeben dass er beabsichtigt von verfügbaren Signaturen gebrauch zu machen und anzuzeigen, welche Art von Signaturen er unterstützt.</dd>
+ <dt>{{HTTPHeader("Alt-Svc")}}</dt>
+ <dd>Kann verwendet werden, um alternative Wege aufzulisten, um diesen Dienst zu erreichen.</dd>
+ <dt>{{HTTPHeader("Date")}}</dt>
+ <dd>Enthält das Datum und die Uhrzeit, zu dem die Nachricht erstellt wurde.</dd>
+ <dt>{{HTTPHeader("Large-Allocation")}}</dt>
+ <dd>Setzt den Browser darüber in Kenntnis, dass die zu ladende Seite eine große Zuordnung durchführen möchte.</dd>
+ <dt>{{HTTPHeader("Link")}}</dt>
+ <dd>Das <code><a href="https://tools.ietf.org/html/rfc5988#section-5">Link</a></code> Entitäten-Header-Feld bietet eine Möglichkeit, eine oder mehrere Links in HTTP-Headern zu serialisieren. Es entspricht semantisch dem HTML Element {{HTMLElement("link")}}.</dd>
+ <dt>{{HTTPHeader("Push-Policy")}} {{experimental_inline}}</dt>
+ <dd>Eine <code><a href="https://tools.ietf.org/html/draft-ruellan-http-accept-push-policy-00#section-3.2">Push-Policy</a></code> definiert das Serververhalten bezüglich Push bei der Verarbeitung einer Anfrage.</dd>
+</dl>
+
+<dl>
+ <dt>{{HTTPHeader("Retry-After")}}</dt>
+ <dd>Gibt an, wie lange der Benutzer-Agent warten soll, bevor eine Folgeanfrage gesendet wird.</dd>
+ <dt>{{HTTPHeader("Signature")}} {{experimental_inline}}</dt>
+ <dd>Das <code><a href="https://wicg.github.io/webpackage/draft-yasskin-http-origin-signed-responses.html#rfc.section.3.1">Signature</a></code> Header-Feld enthält eine Liste von Signaturen für einen Austausch, von welchem jeder Informationen darüber enthält, wie die Autorität dieser Signatur ermittelt und aktualisiert werden kann.</dd>
+ <dt>{{HTTPHeader("Signed-Headers")}} {{experimental_inline}}</dt>
+ <dd>Das <code><a href="https://wicg.github.io/webpackage/draft-yasskin-http-origin-signed-responses.html#rfc.section.5.1.2">Signed-Headers</a></code> Header-Feld identifiziert eine geordnete Liste von Antwort-Header-Feldern, die in eine Signatur aufgenommen werden sollen.</dd>
+ <dt>{{HTTPHeader("Server-Timing")}}</dt>
+ <dd>Kommuniziert eine oder mehrere Metriken und Beschreibungen für den gegebenen Anfrage-Antwort-Zyklus.</dd>
+ <dt>{{HTTPHeader("SourceMap")}}</dt>
+ <dd>Knüpft generierten Code an eine <a href="/de/docs/Tools/Debugger/How_to/Use_a_source_map">Source Map</a>.</dd>
+ <dt>{{HTTPHeader("Upgrade")}}</dt>
+ <dd>Das relevante RFC-Dokument für das <a href="https://tools.ietf.org/html/rfc7230#section-6.7"><code>Upgrade</code> Header-Feld ist RFC 7230, Abschnitt 6.7</a>. Der Standard legt Regeln für das Upgrade oder das Wechseln zu einem anderen Protokoll auf der aktuellen Client-, Server- und Transportprotokollverbindung fest. Mit diesem Header-Standard kann ein Client beispielsweise von HTTP 1.1 zu HTTP 2.0 wechseln, vorausgesetzt der Server beschließt, das <code>Upgrade</code> Header-Feld zu bestätigen und zu implementieren. Keine der Parteien muss die Bedingungen akzeptieren, die im <code>Upgrade</code> Header-Feld angegeben sind. Es kann in Client- und Server-Headern verwendet werden. Wenn das <code>Upgrade</code> Header-Feld angegeben ist, MUSS der Absender auch das <code>Connection</code> Header-Feld mit der angegebenen <code>Upgrade</code> Option senden. Einzelheiten zum <code>Connection</code> Header-Feld finden Sie in <a href="https://tools.ietf.org/html/rfc7230#section-6.1">Abschnitt 6.1</a> des zuvor genannten RFC.</dd>
+ <dt>{{HTTPHeader("X-DNS-Prefetch-Control")}}</dt>
+ <dd>Steuert das DNS-Prefetching, eine Funktion, mit der Browser proaktiv eine Namensauflösung sowohl für Links durchführen, denen der Benutzer folgen könnte, als auch URLs für Elemente, auf die im Dokument verwiesen wird, einschließlich Bilder, CSS, JavaScript, usw.</dd>
+ <dt>{{HTTPHeader("X-Firefox-Spdy")}} {{deprecated_inline}} {{non-standard_inline}}</dt>
+ <dd>...</dd>
+ <dt>{{HTTPHeader("X-Pingback")}} {{non-standard_inline}}</dt>
+ <dd>...</dd>
+ <dt>{{HTTPHeader("X-Requested-With")}}</dt>
+ <dd>...</dd>
+ <dt>{{HTTPHeader("X-Robots-Tag")}} {{non-standard_inline}}</dt>
+ <dd>Wird verwendet, um anzugeben, wie eine Webseite in öffentlichen Suchmaschinenergebnissen indiziert werden soll. Die Kopfzeile entspricht effektiv <code>&lt;meta name="robots" content="..."&gt;</code>.</dd>
+ <dt>{{HTTPHeader("X-UA-Compatible")}} {{non-standard_inline}}</dt>
+ <dd>Wird von Internet Explorer verwendet, um zu signalisieren, welcher Dokumentmodus verwendet werden soll.</dd>
+</dl>
+
+<h2 id="Mitwirken">Mitwirken</h2>
+
+<p>Sie können helfen, indem Sie <a href="/de/docs/MDN/Contribute/Howto/Document_an_HTTP_header">neue Einträge schreiben</a> oder die vorhandenen verbessern.</p>
+
+<h2 id="Siehe_auch">Siehe auch</h2>
+
+<ul>
+ <li>{{interwiki("wikipedia", "Liste der HTTP-Headerfelder")}} auf Wikipedia</li>
+ <li><a href="https://www.iana.org/assignments/message-headers/perm-headers.html">IANA Register</a> (Englisch)</li>
+ <li><a href="https://httpwg.org/specs/">HTTP Arbeitsgruppe</a> (Englisch)</li>
+</ul>
diff --git a/files/de/web/http/headers/referer/index.html b/files/de/web/http/headers/referer/index.html
new file mode 100644
index 0000000000..d61fa0c2f4
--- /dev/null
+++ b/files/de/web/http/headers/referer/index.html
@@ -0,0 +1,87 @@
+---
+title: Referer
+slug: Web/HTTP/Headers/Referer
+tags:
+  - Anfrage
+  - HTTP
+  - Referenz
+  - header
+  - referer
+  - referrer
+translation_of: Web/HTTP/Headers/Referer
+---
+<div>{{HTTPSidebar}}</div>
+
+<p>Der <code><strong>Referer</strong></code> Anfrage-Header beinhaltet die Adresse von der vorher besuchten Webseite, welche einen Link zur aktuell angefragten Seite beinhaltet. Der <code><strong>Referer</strong></code>-Header erlaubt es Server zu sehen, von wo die Personen sie Besuchen und diese Daten zum Beispiel zur Analyse, Logging oder optimiertes Caching zu benutzen.</p>
+
+<div class="warning">
+<p><strong>Wichtig</strong>: Auch wenn dieser Header nützlich ist, kann es ungewollte Konsequenzen für die Sicherheit und Privatsphäre beinhalten. Siehe <a href="https://developer.mozilla.org/en-US/docs/Web/Security/Referer_header:_privacy_and_security_concerns">Referer header: privacy and security concerns</a> für mehr Informationen und Milderungen</p>
+</div>
+
+<p>Merke, dass das Wort referer falsch geschrieben ist. Das richtige Wort ist "referrer". Siehe {{interwiki("wikipedia", "Referrer", "HTTP referer on Wikipedia")}} für mehr Details.</p>
+
+<p>Ein <code>Referer</code>-Header wird von einem Browser nicht gesendet, wenn:</p>
+
+<ul>
+ <li>Der verweisende Ressource ist eine lokale "file" oder "data" URI ist.</li>
+ <li>Eine unsichere HTTP-Anfrage benutzt wird und die verweisende Seite in einem sicheren Protokoll (HTTPS) empfangen wurde.</li>
+</ul>
+
+<table class="properties">
+ <tbody>
+  <tr>
+   <th scope="row">Header-Typ</th>
+   <td>{{Glossary("Request header")}}</td>
+  </tr>
+  <tr>
+   <th scope="row">{{Glossary("Forbidden header name")}}</th>
+   <td>yes</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Syntax">Syntax</h2>
+
+<pre class="syntaxbox">Referer: &lt;url&gt;
+</pre>
+
+<h2 id="Richtlinien">Richtlinien</h2>
+
+<dl>
+ <dt>&lt;url&gt;</dt>
+ <dd>Eine absolute oder partielle Adresse von der vorherigen Webseite, von welcher ein Link zur aktuell angefragen Seite gefolgt wurde. URL-Fragmente (z.B.: "#section") und userinfo (z.B.: "username:password" in "https://username:password@example.com/foo/bar/") sind nicht enthalten.</dd>
+</dl>
+
+<h2 id="Beispiele">Beispiele</h2>
+
+<pre>Referer: https://developer.mozilla.org/en-US/docs/Web/JavaScript</pre>
+
+<h2 id="Spezifikationen">Spezifikationen</h2>
+
+<table class="standard-table">
+ <thead>
+  <tr>
+   <th scope="col">Spezifikation</th>
+   <th scope="col">Titel</th>
+  </tr>
+ </thead>
+ <tbody>
+  <tr>
+   <td>{{RFC("7231", "Referer", "5.5.2")}}</td>
+   <td>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Browser-Kompatibilität">Browser-Kompatibilität</h2>
+
+<p class="hidden">Die Kompatibilitätstabelle auf dieser Seite ist Generiert von struktuierten Daten. Wenn Du zu den Daten beitragen möchtest, schauen sie hier: <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> und sende uns ein Pull-request.</p>
+
+<p>{{Compat("http.headers.Referer")}}</p>
+
+<h2 id="Siehe_auch">Siehe auch</h2>
+
+<ul>
+ <li>{{interwiki("wikipedia", "HTTP_referer", "HTTP referer on Wikipedia")}}</li>
+ <li>{{HTTPHeader("Referrer-Policy")}}</li>
+</ul>
diff --git a/files/de/web/http/headers/server/index.html b/files/de/web/http/headers/server/index.html
new file mode 100644
index 0000000000..fbd162d742
--- /dev/null
+++ b/files/de/web/http/headers/server/index.html
@@ -0,0 +1,69 @@
+---
+title: Server
+slug: Web/HTTP/Headers/Server
+tags:
+  - HTTP
+  - header
+translation_of: Web/HTTP/Headers/Server
+---
+<div>{{HTTPSidebar}}</div>
+
+<p>Der <code><strong>Server</strong></code>-Header beinhaltet Informationen über die Software, die von dem Ursprungsserver verwendet wurde, um die Anfrage zu behandeln.</p>
+
+<p>Zu lange und detailierte Server-Werte sollten vermieden werden, da sie möglicherweise interne Implementations-Details herausgeben, welche es (ein wenig) einfacher für Angreifer machen, bekannte Sicherheitslücken zu finden und auszunutzen.</p>
+
+<table class="properties">
+ <tbody>
+  <tr>
+   <th scope="row">Header-Typ</th>
+   <td>{{Glossary("Response header")}}</td>
+  </tr>
+  <tr>
+   <th scope="row">{{Glossary("Forbidden header name")}}</th>
+   <td>Nein</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Syntax">Syntax</h2>
+
+<pre class="syntaxbox">Server: &lt;produkt&gt;
+</pre>
+
+<h2 id="Directives">Directives</h2>
+
+<dl>
+ <dt>&lt;produkt&gt;</dt>
+ <dd>Der Name der Software oder das (Unter-)Produkt, welches mit Anfragen umgeht.</dd>
+</dl>
+
+<h2 id="Beispiele">Beispiele</h2>
+
+<pre>Server: Apache/2.4.1 (Unix)</pre>
+
+<h2 id="Specifikationen">Specifikationen</h2>
+
+<table class="standard-table">
+ <tbody>
+  <tr>
+   <th scope="col">Specification</th>
+   <th scope="col">Title</th>
+  </tr>
+  <tr>
+   <td>{{RFC("7231", "Server", "7.4.2")}}</td>
+   <td>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Browser-Unterstützung">Browser-Unterstützung</h2>
+
+<p class="hidden">The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> and send us a pull request.</p>
+
+<p>{{Compat("http.headers.Server")}}</p>
+
+<h2 id="Siehe_auch">Siehe auch</h2>
+
+<ul>
+ <li>{{HTTPHeader("Allow")}}</li>
+</ul>
diff --git a/files/de/web/http/headers/set-cookie/index.html b/files/de/web/http/headers/set-cookie/index.html
new file mode 100644
index 0000000000..917e705959
--- /dev/null
+++ b/files/de/web/http/headers/set-cookie/index.html
@@ -0,0 +1,225 @@
+---
+title: Set-Cookie
+slug: Web/HTTP/Headers/Set-Cookie
+tags:
+  - Cookies
+  - HTTP
+  - NeedsTranslation
+  - Reference
+  - Response
+  - TopicStub
+  - header
+  - samesite
+translation_of: Web/HTTP/Headers/Set-Cookie
+---
+<div>{{HTTPSidebar}}</div>
+
+<p><span class="seoSummary">The <strong><code>Set-Cookie</code></strong> HTTP response header is used to send a cookie from the server to the user agent, so the user agent can send it back to the server later. To send multiple cookies, multiple <strong><code>Set-Cookie</code></strong></span> headers should be sent in the same response.</p>
+
+<div class="blockIndicator warning">
+<p>Browsers block frontend JavaScript code from accessing the <code>Set Cookie</code> header, as required by the Fetch spec, which defines <code>Set-Cookie</code> as a <a href="https://fetch.spec.whatwg.org/#forbidden-response-header-name">forbidden response-header name</a> that <a href="https://fetch.spec.whatwg.org/#ref-for-forbidden-response-header-name%E2%91%A0">must be filtered out</a> from any response exposed to frontend code.</p>
+</div>
+
+<p>For more information, see the guide on <a href="/en-US/docs/Web/HTTP/Cookies">Using HTTP cookies</a>.</p>
+
+<table class="properties">
+ <tbody>
+  <tr>
+   <th scope="row">Header type</th>
+   <td>{{Glossary("Response header")}}</td>
+  </tr>
+  <tr>
+   <th scope="row">{{Glossary("Forbidden header name")}}</th>
+   <td>no</td>
+  </tr>
+  <tr>
+   <th scope="row"><a href="https://fetch.spec.whatwg.org/#forbidden-response-header-name">Forbidden response-header name</a></th>
+   <td>yes</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Syntax">Syntax</h2>
+
+<pre class="syntaxbox notranslate">Set-Cookie: &lt;cookie-name&gt;=&lt;cookie-value&gt;
+Set-Cookie: &lt;cookie-name&gt;=&lt;cookie-value&gt;; Expires=&lt;date&gt;
+Set-Cookie: &lt;cookie-name&gt;=&lt;cookie-value&gt;; Max-Age=&lt;non-zero-digit&gt;
+Set-Cookie: &lt;cookie-name&gt;=&lt;cookie-value&gt;; Domain=&lt;domain-value&gt;
+Set-Cookie: &lt;cookie-name&gt;=&lt;cookie-value&gt;; Path=&lt;path-value&gt;
+Set-Cookie: &lt;cookie-name&gt;=&lt;cookie-value&gt;; Secure
+Set-Cookie: &lt;cookie-name&gt;=&lt;cookie-value&gt;; HttpOnly
+
+Set-Cookie: &lt;cookie-name&gt;=&lt;cookie-value&gt;; SameSite=Strict
+Set-Cookie: &lt;cookie-name&gt;=&lt;cookie-value&gt;; SameSite=Lax
+Set-Cookie: &lt;cookie-name&gt;=&lt;cookie-value&gt;; SameSite=None; Secure
+
+// Multiple attributes are also possible, for example:
+Set-Cookie: &lt;cookie-name&gt;=&lt;cookie-value&gt;; Domain=&lt;domain-value&gt;; Secure; HttpOnly
+</pre>
+
+<h2 id="Attributes">Attributes</h2>
+
+<dl>
+ <dt><code>&lt;cookie-name&gt;=&lt;cookie-value&gt;</code></dt>
+ <dd>A cookie begins with a name-value pair:
+ <ul>
+  <li>A <code>&lt;cookie-name&gt;</code> can be any US-ASCII characters, except control characters, spaces, or tabs. It also must not contain a separator character like the following: <code>( ) &lt; &gt; @ , ; : \ " / [ ] ? = { }</code>.</li>
+  <li>A <code>&lt;cookie-value&gt;</code> can optionally be wrapped in double quotes and include any US-ASCII characters excluding control characters, {{glossary("Whitespace")}}, double quotes, comma, semicolon, and backslash. <strong>Encoding</strong>: Many implementations perform URL encoding on cookie values, however it is not required per the RFC specification. It does help satisfying the requirements about which characters are allowed for &lt;cookie-value&gt; though.</li>
+  <li><strong><code>__Secure-</code> prefix</strong>: Cookies names starting with<code> __Secure-</code> (dash is part of the prefix) must be set with the <code>secure</code> flag from a secure page (HTTPS).</li>
+  <li><strong><code>__Host-</code> prefix</strong>: Cookies with names starting with <code>__Host-</code> must be set with the <code>secure</code> flag, must be from a secure page (HTTPS), must not have a domain specified (and therefore aren't sent to subdomains) and the path must be <code>/</code>.</li>
+ </ul>
+ </dd>
+ <dt><code>Expires=&lt;date&gt;</code> {{optional_inline}}</dt>
+ <dd>
+ <p>The maximum lifetime of the cookie as an HTTP-date timestamp. See {{HTTPHeader("Date")}} for the required formatting.</p>
+
+ <p>If unspecified, the cookie becomes a <strong>session cookie</strong>. A session finishes when the client shuts down, and session cookies will be removed.</p>
+
+ <div class="blockIndicator warning">
+ <p><strong>Warning:</strong> Many web browsers have a <em>session restore</em> feature that will save all tabs and restore them next time the browser is used. Session cookies will also be restored, as if the browser was never closed.</p>
+ </div>
+
+ <p>When an Expires date is set, the deadline is relative to the <em>client</em> the cookie is being set on, not the server.</p>
+ </dd>
+ <dt><code>Max-Age=&lt;number&gt; </code>{{optional_inline}}</dt>
+ <dd>Number of seconds until the cookie expires. A zero or negative number will expire the cookie immediately. If both <code>Expires</code> and <code>Max-Age</code> are set, <code>Max-Age</code> has precedence.</dd>
+ <dt><code>Domain=&lt;domain-value&gt;</code> {{optional_inline}}</dt>
+ <dd>Host to which the cookie will be sent.
+ <ul>
+  <li>If omitted, defaults to the host of the current document URL, not including subdomains.</li>
+  <li>Contrary to earlier specifications, leading dots in domain names (<code>.example.com</code>) are ignored.</li>
+  <li>Multiple host/domain values are <em>not</em> allowed, but if a domain <em>is</em> specified, then subdomains are always included.</li>
+ </ul>
+ </dd>
+ <dt><code>Path=&lt;path-value&gt;</code> {{optional_inline}}</dt>
+ <dd>A path that must exist in the requested URL, or the browser won't send the <code>Cookie</code> header.</dd>
+ <dd>The forward slash (<code>/</code>) character is interpreted as a directory separator, and subdirectories will be matched as well: for <code>Path=/docs</code>, <code>/docs</code>, <code>/docs/Web/</code>, and <code>/docs/Web/HTTP</code> will all match.</dd>
+ <dt id="Secure"><code>Secure</code> {{optional_inline}}</dt>
+ <dd>Cookie is only sent to the server when a request is made with the <code>https:</code> scheme (except on localhost), and therefore is more resistent to <a href="https://wiki.developer.mozilla.org/en-US/docs/Glossary/MitM">man-in-the-middle</a> attacks.
+ <p class="note"><strong>Note:</strong> Do not assume that <code>Secure</code> prevents all access to sensitive information in cookies (session keys, login details, etc.). Cookies with this attribute can still be read/modified with access to the client's hard disk, or from JavaScript if the <code>HttpOnly</code> cookie attribute is not set.</p>
+
+ <p class="note"><strong>Note:</strong> Insecure sites (<code>http:</code>) can't set cookies with the <code>Secure</code> attribute (since Chrome 52 and Firefox 52). For Firefox, the <code>https:</code> requirements are ignored when the <code>Secure</code> attribute is set by localhost (since Firefox 75).</p>
+ </dd>
+ <dt id="HttpOnly"><code>HttpOnly</code> {{optional_inline}}</dt>
+ <dd>Forbids JavaScript from accessing the cookie, for example, through the {{domxref("Document.cookie")}} property. Note that a cookie that has been created with HttpOnly will still be sent with JavaScript-initiated requests, e.g. when calling {{domxref("XMLHttpRequest.send()")}} or {{domxref("fetch()")}}. This mitigates attacks against cross-site scripting ({{Glossary("XSS")}}).</dd>
+ <dt id="SameSite"><code>SameSite=&lt;samesite-value&gt;</code> {{optional_inline}}</dt>
+ <dd>Controls whether a cookie is sent with cross-origin requests, providing some protection against cross-site request forgery attacks ({{Glossary("CSRF")}}).</dd>
+ <dd>
+ <div class="note">
+ <p>Standards related to the <a href="/en-US/docs/Web/HTTP/Headers/Set-Cookie/SameSite">SameSite Cookies</a> recently changed such that:</p>
+
+ <ol>
+  <li>The cookie-sending behaviour if <code>SameSite</code> is not specified is <code>SameSite=Lax</code>. Previously the default was that cookies were sent for all requests.</li>
+  <li>Cookies with <code>SameSite=None</code> must now<br>
+   also specify the <code>Secure</code> attribute (i.e. they require a secure context).</li>
+ </ol>
+
+ <p>The options below covers the new behaviour. See the <a href="https://wiki.developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie/SameSite#Browser_compatibility">Browser compatibility</a> table for information about specific browser implementation (rows: "<code>SameSite</code>: Defaults to <code>Lax</code>" and "<code>SameSite</code>: Secure context required").</p>
+ </div>
+ Inline options are:
+
+ <ul>
+  <li><code>Strict</code>: The browser sends the cookie only for same-site requests (that is, requests originating from the same site that set the cookie). If the request originated from a different URL than the current one, no cookies with the <code>SameSite=Strict</code> attribute are sent.</li>
+  <li><code>Lax</code>: The cookie is not sent on cross-site requests, such as calls to load images or frames, but is sent when a user is navigating to the origin site from an external site (e.g. if following a link).<br>
+   This is the default behaviour if the <code>SameSite</code> attribute is not specified.</li>
+  <li><code>None</code>: The browser sends the cookie with both cross-site and same-site requests. The <code>Secure</code> attribute must also be set when <code>SameSite=None</code>!</li>
+ </ul>
+ </dd>
+</dl>
+
+<h2 id="Examples">Examples</h2>
+
+<h3 id="Session_cookie">Session cookie</h3>
+
+<p><strong>Session cookies</strong> are removed when the client shuts down. Cookies are session cookies if they don't specify the <code>Expires</code> or <code>Max-Age</code> attributes.</p>
+
+<pre class="notranslate">Set-Cookie: sessionId=38afes7a8</pre>
+
+<h3 id="Permanent_cookie">Permanent cookie</h3>
+
+<p>Instead of expiring when the client is closed, <strong>permanent cookies</strong> expire at a specific date (<code>Expires</code>) or after a specific length of time (<code>Max-Age</code>).</p>
+
+<pre class="notranslate">Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT
+</pre>
+
+<pre class="notranslate">Set-Cookie: id=a3fWa; Max-Age=2592000</pre>
+
+<h3 id="Invalid_domains">Invalid domains</h3>
+
+<p>A cookie for a domain that does not include the server that set it <a href="https://tools.ietf.org/html/rfc6265#section-4.1.2.3">should be rejected by the user agent</a>.</p>
+
+<p>The following cookie will be rejected if set by a server hosted on <code>originalcompany.com</code>:</p>
+
+<pre class="notranslate">Set-Cookie: qwerty=219ffwef9w0f; Domain=somecompany.co.uk</pre>
+
+<p>A cookie for a sub domain of the serving domain will be rejected.</p>
+
+<p>The following cookie will be rejected if set by a server hosted on <code>example.com</code>:</p>
+
+<pre class="notranslate">Set-Cookie: sessionId=e8bb43229de9; Domain=foo.example.com</pre>
+
+<h3 id="Cookie_prefixes">Cookie prefixes</h3>
+
+<p>Cookies names prefixed with <code>__Secure-</code> or <code>__Host-</code> can be used only if they are set with the <code>secure</code> attribute from a secure (HTTPS) origin.</p>
+
+<p>In addition, cookies with the <code>__Host-</code> prefix must have a path of <code>/</code> (meaning any path at the host) and must not have a <code>Domain</code> attribute.</p>
+
+<div class="blockIndicator warning">
+<p>For clients that don't implement cookie prefixes, you cannot count on these additional assurances, and prefixed cookies will always be accepted.</p>
+</div>
+
+<pre class="notranslate">// Both accepted when from a secure origin (HTTPS)
+Set-Cookie: __Secure-ID=123; Secure; Domain=example.com
+Set-Cookie: __Host-ID=123; Secure; Path=/
+
+// Rejected due to missing Secure attribute
+Set-Cookie: __Secure-id=1
+
+// Rejected due to the missing Path=/ attribute
+Set-Cookie: __Host-id=1; Secure
+
+// Rejected due to setting a Domain
+Set-Cookie: __Host-id=1; Secure; Path=/; Domain=example.com
+</pre>
+
+<h2 id="Specifications">Specifications</h2>
+
+<table class="standard-table">
+ <thead>
+  <tr>
+   <th scope="col">Specification</th>
+   <th scope="col">Title</th>
+  </tr>
+ </thead>
+ <tbody>
+  <tr>
+   <td>{{RFC("6265", "Set-Cookie", "4.1")}}</td>
+   <td>HTTP State Management Mechanism</td>
+  </tr>
+  <tr>
+   <td><a href="https://tools.ietf.org/html/draft-ietf-httpbis-rfc6265bis-05">draft-ietf-httpbis-rfc6265bis-05</a></td>
+   <td>Cookie Prefixes, Same-Site Cookies, and Strict Secure Cookies</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Browser_compatibility">Browser compatibility</h2>
+
+<p class="hidden">The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> and send us a pull request.</p>
+
+<p>{{Compat("http.headers.Set-Cookie", 5)}}</p>
+
+<h2 id="Compatibility_notes">Compatibility notes</h2>
+
+<ul>
+ <li>Starting with Chrome 52 and Firefox 52, insecure sites (<code>http:</code>) can't set cookies with the <code>Secure</code> attribute anymore.</li>
+</ul>
+
+<h2 id="See_also">See also</h2>
+
+<ul>
+ <li><a href="/en-US/docs/Web/HTTP/Cookies">HTTP cookies</a></li>
+ <li>{{HTTPHeader("Cookie")}}</li>
+ <li>{{domxref("Document.cookie")}}</li>
+ <li><a href="/en-US/docs/Web/HTTP/Headers/Set-Cookie/SameSite">SameSite cookies</a></li>
+</ul>
diff --git a/files/de/web/http/headers/set-cookie/samesite/index.html b/files/de/web/http/headers/set-cookie/samesite/index.html
new file mode 100644
index 0000000000..51879c388d
--- /dev/null
+++ b/files/de/web/http/headers/set-cookie/samesite/index.html
@@ -0,0 +1,135 @@
+---
+title: SameSite cookies
+slug: Web/HTTP/Headers/Set-Cookie/SameSite
+tags:
+  - HATTP
+  - IT
+translation_of: Web/HTTP/Headers/Set-Cookie/SameSite
+---
+<div>{{HTTPSidebar}}</div>
+
+<p><span class="seoSummary">The <strong><code>SameSite</code></strong> attribute of the {{HTTPHeader("Set-Cookie")}} HTTP response header allows you to declare if your cookie should be restricted to a <a href="/en-US/docs/Web/HTTP/Cookies#Third-party_cookies">first-party</a> or same-site context. </span></p>
+
+<div class="blockIndicator note">
+<p>Standards related to the Cookie <code>SameSite</code> attribute recently changed such that:</p>
+
+<ul>
+ <li>The cookie-sending behaviour if <code>SameSite</code> is not specified is <code>SameSite=Lax</code>. Previously the default was that cookies were sent for all requests.</li>
+ <li>Cookies with <code>SameSite=None</code> must now also specify the <code>Secure</code> attribute (they require a secure context/HTTPS).</li>
+</ul>
+
+<p>This article documents the new standard. See <a href="#Browser_compatibility">Browser Compatibility</a> below for information about specific versions where the behaviour changed.</p>
+</div>
+
+<h2 id="Values">Values</h2>
+
+<p>The <code>SameSite</code> attribute accepts three values:</p>
+
+<h3 id="Lax"><code>Lax</code></h3>
+
+<p>Cookies are not sent on normal cross-site subrequests (for example to load images or frames into a third party site), but are sent when a user is <em>navigating to</em> the origin site (i.e. when following a link).</p>
+
+<p>This is the default cookie value if <code>SameSite</code> has not been explicitly specified in recent browser versions (see the "SameSite: Defaults to Lax" feature in the Browser Compatibility).</p>
+
+<div class="blockIndicator note">
+<p><code>Lax</code> replaced <code>None</code> as the default value in order to ensure that users have reasonably robust defense against some classes of cross-site request forgery ({{Glossary("CSRF")}}) attacks.</p>
+</div>
+
+<h3 id="Strict"><code>Strict</code></h3>
+
+<p>Cookies will only be sent in a first-party context and not be sent along with requests initiated by third party websites.</p>
+
+<h3 id="None"><code>None</code></h3>
+
+<p>Cookies will be sent in all contexts, i.e in responses to both first-party and cross-origin requests.If <code>SameSite=None</code> is set, the cookie <a href="/en-US/docs/Web/HTTP/Headers/Set-Cookie#Secure"><code>Secure</code></a> attribute must also be set (or the cookie will be blocked).</p>
+
+<h2 id="Fixing_common_warnings">Fixing common warnings</h2>
+
+<h3 id="SameSiteNone_requires_Secure"><code>SameSite=None</code> requires <code>Secure</code></h3>
+
+<p>Warnings like the ones below might appear in your console:</p>
+
+<pre class="syntaxbox notranslate">Cookie “<em>myCookie</em>” rejected because it has the “SameSite=None” attribute but is missing the “secure” attribute.
+
+This Set-Cookie was blocked because it had the "SameSite=None" attribute but did not have the "Secure" attribute, which is required in order to use "SameSite=None".</pre>
+
+<p>The warning appears because any cookie that requests <code>SameSite=None</code> but is not marked <code>Secure</code> will be rejected.</p>
+
+<pre class="example-bad notranslate">Set-Cookie: flavor=choco; SameSite=None</pre>
+
+<p>To fix this, you will have to add the <code>Secure</code> attribute to your <code>SameSite=None</code> cookies.</p>
+
+<pre class="example-good notranslate">Set-Cookie: flavor=choco; SameSite=None; <strong>Secure</strong></pre>
+
+<p>A <a href="#Secure"><code>Secure</code></a> cookie is only sent to the server with an encrypted request over the HTTPS protocol. Note that insecure sites (<code>http:</code>) can't set cookies with the <code>Secure</code> directive.</p>
+
+<div class="blockIndicator note">
+<p>On older browser versions you might simply get a warning that the cookie will be blocked in future. For example:</p>
+
+<pre class="syntaxbox notranslate">Cookie “<em>myCookie</em>” will be soon rejected because it has the “SameSite” attribute set to “None” or an invalid value, without the “secure” attribute. To know more about the “SameSite” attribute, read https://developer.mozilla.org/docs/Web/HTTP/Headers/Set-Cookie/SameSite
+</pre>
+</div>
+
+<h3 id="Cookies_without_SameSite_default_to_SameSiteLax">Cookies without <code>SameSite</code> default to <code>SameSite=Lax</code></h3>
+
+<p>Recent versions of modern browsers provide a more secure default for <code>SameSite</code> to your cookies and so the following message might appear in your console:</p>
+
+<pre class="syntaxbox notranslate">Cookie “<em>myCookie</em>” has “SameSite” policy set to “Lax” because it is missing a “SameSite” attribute, and “SameSite=Lax” is the default value for this attribute.
+</pre>
+
+<p>The warning appears because the <code>SameSite</code> policy for a cookie was not explicitly specified:</p>
+
+<pre class="example-bad notranslate">Set-Cookie: flavor=choco</pre>
+
+<p>You should explicitly communicate the intended <code>SameSite</code> policy for your cookie (rather than relying on browsers to apply <code>SameSite=Lax</code> automatically). This will also improve the experience across browsers as not all of them default to <code>Lax</code> yet.</p>
+
+<pre class="example-good notranslate">Set-Cookie: flavor=choco; <strong>SameSite=Lax</strong></pre>
+
+<h2 id="Example"><strong>Example:</strong></h2>
+
+<pre class="notranslate">RewriteEngine on
+RewriteBase "/"
+RewriteCond "%{HTTP_HOST}"       "^example\.org$" [NC]
+RewriteRule "^(.*)"              "https://www.example.org/index.html" [R=301,L,QSA]
+RewriteRule "^(.*)\.ht$"         "index.php?nav=$1 [NC,L,QSA,CO=RewriteRule;01;https://www.example.org;30/;SameSite=None;Secure]
+RewriteRule "^(.*)\.htm$"        "index.php?nav=$1 [NC,L,QSA,CO=RewriteRule;02;https://www.example.org;30/;SameSite=None;Secure]
+RewriteRule "^(.*)\.html$"       "index.php?nav=$1 [NC,L,QSA,CO=RewriteRule;03;https://www.example.org;30/;SameSite=None;Secure]
+[...]
+RewriteRule "^admin/(.*)\.html$" "admin/index.php?nav=$1 [NC,L,QSA,CO=RewriteRule;09;https://www.example.org:30/;SameSite=Strict;Secure]
+</pre>
+
+<h2 id="Specifications">Specifications</h2>
+
+<table class="standard-table">
+ <thead>
+  <tr>
+   <th scope="col">Specification</th>
+   <th scope="col">Title</th>
+  </tr>
+ </thead>
+ <tbody>
+  <tr>
+   <td>{{RFC("6265", "Set-Cookie", "4.1")}}</td>
+   <td>HTTP State Management Mechanism</td>
+  </tr>
+  <tr>
+   <td><a href="https://tools.ietf.org/html/draft-ietf-httpbis-rfc6265bis-05">draft-ietf-httpbis-rfc6265bis-05</a></td>
+   <td>Cookie Prefixes, Same-Site Cookies, and Strict Secure Cookies</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Browser_compatibility">Browser compatibility</h2>
+
+<p class="hidden">The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> and send us a pull request.</p>
+
+<p>{{Compat("http.headers.Set-Cookie", 5)}}</p>
+
+<h2 id="See_also">See also</h2>
+
+<ul>
+ <li><a href="/en-US/docs/Web/HTTP/Cookies">HTTP cookies</a></li>
+ <li>{{HTTPHeader("Cookie")}}</li>
+ <li>{{domxref("Document.cookie")}}</li>
+ <li><a href="https://web.dev/samesite-cookies-explained/">Samesite cookies explained</a> (web.dev blog)</li>
+</ul>
diff --git a/files/de/web/http/headers/tk/index.html b/files/de/web/http/headers/tk/index.html
new file mode 100644
index 0000000000..f2bd1a3e24
--- /dev/null
+++ b/files/de/web/http/headers/tk/index.html
@@ -0,0 +1,94 @@
+---
+title: Tk
+slug: Web/HTTP/Headers/Tk
+tags:
+  - Antwort
+  - DNT
+  - HTTP
+  - Referenz
+  - header
+  - tracking
+translation_of: Web/HTTP/Headers/Tk
+---
+<div>{{HTTPSidebar}}</div>
+
+<p>Der <strong><code>Tk</code></strong> Antwort-Header beeinhaltet den Tracking-Status der auf die Anfrage zutraf.</p>
+
+<table class="properties">
+ <tbody>
+  <tr>
+   <th scope="row">Header-Typ</th>
+   <td>{{Glossary("Response header")}}</td>
+  </tr>
+  <tr>
+   <th scope="row">{{Glossary("Forbidden header name")}}</th>
+   <td>Nein</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Syntax">Syntax</h2>
+
+<pre class="syntaxbox">Tk: !  (Arbeit im Gange)
+Tk: ?  (Dynamisch)
+Tk: G  (Gateway oder mehrere Partien)
+Tk: N  (Kein Tracking)
+Tk: T  (Tracking)
+Tk: C  (Tracking mit Einwilligung)
+Tk: P  (Mögliche Einwilligung)
+Tk: D  (DNT wird ignoriert)
+Tk: U  (Aktuallisiert)
+</pre>
+
+<h3 id="Directives">Directives</h3>
+
+<dl>
+ <dt>!</dt>
+ <dd>Arbeit im Gange. Der Ursprungsserver testet gerade seine Kommunikation des Tracking-Status.</dd>
+ <dt>?</dt>
+ <dd>Dynamisch. Der Ursprungsserver braucht mehr Information, um den Tracking-Status bestimmen zu können.</dd>
+ <dt>G</dt>
+ <dd>Gateway oder mehrere Partien. Der Server handelt als Gateway zu einem Austausch, der mehrere Partien beinhaltet.</dd>
+ <dt>N</dt>
+ <dd>Kein Tracking.</dd>
+ <dt>T</dt>
+ <dd>Tracking.</dd>
+ <dt>C</dt>
+ <dd>Tracking mit Einwilligung. Der Ursprungsserver glaubt, er hat zuvur eine Einwilligung bekommen, diesen Nutzer, User-Agent oder dieses Gerät zu tracken.</dd>
+ <dt>P</dt>
+ <dd>Mögliche Einwilligung. Der Ursprungsserver weiß nicht, in Echtzeit, ob er eine zuvorige Einwilligung für das tracken dieses Nutzers, User-Agents oder Geräts, bekommen hat. Verspricht, aber keine <code>DNT:1</code>-Daten zu teilen, bis eine Einwilligung festgestellt wurde. Des weiteren, verspricht er alle <code>DNT:1</code>-Daten in den folgenen 24 Stunden zu löschen oder zu de-identifizieren.</dd>
+ <dt>D</dt>
+ <dd>DNT wird ignoriert. Der Ursprungsserver ist nicht fähig, eine Tracking-Präferenz des User-Agents zu respektieren, oder will einfach nicht.</dd>
+ <dt>U</dt>
+ <dd>Aktuallisiert. Die Anfrage hat in eine mögliche Änderung des Tracking-Statueses des Nutzers, User-Agents oder Geräts resultiert.</dd>
+</dl>
+
+<h2 id="Beispiele">Beispiele</h2>
+
+<p>Ein <code>Tk</code>-Header für eine Resource, die von sich selbst sagt, nicht zu tracken, würde so aussehen:</p>
+
+<pre>Tk: N</pre>
+
+<p>Spezifikationen</p>
+
+<table class="standard-table">
+ <tbody>
+  <tr>
+   <th scope="col">Specification</th>
+   <th scope="col">Status</th>
+   <th scope="col">Comment</th>
+  </tr>
+  <tr>
+   <td>{{SpecName('Tracking','#Tk-header-defn', 'Tk header field')}}</td>
+   <td>{{Spec2("Tracking")}}</td>
+   <td>Erstmalige Definition.</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Siehe_auch">Siehe auch</h2>
+
+<ul>
+ <li>{{HTTPHeader("DNT")}} header</li>
+ <li>{{domxref("Navigator.doNotTrack")}}</li>
+</ul>
diff --git a/files/de/web/http/headers/user-agent/index.html b/files/de/web/http/headers/user-agent/index.html
new file mode 100644
index 0000000000..ceb6e8e533
--- /dev/null
+++ b/files/de/web/http/headers/user-agent/index.html
@@ -0,0 +1,139 @@
+---
+title: User-Agent
+slug: Web/HTTP/Headers/User-Agent
+tags:
+  - HTTP
+  - NeedsTranslation
+  - Reference
+  - TopicStub
+  - header
+translation_of: Web/HTTP/Headers/User-Agent
+---
+<div>{{HTTPSidebar}}</div>
+
+<p>The <strong>User-Agent</strong> request header contains a characteristic string that allows the network protocol peers to identify the application type, operating system, software vendor or software version of the requesting software user agent.</p>
+
+<div class="note">
+<p>Please read <a href="/en-US/docs/Web/HTTP/Browser_detection_using_the_user_agent">Browser detection using the user agent</a> and why serving different Web pages or services to different browsers is usually a bad idea.</p>
+</div>
+
+<table class="properties">
+ <tbody>
+  <tr>
+   <th scope="row">Header type</th>
+   <td>{{Glossary("Request header")}}</td>
+  </tr>
+  <tr>
+   <th scope="row">{{Glossary("Forbidden header name")}}</th>
+   <td>no</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Syntax">Syntax</h2>
+
+<pre class="syntaxbox">User-Agent: &lt;product&gt; / &lt;product-version&gt; &lt;comment&gt;
+
+Common format for web browsers:
+
+User-Agent: Mozilla/&lt;version&gt; (&lt;system-information&gt;) &lt;platform&gt; (&lt;platform-details&gt;) &lt;extensions&gt;
+</pre>
+
+<h2 id="Directives">Directives</h2>
+
+<dl>
+ <dt>&lt;product&gt;</dt>
+ <dd>A product identifier</dd>
+ <dt>&lt;product-version&gt;</dt>
+ <dd>A version number of the product.</dd>
+ <dt>&lt;comment&gt;</dt>
+ <dd>Zero or more comments containing sub product information, for example.</dd>
+</dl>
+
+<h2 id="Firefox_UA_string">Firefox UA string</h2>
+
+<p>For more details on Firefox and Gecko based user agent strings, see the <a href="/en-US/docs/Web/HTTP/Headers/User-Agent/Firefox">Firefox user agent string reference</a>. The UA string of Firefox itself is broken down into four components:</p>
+
+<p><strong>Mozilla/5.0 (<em>platform</em>; rv:<em>geckoversion</em>) Gecko/<em>geckotrail</em> Firefox/<em>firefoxversion</em></strong></p>
+
+<ul>
+ <li><em><strong>Mozilla/5.0</strong></em> is the general token that says the browser is Mozilla compatible, and is common to almost every browser today.</li>
+ <li><strong><em>platform</em></strong> describes the native platform the browser is running on (e.g. Windows, Mac, Linux or Android), and whether or not it's a mobile phone. Firefox OS phones simply say "Mobile"; the web is the platform. Note that <strong><em>platform</em></strong> can consist of multiple "; "-separated tokens. See below for further details and examples.</li>
+ <li><strong>rv:<em>geckoversion</em></strong> indicates the release version of Gecko (such as <em>"17.0"</em>). In recent browsers, <strong><em>geckoversion</em></strong> is the same as <strong><em>firefoxversion</em></strong>.</li>
+ <li><strong><em>Gecko/geckotrail</em></strong> indicates that the browser is based on Gecko.</li>
+ <li>On Desktop, <em><strong>geckotrail</strong></em> is the fixed string "20100101"</li>
+ <li><em><strong>Firefox/firefoxversion</strong></em> indicates the browser is Firefox, and provides the version (such as "<em>17.0"</em>).</li>
+</ul>
+
+<h3 id="Examples">Examples</h3>
+
+<pre>Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:47.0) Gecko/20100101 Firefox/47.0
+Mozilla/5.0 (Macintosh; Intel Mac OS X <em>x.y</em>; rv:42.0) Gecko/20100101 Firefox/42.0
+</pre>
+
+<h2 id="Chrome_UA_string">Chrome UA string</h2>
+
+<p>The Chrome (or Chromium/blink-based engines) user agent string is similar to the Firefox format. For compatibility, it adds strings like "KHTML, like Gecko" and "Safari".</p>
+
+<h3 id="Examples_2">Examples</h3>
+
+<pre>Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36</pre>
+
+<h2 id="Opera_UA_string">Opera UA string</h2>
+
+<p>The Opera browser is also based on the blink engine, which is why it almost looks the same, but adds "OPR/&lt;version&gt;".</p>
+
+<h3 id="Examples_3">Examples</h3>
+
+<pre>Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.106 Safari/537.36 OPR/38.0.2220.41</pre>
+
+<h2 id="Safari_UA_string">Safari UA string</h2>
+
+<p>In this example, the user agent string is mobile safari version. It contains the word "Mobile".</p>
+
+<h3 id="Examples_4">Examples</h3>
+
+<pre>Mozilla/5.0 (iPhone; CPU iPhone OS 10_3_1 like Mac OS X) AppleWebKit/603.1.30 (KHTML, like Gecko) Version/10.0 Mobile/14E304 Safari/602.1</pre>
+
+<h2 id="Internet_Explorer_UA_string">Internet Explorer UA string</h2>
+
+<h3 id="Examples_5">Examples</h3>
+
+<pre>Mozilla/5.0 (compatible; MSIE 9.0; Windows Phone OS 7.5; Trident/5.0; IEMobile/9.0)</pre>
+
+<h2 id="Crawler_and_bot_UA_strings">Crawler and bot UA strings</h2>
+
+<h3 id="Examples_6">Examples</h3>
+
+<pre>Googlebot/2.1 (+http://www.google.com/bot.html)</pre>
+
+<h2 id="Specifications">Specifications</h2>
+
+<table class="standard-table">
+ <tbody>
+  <tr>
+   <th scope="col">Specification</th>
+   <th scope="col">Title</th>
+  </tr>
+  <tr>
+   <td>{{RFC("7231", "User-Agent", "5.5.3")}}</td>
+   <td>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Browser_compatibility">Browser compatibility</h2>
+
+<p class="hidden">The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> and send us a pull request.</p>
+
+<p>{{Compat("http.headers.User-Agent")}}</p>
+
+<h2 id="See_also">See also</h2>
+
+<ul>
+ <li><a href="https://hacks.mozilla.org/2013/09/user-agent-detection-history-and-checklist/">User-Agent detection, history and checklist</a></li>
+ <li><a href="/en-US/docs/Web/HTTP/Headers/User-Agent/Firefox">Firefox user agent string reference</a></li>
+ <li>
+  <p><a href="/en-US/docs/Web/HTTP/Browser_detection_using_the_user_agent">Browser detection using the user agent</a></p>
+ </li>
+</ul>
diff --git a/files/de/web/http/headers/x-content-type-options/index.html b/files/de/web/http/headers/x-content-type-options/index.html
new file mode 100644
index 0000000000..3f4220a14d
--- /dev/null
+++ b/files/de/web/http/headers/x-content-type-options/index.html
@@ -0,0 +1,93 @@
+---
+title: X-Content-Type-Options
+slug: Web/HTTP/Headers/X-Content-Type-Options
+translation_of: Web/HTTP/Headers/X-Content-Type-Options
+---
+<div>{{HTTPSidebar}}</div>
+
+<p>Der Header <code><strong>X-Content-Type-Option</strong></code> in HTTP-Antworten wird vom Server dazu benutzt, um anzuzeigen, dass <a href="/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types">MIME-Typen</a>, so wie sie in den {{HTTPHeader("Content-Type")}}-Headern angegeben sind, nicht geändert und somit befolgt werden sollen. Damit lässt sich <a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types#MIME_sniffing">MIME type sniffing</a> ausschließen. Oder anders gesagt: es zeigt, dass die Web-Admins wissen, was sie tun.</p>
+
+<p>Der Header wurde von Microsoft mit dem IE 8 eingeführt, damit Web-Admins die automatische Inhaltserkennung ausschalten können. Die automatische Erkennung konnte dazu führen, dass Inhalt fälschlich als ausführbarer MIME-Typ erkannt wird. Inzwischen haben andere Browser diese Option übernommen, auch wenn deren Erkennungsalgorithmen von vorneherein vorsichtiger waren.</p>
+
+<p>Bei Sicherheits-Audits wird im Allgemeinen erwartet, dass dieser Header gesetzt ist.</p>
+
+<p class="blockIndicator note">Anmerkung: <code>nosniff</code> gilt nur für "<code>script</code>"- und "<code>style</code>"-Typen. Gleichzeitig wird auch Cross-Origin Read Blocking (CORB) für HTML-, TXT-, JSON- und XML- Dateien (ausgenommen SVG bzw. <code>image/svg+xml</code>) aktiviert. Das Anwenden von <code>nosniff</code> bei Bildern erwies sich als <a href="https://github.com/whatwg/fetch/issues/395">inkompatibel zu bestehenden Webseiten</a>.</p>
+
+<table class="properties">
+ <tbody>
+  <tr>
+   <th scope="row">Art des Headers</th>
+   <td>{{Glossary("Antwort-Header")}}</td>
+  </tr>
+  <tr>
+   <th scope="row">{{Glossary("Unzulässiger Header-Name")}}</th>
+   <td>Nein</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Syntax">Syntax</h2>
+
+<pre class="syntaxbox notranslate">X-Content-Type-Options: nosniff
+</pre>
+
+<h2 id="Direktiven">Direktiven</h2>
+
+<dl>
+ <dt><code>nosniff</code></dt>
+ <dd>Verhindert eine Anfrage, wenn der angeforderte Typ
+ <ul>
+  <li>"<code>style</code>" und der MIME-Typ nicht  "<code>text/css</code>" ist, oder</li>
+  <li>"<code>script</code>" und der MIME-Typ kein <a href="https://html.spec.whatwg.org/multipage/scripting.html#javascript-mime-type">JavaScript-MIME-Typ</a> ist.</li>
+ </ul>
+
+ <p>Aktiviert außerdem Cross-Origin Read Blocking für folgende MIME-Typen:</p>
+
+ <ul>
+  <li><code>text/html</code></li>
+  <li><code>text/plain</code></li>
+  <li><code>text/json</code>, <code>application/json</code> und alle anderen MIME-Typen mit JSON-Erweiterung: <code>*/*+json</code></li>
+  <li><code>text/xml</code>, <code>application/xml</code> und alle anderen MIME-Typen mit XML-Erweiterung: <code>*/*+xml</code> (ausgenommen <code>image/svg+xml</code>)</li>
+ </ul>
+ </dd>
+</dl>
+
+<h2 id="Spezifikationen">Spezifikationen</h2>
+
+<table class="standard-table">
+ <tbody>
+  <tr>
+   <th scope="col">Spezifikation</th>
+   <th scope="col">Status</th>
+   <th scope="col">Anmerkung</th>
+  </tr>
+  <tr>
+   <td>{{SpecName("Fetch", "#x-content-type-options-header", "X-Content-Type-Options definition")}}</td>
+   <td>{{Spec2("Fetch")}}</td>
+   <td>Erste Definition</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Browser-Kompatibilität">Browser-Kompatibilität</h2>
+
+<div class="hidden">Die Kompatibilitätstabelle dieser Seite wurde aus strukturierten Daten automatisch generiert. Falls du zu diesen Daten beitragen möchtest, lade dir <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> herunter und sende uns einen Pull Request.</div>
+
+<p>{{Compat("http.headers.X-Content-Type-Options")}}</p>
+
+<h3 id="Browser_spezifische_Anmerkung">Browser spezifische Anmerkung</h3>
+
+<ul>
+ <li>Firefox 72 schaltet <code>X-Content-Type-Options: nosniff</code> für Dokumente der obersten Ebene frei</li>
+</ul>
+
+<h2 id="Siehe_auch">Siehe auch</h2>
+
+<ul>
+ <li>{{HTTPHeader("Content-Type")}}</li>
+ <li>Die <a href="https://blogs.msdn.microsoft.com/ie/2008/09/02/ie8-security-part-vi-beta-2-update/">Original-Definition</a> von X-Content-Type-Options von Microsoft</li>
+ <li>Das Werkzeug <a href="https://observatory.mozilla.org/">Mozilla Observatory</a>, um die Sicherheit von Webseiten (darunter auch diesen Header) zu prüfen</li>
+ <li><a href="https://blog.mozilla.org/security/2016/08/26/mitigating-mime-confusion-attacks-in-firefox/">Mitigating MIME Confusion Attacks in Firefox</a></li>
+ <li><a href="https://fetch.spec.whatwg.org/#corb">Cross-Origin Read Blocking (CORB)</a></li>
+ <li><a href="https://chromium.googlesource.com/chromium/src/+/master/services/network/cross_origin_read_blocking_explainer.md">Google Docs CORB explainer</a></li>
+</ul>
diff --git a/files/de/web/http/headers/x-frame-options/index.html b/files/de/web/http/headers/x-frame-options/index.html
new file mode 100644
index 0000000000..5d18375875
--- /dev/null
+++ b/files/de/web/http/headers/x-frame-options/index.html
@@ -0,0 +1,131 @@
+---
+title: X-Frame-Options
+slug: Web/HTTP/Headers/X-Frame-Options
+translation_of: Web/HTTP/Headers/X-Frame-Options
+---
+<div>{{HTTPSidebar}}</div>
+
+<p>Die <strong><code>X-Frame-Options</code></strong> im <a href="/en-US/docs/Web/HTTP">HTTP</a> Antwort Header kann verwendet werden, um zu bestimmen, ob ein aufrufender Browser die Zielseite in einem {{HTMLElement("frame")}}, {{HTMLElement("iframe")}}, {{HTMLElement("embed")}} oder {{HTMLElement("object")}} rendern also einbetten darf. Webseiten können diesen Header verwenden, um {{interwiki("wikipedia", "clickjacking")}} Attacken abzuwehren, indem sie unterbinden, dass ihr Content in fremden Seiten eingebettet wird.</p>
+
+<p>Die somit erreichte Sicherheit wird nur dann gewährleistet, wenn der User zum Aufruf einen Browser verwendet, der die <code>X-Frame-Options</code> Funktion auch unterstützt.</p>
+
+<table class="properties">
+ <tbody>
+  <tr>
+   <th scope="row">Header type</th>
+   <td>{{Glossary("Response header")}}</td>
+  </tr>
+  <tr>
+   <th scope="row">{{Glossary("Forbidden header name")}}</th>
+   <td>nein</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Syntax">Syntax</h2>
+
+<p>Es gibt drei mögliche Ausprägungen der <code>X-Frame-Options</code>:</p>
+
+<pre class="syntaxbox">X-Frame-Options: deny
+X-Frame-Options: sameorigin
+X-Frame-Options: allow-from https://example.com/
+</pre>
+
+<h3 id="Ausprägungen">Ausprägungen</h3>
+
+<p>Die Nutzung von <code>deny</code> unterbindet nicht nur die Frame-Einbindung von fremden Seiten sondern auch das Einbetten auf derselben Ursprungswebseite. Alternativ kann der Wert <code>sameorigin</code> verwendet werden, wenn die Nutzung innerhalb der gleichen Ursprungswebseite erlaubt sein soll.</p>
+
+<dl>
+ <dt><code>deny</code></dt>
+ <dd>Die Seite kann nicht in einem Frame eingebettet werden, egal welches die aufrufende Webseite ist.</dd>
+ <dt><code>sameorigin</code></dt>
+ <dd>Die Seite kann nur als Frame eingebettet werden, wenn beide von der gleichen Quellseite (same origin) stammen. Die Spezifikation lässt es Browserherstellern offen, auf welcher Ebene dieser Wert greift: auf höchster Ebene, der nächsthöheren oder der gesamten Kette. Es wird jedoch festgestellt, dass die Option wenig nützlich ist, sofern nicht alle Eltern-Webseiten von der gleichen Quelle stammen (siehe {{bug(725490)}}).  Siehe weiterhin {{anch("Browser compatibility")}} zur Browserunterstützung.</dd>
+ <dt><code>allow-from <em>uri</em></code></dt>
+ <dd>Die Seite lässt sich ausschließlich dann einbetten, wenn die einbettende Seite aus der Quelle <em><code>uri</code></em> stammt. Hinweis: In Firefox besteht hier das gleiche Problem wie bei <code>sameorigin</code> -  die Eltern-Frames werden nicht darauf hin geprüft, ob sie aus der gleichen Quelle stammen.</dd>
+</dl>
+
+<h2 id="Beispiele">Beispiele</h2>
+
+<div class="note">
+<p><strong>Hinweis:</strong> Die Nutzung des <code>meta tag</code> innerhalb des Webseiten-Contents hat keinen Effekt! Beispielsweise die Deklaration <code>&lt;meta http-equiv="X-Frame-Options" content="deny"&gt;</code> führt zu keiner Verhaltensänderung. Ausschließlich die Nutzung der HTTP Header (siehe Beispiele) führt zu einer Verhaltensänderung des Browser.</p>
+</div>
+
+<h3 id="Apache_Konfiguration">Apache Konfiguration</h3>
+
+<p>Um einen Apache Webserver zum Senden des <code>X-Frame-Options</code> Headers für alle Webseiten zu bewegen, fügen Sie folgenden Eintrag in die Seiten-Konfiguration ein:</p>
+
+<pre>Header always set X-Frame-Options "sameorigin"
+</pre>
+
+<p>Um Apache so zu konfigurieren, dass <code>X-Frame-Options</code> mit dem Wert <code>deny</code> gesendet wird, fügen Sie folgenden Eintrag in die Seiten-Konfiguration ein:</p>
+
+<pre class="line-numbers  language-html"><code class="language-html">Header set X-Frame-Options "deny"</code></pre>
+
+<p>Um Apache so zu konfigurieren, dass <code>X-Frame-Options</code> mit dem Wert <code>allow-from</code> einen bestimmten Host freigibt, fügen Sie folgenden Eintrag in die Seiten-Konfiguration ein:</p>
+
+<pre class="line-numbers  language-html"><code class="language-html">Header set X-Frame-Options "allow-from https://example.com/"</code></pre>
+
+<h3 id="nginx_Konfiguration">nginx Konfiguration</h3>
+
+<p>Um einen nginx Server zum Senden des <code>X-Frame-Options</code> Header aufzufordern, fügen Sie folgenden Eintrag entweder zu Ihrer http, server oder location Konfiguration hinzu:</p>
+
+<pre>add_header X-Frame-Options sameorigin;
+</pre>
+
+<h3 id="IIS_Konfiguration">IIS Konfiguration</h3>
+
+<p>Um den IIS Server zum Senden des <code>X-Frame-Options</code> Headers aufzufordern, ergänzen Sie folgenden Eintrag entsprechend in Ihrer <code>Web.config</code> Datei:</p>
+
+<pre class="brush: xml">&lt;system.webServer&gt;
+  ...
+
+  &lt;httpProtocol&gt;
+    &lt;customHeaders&gt;
+      &lt;add name="X-Frame-Options" value="sameorigin" /&gt;
+    &lt;/customHeaders&gt;
+  &lt;/httpProtocol&gt;
+
+  ...
+&lt;/system.webServer&gt;
+</pre>
+
+<h3 id="HAProxy_Konfiguration">HAProxy Konfiguration</h3>
+
+<p>Um HAProxy zum Senden des <code>X-Frame-Options</code> Headers aufzufordern, fügen Sie diesen Eintrag zu Ihrer front-end, listen oder backend Konfiguration hinzu:</p>
+
+<pre>rspadd X-Frame-Options:\ sameorigin</pre>
+
+<p>Alternatively, in newer versions:</p>
+
+<pre class="line-numbers language-html"><code class="language-html">http-response set-header X-Frame-Options sameorigin</code></pre>
+
+<h2 id="Spezifikationen">Spezifikationen</h2>
+
+<table class="standard-table">
+ <tbody>
+  <tr>
+   <th scope="col">Spezifikation</th>
+   <th scope="col">Bezeichnung</th>
+  </tr>
+  <tr>
+   <td>{{RFC("7034")}}</td>
+   <td>HTTP Header Field X-Frame-Options</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Browser_Kompatibilität">Browser Kompatibilität</h2>
+
+<p class="hidden">Die hier gelistete Browser-Kompatibilitätstabelle wurde automatisch aus strukturierten Daten erzuegt. Wenn Sie Daten entsprechend ergänzen möchten, tun Sie dies bitte unter der URL <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> und senden Sie uns einen Pull Request.</p>
+
+<p>{{Compat("http.headers.X-Frame-Options")}}</p>
+
+<h2 id="Siehe_auch">Siehe auch</h2>
+
+<ul>
+ <li><a href="https://developer.mozilla.org/docs/Web/HTTP/Headers/Content-Security-Policy/frame-ancestors"><code>frame-ancestors</code> (CSP)</a></li>
+ <li><a class="external" href="https://blogs.msdn.com/b/ie/archive/2009/01/27/ie8-security-part-vii-clickjacking-defenses.aspx">ClickJacking Defenses - IEBlog</a></li>
+ <li><a href="https://blogs.msdn.com/b/ieinternals/archive/2010/03/30/combating-clickjacking-with-x-frame-options.aspx">Combating ClickJacking with X-Frame-Options - IEInternals</a></li>
+ <li><a href="https://tools.ietf.org/html/rfc7034">HTTP Header Field X-Frame-Options - RFC 7034</a></li>
+ <li><a href="https://w3c.github.io/webappsec/specs/content-security-policy/#directive-frame-ancestors">CSP Level 2 frame-ancestors directive</a></li>
+</ul>
diff --git a/files/de/web/http/index.html b/files/de/web/http/index.html
new file mode 100644
index 0000000000..6cf5dfb5e4
--- /dev/null
+++ b/files/de/web/http/index.html
@@ -0,0 +1,366 @@
+---
+title: HTTP
+slug: Web/HTTP
+tags:
+  - HTTP
+  - NeedsTranslation
+  - TopicStub
+translation_of: Web/HTTP
+---
+<div>{{HTTPSidebar}}</div>
+
+<p class="summary"><strong><dfn>Das Hypertext Transfer Protocol (HTTP)</dfn></strong> ist ein <a class="external" href="https://de.wikipedia.org/wiki/OSI-Modell#Schicht_7_.E2.80.93_Anwendungsschicht_.28Application_Layer.29">Anwendungsschicht</a>-Protokoll zum Transportieren von <a class="external" href="https://de.wikipedia.org/wiki/Hypermedia">Hypermedia</a> Dokumenten, wie zum Beispiel <a href="/de/docs/Web/HTML">HTML</a>. Hauptsächlich wird es zur Kommunikation zwischen Webservern und Webbrowsern verwendet, jedoch könnte es theoretisch auch für andere Zwecke benutzt werden. Es folgt einem klassischen <a class="external" href="https://de.wikipedia.org/wiki/Client-Server-Modell">Client-Server-Modell</a>, mit einem Client der die Verbindung eröffnet, indem er eine Anfrage macht und dann wartet, bis es eine Antwort erhält. Außerdem ist es ein <a class="external" href="https://de.wikipedia.org/wiki/Zustandslosigkeit">zustandsloses</a> <a class="external" href="https://de.wikipedia.org/wiki/Netzwerkprotokoll">Protokoll</a>, was bedeutet, dass der Server keine Daten (Zustände) zwischen zwei Anfragen behält.<br>
+ <br>
+ Obwohl oft auf einer TCP/IP Schicht aufgebaut, könnte es auch auf jede andere verlässliche, verbindungsorientierte <a class="external" href="https://de.wikipedia.org/wiki/OSI-Modell#Schicht_4_.E2.80.93_Transportschicht">Transportschicht</a> aufbauen, sofern sie Nachrichten nicht leise verliert, wie es zum Beispiel bei <a class="external" href="https://de.wikipedia.org/wiki/User_Datagram_Protocol">UDP</a> der Fall ist.</p>
+
+<h2 class="Documentation" id="Dokumentation">Dokumentation</h2>
+
+<dl>
+ <dt><a href="/de/docs/Web/HTTP/Headers">HTTP-Header</a></dt>
+ <dd>HTTP-Nachrichten-Header werden verwendet, um genau zu beschreiben, welche Ressource abgeholt wird oder das Verhalten des Servers oder des Clients. Benutzerdefinierte Header können mit dem ' X-' Präfix hinzugefügt werden; Andere sind in einer IANA-Registry aufgeführt, deren ursprünglicher Inhalt in <a href="https://tools.ietf.org/html/rfc4229">RFC 4229</a> definiert wurde. IANA unterhält auch eine <a href="https://www.iana.org/assignments/message-headers/message-headers.xhtml#prov-headers">Registry der vorgeschlagenen neuen HTTP-Nachrichten-Header</a>.</dd>
+ <dt><a href="/de/Web_Development/HTTP_cookies">HTTP-Cookies</a></dt>
+ <dd>Wie Cookies funktionieren, definiert der RFC 6265. Wenn ein Server eine HTTP-Anfrage erhält, kann er einen <code>Set-Cookie</code> Header mit der Antwort senden. Danach wird der Cookie-Wert zusammen mit jeder Anfrage an den gleichen Server in Form eines <code>Cookie</code> HTTP-Headers gesendet. Zusätzlich kann eine Verfallsverzögerung angegeben werden. Einschränkungen einer bestimmten Domäne und eines bestimmten Pfades können ebenfalls festgelegt werden.</dd>
+</dl>
+
+<dl>
+ <dt><a href="/de/docs/HTTP/Basic_access_authentication">Basic access authentication</a></dt>
+ <dd>Im Kontext einer HTTP-Transaktion ist <strong>basic access authentication</strong> eine Methode für einen <a href="/de/docs/Web/API/window.navigator.userAgent">HTTP user agent</a> einen Benutzernamen und ein Kennwort beim Stellen einer Anfrage zu übermitteln.</dd>
+ <dt><a href="/de/HTTP_Pipelining_FAQ">HTTP pipelining FAQ</a></dt>
+ <dd>HTTP/1.1 Pipelining FAQ</dd>
+ <dt><a href="/de/docs/HTTP/Access_control_CORS">HTTP access control (CORS)</a></dt>
+ <dd><strong>Cross-site HTTP requests</strong> sind <a href="/de/docs/HTTP">HTTP</a>-Anfragen nach Ressourcen auf einer <strong>anderen Domain</strong> als der Domain, auf der die Ressource liegt, die die Anfrage initiiert. Beispielsweise initiiert eine Ressource, wie eine Web-Seite, die von Domain A (<code>http://domaina.example</code>) geladen wird, eine Anfrage durch Verwendung des <code>img</code>-Elements (<code>http://domainb.foo/image.jpg</code>) nach einem Bild, das auf Domain B (http://domainb.foo) liegt. Dies tritt heutzutage sehr häufig auf — Seiten laden eine Vielzahl an Ressourcen mittels Cross-site-Verfahren, einschließlich CSS-Stylesheets, Bildern, Skripten und anderen Ressourcen.</dd>
+ <dt><a href="/de/Controlling_DNS_prefetching">Steuern des DNS prefetchings</a></dt>
+ <dd>Firefox 3.5 führt <strong>DNS prefetching</strong> durch. Dies ist eine Funktion durch die Firefox gezielt Domain-Namensauflösung betreibt, sowohl für Verknüpfungen, denen der Benutzer möglicherweise folgt, als auch für URLs von Objekten auf die im Dokument Bezug genommen wird, einschließlich Bildern, CSS, JavaScript und so weiter. Dieses Vorausladen wird im Hintergrund durchgeführt, so dass es wahrscheinlich ist, dass der DNS-Name bereits aufgelöst wurde, wenn er benötigt wird. Dies reduziert die Verzögerung wenn ein Benutzer tatsächlich eine Verknüpfung anklickt.</dd>
+ <dt><a href="/de/docs/HTTP/HTTP_response_codes">HTTP Antwort-Codes</a></dt>
+ <dd>HTTP Antwort-Codes zeigen an, ob eine bestimmte <a href="/de/docs/HTTP">HTTP</a>-Anfrage erfolgreich abgeschlossen wurde. Antworten werden in fünf Klassen zusammengefasst: Informationsantworten, Erfolgsantworten, Weiterleitungen, Client-Fehler und Server-Fehler.</dd>
+</dl>
+
+<h2 id="Die_kurze_Geschichte_zu_HTTP">Die kurze Geschichte zu HTTP</h2>
+
+<p>Since its original conception, as a protocol with one single method (GET) and returning only HTML pages, the HTTP protocol went through several revisions. The first documented version was HTTP/0.9 in 1991, corresponding to the original version. Very simple, it has a rudimentary search capability via the HTML {{ HTMLElement("isindex") }} element and an extension of the URL using the '<code>?</code>' character.</p>
+
+<p>Then, in 1992, a version was published that became, with some minor changes, HTTP/1.0 (finalized in <a class="external" href="https://tools.ietf.org/html/rfc1945">RFC 1945</a> in May 1996). One major improvement over the previous version was the ability to transmit files of different types, like images, videos, scripts, CSS documents, and so on, instead of only HTML files: this is achieved by using <a class="external" href="https://en.wikipedia.org/wiki/Mime_types">MIME types</a> in conjunction with the <code>Content-Type:</code> header.</p>
+
+<p>In 1995, the <a class="external" href="https://www.ietf.org/">IETF</a>  began developing a new version of HTTP, which would become HTTP/1.1. It quickly spread into wide usage, and it was officially standardized in 1997 in <a class="external" href="https://tools.ietf.org/html/rfc2068">RFC 2068</a>, with minor fixes in <a class="external" href="https://tools.ietf.org/html/rfc2616">RFC 2616</a> two years later.</p>
+
+<p>HTTP/1.1 brought the ability to reuse established connections for subsequent requests, greatly improving the performance of the protocol by lowering the latency between them; this is especially useful with complex HTML documents that need to fetch several subsequent files, like images or style sheets. It also brought the <code>Host:</code> header, which allows a single server, listening on a specific port, to receive requests for several websites; this paved the way for colocating numerous websites on one single server, greatly reducing the cost of hosting.</p>
+
+<p>Since then, the HTTP protocol evolved by adding new <a href="/de/HTTP/Headers">headers</a>, defining new behaviors without the need to fundamentally change the protocol. Unknown headers are simply ignored by servers or clients.</p>
+
+<p>HTTP/1.1 is currently being revised by the <a class="external" href="https://tools.ietf.org/wg/httpbis/">IETF HTTPbis Working Group</a>.</p>
+
+<h2 id="Eine_HTTP-Sitzung">Eine HTTP-Sitzung</h2>
+
+<p>Because HTTP is a client-server protocol, an HTTP session consists of three phases:</p>
+
+<ol>
+ <li>The client establishes a TCP connection (or the appropriate connection if the transport layer is not TCP).</li>
+ <li>The client sends its request and then waits for the answer.</li>
+ <li>The server processes the request and sends back its answer, containing a status code and the appropriate data.</li>
+</ol>
+
+<p>Starting with HTTP/1.1, the connection is no longer closed after the third phase, as the client is allowed to issue another request at this point: the second and third phases can therefore be done several times.</p>
+
+<h3 id="Herstellen_einer_Verbindung">Herstellen einer Verbindung</h3>
+
+<p>Because HTTP is a client-server protocol, it always is the client that establishes the connection. Opening a connection in HTTP really is establishing a connection in the underlying transport layer, usually TCP.</p>
+
+<p>With TCP, the default port for an HTTP server on a computer is port 80, though others are often used, like 8000 or 8080. The URL of a page to fetch contains both the domain name and the port number, though the latter can be omitted if it is 80.</p>
+
+<div class="note"><strong>Note:</strong> The client-server model does not allow the server to send data to the client without an explicit request of for it. To work around this problem, web developers use several techniques: pinging the server periodically via the <a href="/de/DOM/XMLHttpRequest">XMLHTTPRequest</a> Javascript object, using the HTML <a href="/de/WebSockets">WebSockets API</a>, or similar protocols.</div>
+
+<h3 id="Senden_einer_Client-Anfrage">Senden einer Client-Anfrage</h3>
+
+<p>Once the connection is established, the user-agent can send its request. (A user-agent is typically a web browser, but need not be.) A client request consists of text directives, separated by CRLF (carriage return, followed by line feed), divided in three blocks:</p>
+
+<ol>
+ <li>The first line contains a request method followed by its parameters:
+  <ul>
+   <li>the path of the document, i.e., an absolute URL without the protocol and the domain name</li>
+   <li>the HTTP protocol version used</li>
+  </ul>
+ </li>
+ <li>The subsequent lines each represent a specific HTTP header, giving the server some information about what kind of data is appropriate (e.g., what language, what MIME types) or some data altering its behavior (e.g., not sending an answer if it is already cached). These HTTP headers form a block that ends with an empty line.</li>
+ <li>The final block is the optional data block, which contains further data and is mainly used by the POST method.</li>
+</ol>
+
+<h4 id="Beispiele_von_Anfragen">Beispiele von Anfragen</h4>
+
+<ul>
+ <li>Fetching the root page of developer.mozilla.org, i.e. <a class="linkification-ext external" href="/">http://developer.mozilla.org/</a>, and telling the server that the user-agent would prefer the page in French, if possible:
+
+  <pre class="notranslate">GET / HTTP/1.1
+Host: developer.mozilla.org
+Accept-Language: fr
+
+</pre>
+
+  <p>Note the final empty line, separating the data block from the headers block. As there is no <code>Content-Length:</code> HTTP header, the data block is empty and the server can process the request as soon as it receives the empty line marking the end of the headers.</p>
+ </li>
+ <li>Sending the result of a form:
+  <pre class="notranslate">POST /contact_form.php HTTP/1.1
+Host: developer.mozilla.org
+Content-Length: 64
+Content-Type: application/x-www-form-urlencoded
+
+name=Joe%20User&amp;request=Send%20me%20one%20of%20your%20catalogue
+</pre>
+ </li>
+</ul>
+
+<h3 id="Die_Struktur_einer_Server-Antwort">Die Struktur einer Server-Antwort</h3>
+
+<p>After the connected agent has sent its request, the web server handles it, and finally sends a response back. Similarly to a client request, a server response is formed of text directives, separated by CRLF, though divided in three different blocks:</p>
+
+<ol>
+ <li>The first line, the <em>status line</em>, consists of an acknowledgment of the HTTP version used followed by a status request (and its meaning in human-readable text).</li>
+ <li>The subsequent lines each represent a specific HTTP header giving the client some information about the data sent (e.g., type, data size, compression algorithm used, hints about caching). Similarly to the block of HTTP headers for a client request, these HTTP headers form a block that ends with an empty line.</li>
+ <li>The final block is the data block, which contains the data (if any).</li>
+</ol>
+
+<h4 id="Beispiele_von_Antworten">Beispiele von Antworten</h4>
+
+<ul>
+ <li>Successful reception of a web page:
+  <pre class="notranslate">HTTP/1.1 200 OK
+Date: Sat, 09 Oct 2010 14:28:02 GMT
+Server: Apache
+Last-Modified: Tue, 01 Dec 2009 20:18:22 GMT
+ETag: "51142bc1-7449-479b075b2891b"
+Accept-Ranges: bytes
+Content-Length: 29769
+Content-Type: text/html
+
+&lt;!DOCTYPE html... <em><strong>(here comes the 29769 bytes of the requested web page)</strong></em>
+
+</pre>
+ </li>
+ <li>Notification that the requested resource has been permanently moved:
+  <pre class="notranslate">HTTP/1.1 301 Moved Permanently
+Server: Apache/2.2.3 (Red Hat)
+Content-Type: text/html; charset=iso-8859-1
+Date: Sat, 09 Oct 2010 14:30:24 GMT
+Location: <a class="linkification-ext" href="../../../../">https://developer.mozilla.org/</a> <strong><em>(this is the</em><em> new link to the resource; it is expected that the user-agent will fetch it)</em></strong>
+Keep-Alive: timeout=15, max=98
+Accept-Ranges: bytes
+Via: Moz-Cache-zlb05
+Connection: Keep-Alive
+X-Cache-Info: caching
+X-Cache-Info: caching
+Content-Length: 325 <em>(<strong>the content contains a default page to display if the user-agent is not able to follow the link)</strong></em>
+
+&lt;!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"&gt;
+&lt;html&gt;&lt;head&gt;
+&lt;title&gt;301 Moved Permanently&lt;/title&gt;
+&lt;/head&gt;&lt;body&gt;
+&lt;h1&gt;Moved Permanently&lt;/h1&gt;
+&lt;p&gt;The document has moved &lt;a href="<a class="linkification-ext" href="../../../../">https://developer.mozilla.org/</a>"&gt;here&lt;/a&gt;.&lt;/p&gt;
+&lt;hr&gt;
+&lt;address&gt;Apache/2.2.3 (Red Hat) Server at developer.mozilla.org Port 80&lt;/address&gt;
+&lt;/body&gt;&lt;/html&gt;
+
+</pre>
+ </li>
+ <li>Notification that the requested resource doesn't exist:
+  <pre class="notranslate">HTTP/1.1 404 Not Found
+Date: Sat, 09 Oct 2010 14:33:02 GMT
+Server: Apache
+Last-Modified: Tue, 01 May 2007 14:24:39 GMT
+ETag: "499fd34e-29ec-42f695ca96761;48fe7523cfcc1"
+Accept-Ranges: bytes
+Content-Length: 10732
+Content-Type: text/html
+
+&lt;!DOCTYPE html... <strong><em>(contains a site-customized page helping the user to find the missing resource)</em></strong>
+
+</pre>
+ </li>
+</ul>
+
+<h3 id="Persistente_Verbindungen">Persistente Verbindungen</h3>
+
+<p>Persistent connections were introduced in HTTP/1.1. They allow transmitting several requests on the same TCP connection (or on the specific connected transport layer if the HTTP is not built upon TCP/IP). This has several advantages:</p>
+
+<ul>
+ <li>Because the connection can be reused, requests can be <a href="/de/HTTP_Pipelining_FAQ">pipelined</a> to save part of the connection latency.</li>
+ <li>By opening and closing fewer TCP connections, CPU time is saved.</li>
+ <li>Network congestion is diminished by lowering the total amount of TCP packets (fewer opening and closing TCP packets).</li>
+ <li>The TCP stack has more time to detect network congestion and to adapt its sending and receiving windows.</li>
+ <li>HTTP is more adaptive: the cost for trying a feature is considerably lowered as an error response no longer leads to closing the connection.</li>
+</ul>
+
+<h2 id="HTTP-Antfragemethoden">HTTP-Antfragemethoden</h2>
+
+<p>The request method indicates the action to be performed by the server. The HTTP/1.1 standard defines seven methods and allows other methods to be added later. Over the years, a few ones have been added in standards like <a href="/de/WebDAV">WebDAV</a>. The  <a class="external" href="https://tools.ietf.org/wg/httpbis/" rel="external nofollow">IETF HTTPbis Working Group</a> is currently working on an IANA registry to list them all. If a server receives a request method that it doesn't know, it must return a <code><a href="/de/HTTP/HTTP_response_codes#501" rel="internal">501 Not implemented</a></code> response; if it knows the method but is configured not to answer it, it must return a <code><a href="/de/HTTP/HTTP_response_codes#501" rel="internal">405 Method not allowed</a></code> response. Two methods are required to be supported: HEAD and GET; all others are optional.</p>
+
+<p>Two specific semantics are defined in the standard and are crucial for web developers: the <em>safety</em> property and the <em>idempotent</em> property.</p>
+
+<h3 id="Sichere_Methoden">Sichere Methoden</h3>
+
+<p>A <dfn>safe method</dfn> is a method that doesn't have any side-effects on the server. In other words, this property means that the method must be used only for <em>retrieval</em> of data. The safe HTTP methods defined in HTTP/1.1 are:</p>
+
+<ul>
+ <li>GET, used to retrieve information identified by the request URI. This information may be generated on the fly or the GET may be conditional if any of the {{ httpheader("If-Modified-Since") }}, {{ httpheader("If-Unmodified-Since") }}, {{ httpheader("If-Match") }}, {{ httpheader("If-None-Match") }} or {{ httpheader("If-Range") }} HTTP headers are set. In that latter case the information is only sent back if all the conditions are fulfilled.</li>
+ <li>HEAD, which is identical to GET but without the message body sent.</li>
+</ul>
+
+<div class="note"><strong>Notes: </strong>
+
+<ul>
+ <li>Any safe method is also <em>idempotent</em>.</li>
+ <li>Not having any side-effects means, for the GET method, that it <strong>must</strong> not be used to trigger an action outside the server, like an order in an e-commerce site. If a side-effect is wanted, a non-<em>idempotent</em> method should be used, like POST.</li>
+ <li>When a page is generated on the fly by a script, the script engine may calculate the page as if it was requested by a GET and then strip the data block. This does not cause problem as long as the GET as implemented in the script is <em>safe</em>, but if it has any side-effects (like triggering an order on an e-commerce site), the HEAD method will trigger it too. It is up to the web developer to ensure that both the GET and HEAD method are safely implemented.</li>
+</ul>
+</div>
+
+<h3 id="Idempotente_Methoden">Idempotente Methoden</h3>
+
+<p>An <dfn>idempotent method</dfn> is a method such that the side-effects on the server of several identical requests with the method are the same as the side-effects of one single request.</p>
+
+<ul>
+ <li>HEAD and GET, like any safe method, are also idempotent, as a safe method doesn't have side-effects on the server.</li>
+ <li>PUT is the way to upload a new resource on the server. If the resource already exists and is different, it is replaced; if it doesn't exist, it is created.</li>
+ <li>DELETE removes a resource from the server.</li>
+</ul>
+
+<h3 id="Andere_Methoden">Andere Methoden</h3>
+
+<ul>
+ <li>POST is the way to trigger an action on the server. It has side-effects and can be used to trigger an order, to modify a database, to post a message in a forum, and so on.</li>
+ <li>OPTIONS is a request for communication options available on the chain between the client and the server (through eventual proxies); this method is typically sent before any <a href="/de/HTTP_access_control#Preflighted_requests">preflighted cross-origin request</a>, in order to know whether it is safe to do it.
+  <div class="note"><strong>Note:</strong> <a href="/de/HTTP_access_control#Preflighted_requests">Preflighted cross-origin requests</a> cannot be done on servers which don't allow or support the OPTIONS method.</div>
+ </li>
+ <li>TRACE is a kind of ping between the client and the server (through eventual proxies).</li>
+</ul>
+
+<p>Many more methods, such as PROPFIND or PATCH are defined in other standards-track RFCs of the IETF, like WebDAV.</p>
+
+<p>The CONNECT method is defined in <a class="external" href="https://tools.ietf.org/html/rfc2817">RFC 2817</a>.</p>
+
+<h3 id="HTTP-Anfragemethoden_in_HTML-Formularen">HTTP-Anfragemethoden in HTML-Formularen</h3>
+
+<p>In HTML, different HTTP request methods can be specified in the {{ htmlattrxref("method", "form") }} attribute of the {{ HTMLElement("form") }} element, but also to the {{ htmlattrxref("formmethod", "input") }} of the {{ HTMLElement("input") }} and {{ HTMLElement("button") }} elements. But not all HTTP methods can be used with these attributes; only GET and POST method are allowed by the HTML specification. See <a href="https://softwareengineering.stackexchange.com/a/211790">this StackExchange answer why other HTTP request methods are not allowed by the HTML specification</a>.</p>
+
+<div class="note"><strong>Note</strong>: The choice of a GET or POST method for HTML forms is not neutral. Because the GET method is a <a href="/de/HTTP#Safe_methods">safe method</a>, it should be used only in cases where no side-effect is expected; e.g., it shouldn't be used to transmit an order, as this order is a side-effect. In all cases where such side-effects are expected, the POST method should be used.</div>
+
+<h2 id="HTTP-Antwort-Codes">HTTP-Antwort-Codes</h2>
+
+<p>When answering a client request, the server sends back a three-digit number indicating whether the request was successfully processed. These codes can be grouped in five categories:</p>
+
+<ul>
+ <li><dfn>Informational responses</dfn> (of the form <code>1xx</code>) are provisional responses. Most of the time neither the end user, nor the web developer or webmaster should have to bother with these. The most common is the <code><a href="/de/HTTP/HTTP_response_codes#100">100 Continue</a></code> response, indicating that the client should continue to send its request.
+
+  <div class="note"><strong>Note:</strong> No information response codes were defined in the HTTP/1.0, and therefore they must not be sent back when this version of the protocol is used.</div>
+ </li>
+ <li><dfn>Success responses</dfn> (of the form <code>2xx</code>) are for successfully processed requests. The <code><a href="/de/HTTP/HTTP_response_codes#200">200 OK</a></code> response is by far the most common of these responses, but the <code><a href="/de/HTTP/HTTP_response_codes#206">206 Partial Content</a></code> is also often seen when fetching a file or some media data like video or audio.</li>
+ <li><dfn>Redirection responses</dfn> (of the form <code>3xx</code>) indicate that the resource that the client requested has moved and the server is not able to serve it directly. Most of these responses contain some location information telling where to find the requested resource; user-agents often then retrieve it without further user interaction. The most common responses of this type are <code><a href="/de/HTTP/HTTP_response_codes#301">301 Moved Permanently</a></code>, indicating that the URI given is no longer valid and has been moved to another place, and <code><a href="/de/HTTP/HTTP_response_codes#302">302 Found</a></code> which indicates that the resource has been <em>temporarily</em> moved to another place.
+  <div class="note"><strong>Note:</strong> For webmasters, it is recommended to set up a <code><a href="/de/HTTP/HTTP_response_codes#301">301 Moved Permanently</a></code> redirection when moving pages to another URI, during a site reorganization for example. That allows users following links to still reach the resource and it also teaches search engines and other services the new location of the resource, so that they can transfer their metadata to it. It is also important to add adequate cache headers to the <code><a href="/de/HTTP/HTTP_response_codes#301">301 Moved Permanently</a></code> response so that this information is cached by the client and prevents it from making unnecessary requests to the original URI prior to fetching the resource itself.</div>
+ </li>
+ <li><dfn>Client error responses</dfn> (of the form <code>4xx</code>) indicate that the request sent by the client is either invalid, incomplete, or doesn't have enough rights to be performed. The most common such response is <code><a href="/de/HTTP/HTTP_response_codes#404">404 Not Found</a></code> which is sent back when the URI requested doesn't exist, but a few others are often presented to the end user, like <code><a href="/de/HTTP/HTTP_response_codes#400">400 Bad Request</a></code> sent when the request isn't a valid HTTP request (as this shouldn't happen but may indicate a bug into the user agent or, less likely, the server) or <code><a href="/de/HTTP/HTTP_response_codes#403">403 Forbidden</a></code>, sent when the client request a resource that does exist but isn't allowed to be transmitted (like a directory content).</li>
+ <li><dfn>Server error responses</dfn> (of the form <code>5xx</code>) indicate that the server had a problem handling the valid client request. The two most common such responses are <code><a href="/de/HTTP/HTTP_response_codes#500">500 Internal Server Error</a></code>, a generic error code indicating a bug in the server or <code><a href="/de/HTTP/HTTP_response_codes#503">503 Service Unavailable</a></code> indicating that the server cannot process the request due to a temporary problem, like a disabled service for maintenance purposes or the non-availability of a database.</li>
+</ul>
+
+<p>A web developer shouldn't encounter many other response codes, but people building requests using the <code><a href="/de/nsIXMLHttpRequest">XMLHTTPRequest</a></code> function may hit <a href="/de/HTTP/HTTP_response_codes">less usual response codes</a>.</p>
+
+<h3 id="Mehr_über_Weiterleitungsantworten">Mehr über Weiterleitungsantworten</h3>
+
+<p>Starting in Gecko 9.0 {{ geckoRelease("9.0") }}, redirections (such as 301 and 307) that specify a <code>javascript:</code> URI are no longer performed. Instead, a bad connection error is presented. This helps avoid cross-site scripting attacks. See {{ bug(255119) }} if you want more details.</p>
+
+<h2 id="HTTP-Headers">HTTP-Headers</h2>
+
+<p>HTTP-Kopfdaten ermöglichen the client and the server to pass additional information with the request or the response. A request header consists of its case-insensitive name followed by a colon ':', then by its value (without CRLF in it). Leading white space before the value is ignored.</p>
+
+<p>Headers are grouped according the context in which they may appear:</p>
+
+<dl>
+ <dt>Allgemeine Kopfdaten</dt>
+ <dd>These headers apply to both requests and responses but are unrelated to the data eventually transmitted in the body. They therefore apply only to the message being transmitted. There are only a few of them and new ones cannot been added without increasing the version number of the HTTP protocol. The exhaustive list for HTTP/1.1 is {{ httpheader("Cache-Control") }}, {{ httpheader("Connection") }}, {{ httpheader("Date") }}, {{ httpheader("Pragma") }}, {{ httpheader("Trailer") }}, {{ httpheader("Transfer-Encoding") }}, {{ httpheader("Upgrade") }}, {{ httpheader("Via") }} and {{ httpheader("Warning") }}.</dd>
+ <dt>Anfragekopfdaten</dt>
+ <dd>These headers give more precise information about the resource to be fetched or about the client itself. Among them one find <a href="/de/HTTP_Caching_FAQ">cache-related headers</a>, transforming a GET method in a conditional GET, like {{ httpheader("If-Modified-Since") }}, user-preference information like {{ httpheader("Accept-Language") }} or {{ httpheader("Accept-Charset") }} or plain client information like {{ httpheader("User-Agent") }}. New request headers cannot officially be added without increasing the version number of the HTTP protocol. But, it is common for new request headers to be added if both the server and the client agree on their meaning. In that case, a client should not assume that they will be handled adequately by the server; unknown request headers are handled as <em>entity headers</em>.</dd>
+ <dt>Antwortkopfdaten</dt>
+ <dd>These headers give more information about the resource sent back, like its real location ({{ httpheader("Location") }}) or about the server itself, like its name and version ({{ httpheader("Server") }}). New response headers cannot be added without increasing the version number of the HTTP protocol. But, it is common for new response headers to be added if both the server and the client agree on their meaning. In that case, a server should not assume that they will be handled adequately by the client ; unknown response headers are handled as <em>entity headers</em>.</dd>
+ <dt>Entitätskopfdaten</dt>
+ <dd>Diese Kopfdaten beinhalten mehr Informationen über den Körper der Entität, wie ihre Länge ({{ httpheader("Content-Length") }}), eine Identifikationsprüfsumme ({{ httpheader("Content-MD5") }}) oder ihren MIME-Typ ({{ httpheader("Content-Type") }}). Neue Entitätskopfdaten können ohne Erhöhung der Versionsnummer des HTTP-Protokolls hinzugefügt werden.</dd>
+</dl>
+
+<p>Kopfdaten können auch nach ihrer Handhabung durch puffernde und nicht-puffernde Proxys gruppiert werden:</p>
+
+<dl>
+ <dt>Ende-zu-Ende-Kopfdaten</dt>
+ <dd>These headers must be transmitted to the final recipient of the message; that is, the server for a request message or the client for a response message. Such a header means that intermediate proxies must retransmit it unmodified and also that caches must store it.</dd>
+ <dt>Sprung-zu-Sprung-Kopfdaten</dt>
+ <dd>Diese Kopfdaten sind nur für eine einzelne Verbindung auf Transportebene von Bedeutung und dürfen von Proxys nicht weitergeleitet oder gepuffert werden. Solche Kopfdaten sind: {{ httpheader("Connection") }}, {{ httpheader("Keep-Alive") }}, {{ httpheader("Proxy-Authenticate") }}, {{ httpheader("Proxy-Authorization") }}, {{ httpheader("TE") }}, {{ httpheader("Trailers") }}, {{ httpheader("Transfer-Encoding") }} und {{ httpheader("Upgrade") }}. Zu Beachten ist, dass nur Sprung-zu-Sprung-Kopfdaten {{ httpheader("Connection") }} bei der Verwendung der Allgemeinen Kopfdaten gesetzt werden dürfen.</dd>
+</dl>
+
+<p>In order to learn about the specific semantic of each header, see its entry in the <a href="/de/HTTP/Headers">comprehensive list of HTTP headers</a>.</p>
+
+<h3 id="Nützliche_Anfragekopfdaten">Nützliche Anfragekopfdaten</h3>
+
+<p>Among the numerous <a href="/de/HTTP/Headers">HTTP request headers</a>, several are especially useful when set correctly. If you are building your own requests, by using <code><a href="/de/DOM/XMLHttpRequest">XMLHTTPRequest</a></code> or when writing an extension and sending <a href="/de/Setting_HTTP_request_headers">custom HTTP requests via XPCOM</a>, then it is important to ensure the presence of headers that are often set by browsers based on the preferences of the user.</p>
+
+<dl>
+ <dt>Steuern der Ressourcensprache</dt>
+ <dd>Most user-agents, like Firefox, allow the user to set a preference for the language for receiving a resource. The browser translate this into an {{ httpheader("Accept-Language") }} header. It is good practice for web developers, when building specific HTTP requests, to include such a header too.</dd>
+ <dt>Verwenden des bedingten GET</dt>
+ <dd>Caching is a major tool to accelerate the display of web pages. Even when parts of a webpage are refreshed via an <code><a href="/de/DOM/XMLHttpRequest">XMLHTTPRequest</a></code>:, it is a good idea to use the {{ httpheader("If-Modified-Since") }} header (and other similar ones) in order to fetch the new content only if it has changed. This approach lowers the burden on the network.</dd>
+</dl>
+
+<h3 id="Nützliche_Antwortkopfdaten">Nützliche Antwortkopfdaten</h3>
+
+<p>The configuration of a web server is a critical part to ensure good performance and optimal security of a web site. Among the <a href="/de/HTTP/Headers">numerous HTTP response headers</a>, several are of specific importance and should be configured on the server</p>
+
+<h4 id="Restricting_framing">Restricting framing</h4>
+
+<p>Several cross-site scripting (XSS) attacks take advantage of the ability to put third-party content inside an {{ HTMLElement("frame") }} or {{ HTMLElement("iframe") }}. In order to mitigate that risk, modern browsers have introduced the <code><a href="/de/Security/CSP/CSP_policy_directives#frame-ancestors">CSP frame-ancestors directive</a></code>. By setting it with the value <code>'none'</code>, it prevents the browser from displaying this resource inside of a frame. Using it on critical resources (like those containing a formularies or critical information) will reduce the risk caused by XSS attacks. Note that this specific HTTP response header is not the only way to mitigate XSS risks; other techniques, like setting some <a href="/de/Security/CSP/Introducing_Content_Security_Policy">Content Security Policies</a>, may be helpful too.</p>
+
+<h4 id="Komprimierung">Komprimierung</h4>
+
+<p>Minimizing the amount of data transferred accelerates the display of a web page. Though most techniques, like <a href="/de/CSS/CSS_Sprites">CSS Sprites</a>, should be applied on the site itself, compression of data must be set at the web server level. If set, resources requested by the client with an {{ httpheader("Accept-Encoding") }} request header are compressed using the appropriate method and sent back with a {{ httpheader("Content-Encoding") }} response header. Setting these in Apache 2 servers is done by using the <a class="external" href="https://httpd.apache.org/docs/2.4/mod/mod_deflate.html">mod_deflate module</a>.</p>
+
+<div class="note"><strong>Note:</strong> Be aware that not all data formats can be efficiently compressed. Already-compressed media data, like JPEG images or most audio and video formats, do not shrink using another pass of compression. In fact, they often become larger due to the overhead of the compression method. It is important not to try to compress these resource types any further; there is no advantage in size and the compression/decompression mechanism is resource-intensive.</div>
+
+<h4 id="Steruern_des_Puffers">Steruern des Puffers</h4>
+
+<p><a href="/de/HTTP_Caching_FAQ">HTTP Caching</a> is a technique that prevents the same resource from being fetched several times if it hasn't change. Configuring the server with the correct response headers allows the user-agent to adequately cache the data. In order to do that, be sure that:</p>
+
+<ul>
+ <li>Any static resource provides an {{ httpheader("Expires") }} response header that is set to far in the future. That way, the resource may stay in the cache until the user-agent flushes it for its own reasons (like reaching its cache size limit).
+  <div class="note"><strong>Note: </strong>On Apache, use the ExpiresDefault directive in your .htaccess to define a relative expires: <code>ExpiresDefault "access plus 1 month"</code>.</div>
+ </li>
+ <li>Any dynamic resource provides a {{ httpheader("Cache-control") }} response header. Theoretically, any HTTP request done through a <a href="/de/HTTP#Safe_Methods">safe method</a> (GET or HEAD) or even through a solely <a href="/de/HTTP#Idempotent_Methods">idempotent one</a> (DELETE, PUT) may be cached; but in practice careful study is needed to determine if the caching of the response may lead to inappropriate side-effects.</li>
+</ul>
+
+<h4 id="Setzen_der_richtigen_MIME-Typen">Setzen der richtigen MIME-Typen</h4>
+
+<p>The MIME type is the mechanism to tell the client the kind of document transmitted: the extension of a file name has no meaning on the web. It is therefore important that the server is correctly set up so that the correct MIME type is transmitted with each document: user-agents often use this MIME-type to determine what default action to do when a resource is fetched.</p>
+
+<div class="note"><strong>Note: </strong>
+
+<ul>
+ <li>On Apache, one can match file extensions with a given MIME type in the .htaccess using the <code>AddType</code> type directive like <code>AddType image/jpeg jpg.</code></li>
+ <li>Most web servers send unknown-type resources using the default <code>application/octet-stream</code> MIME type; for security reasons, most browsers, like Firefox, do not allow setting a custom default action for such resources and force the user to store it to disk in order to use it. Some common cases of often incorrectly configured servers happens for the following file types:
+  <ul>
+   <li>
+    <p>Rar-encoded files. The ideal would be to be able to set the real type of the encoded files; this often is not possible (as it may not be known to the server and these files may contains several resource of different types). In that case, configure the server to send the <code>application/x-rar-compressed </code>MIME type or some users won't be able to define a useful default action for them.</p>
+   </li>
+   <li>
+    <p>Audio and video files. Only resources with the proper MIME Type will be recognized and played, using a {{ HTMLElement("video") }} or {{ HTMLElement("audio") }} elements. Be sure to <a href="/de/Media_formats_supported_by_the_audio_and_video_elements">use the correct MIME type for audio and video resources</a>.</p>
+   </li>
+   <li>
+    <p>Proprietary file types. Pay special attention when serving a proprietary file type. Be sure not to forget to add an x-prefixed type for it; otherwise, special handling won't be possible. This is especially true with resources using the <a class="external" href="https://en.wikipedia.org/wiki/Keyhole_Markup_Language">Keyhole Markup Language</a>, which should be served as <code>application/vnd.google-earth.kml+xml </code>for an optimal user experience.</p>
+   </li>
+  </ul>
+ </li>
+</ul>
+</div>
+
+<h2 id="Siehe_auch">Siehe auch</h2>
+
+<ul>
+ <li><a href="/de/Controlling_DNS_prefetching">Controlling DNS prefetching</a></li>
+ <li>The <a href="/de/HTTP_Pipelining_FAQ">HTTP pipelining FAQ</a></li>
+ <li><a href="/de/Web_Development/HTTP_cookies">HTTP cookies</a></li>
+ <li><a href="/de/docs/HTTP/Headers">HTTP Headers</a></li>
+ <li><a href="/de/docs/HTTP/Basic_access_authentication">Basic access authentication</a></li>
+ <li><a href="/de/docs/HTTP/Access_control_CORS">HTTP access control (CORS)</a></li>
+</ul>
diff --git a/files/de/web/http/methods/connect/index.html b/files/de/web/http/methods/connect/index.html
new file mode 100644
index 0000000000..6372973577
--- /dev/null
+++ b/files/de/web/http/methods/connect/index.html
@@ -0,0 +1,84 @@
+---
+title: CONNECT
+slug: Web/HTTP/Methods/CONNECT
+translation_of: Web/HTTP/Methods/CONNECT
+---
+<div>{{HTTPSidebar}}</div>
+
+<div>
+<p>Die <strong>Methode HTTP <code>CONNECT</code></strong> startet die bidirektionale Kommunikation mit der angeforderten Ressource. Es kann verwendet werden, um einen Tunnel zu öffnen.</p>
+
+<p>Beispielsweise kann die CONNECT-Methode verwendet werden, um auf Websites zuzugreifen, die {{Glossary("SSL")}} ({{Glossary("HTTPS")}}) verwenden. Der Client fordert einen HTTP-Proxy-Server auf, die TCP-Verbindung zum gewünschten Ziel zu tunneln. Der Server fährt dann fort, die Verbindung im Namen des Clients herzustellen. Sobald die Verbindung vom Server hergestellt wurde, fährt der Proxy-Server mit dem Proxy des TCP-Streams zum und vom Client fort.</p>
+</div>
+
+<p><code>CONNECT </code>ist eine Hop-by-Hop-Methode.</p>
+
+<table class="properties">
+ <tbody>
+  <tr>
+   <th scope="row">Request hat einen Inhalt</th>
+   <td>Nein</td>
+  </tr>
+  <tr>
+   <th scope="row">Erfolgreicher response hat einen Inhalt</th>
+   <td>Ja</td>
+  </tr>
+  <tr>
+   <th scope="row">{{Glossary("Safe")}}</th>
+   <td>Nein</td>
+  </tr>
+  <tr>
+   <th scope="row">{{Glossary("Idempotent")}}</th>
+   <td>Nein</td>
+  </tr>
+  <tr>
+   <th scope="row">{{Glossary("Cacheable")}}</th>
+   <td>Nein</td>
+  </tr>
+  <tr>
+   <th scope="row">Erlaubt in <a href="/en-US/docs/Web/Guide/HTML/Forms">HTML forms</a></th>
+   <td>Nein</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Syntax">Syntax</h2>
+
+<pre class="syntaxbox">CONNECT www.example.com:443 HTTP/1.1
+</pre>
+
+<h2 id="Beispiel">Beispiel</h2>
+
+<p>Einige Proxy-Server benötigen möglicherweise die Berechtigung, um einen Tunnel zu erstellen. Siehe auch den Header {{HTTPHeader("Proxy-Authorization")}}.</p>
+
+<pre class="line-numbers  language-html">CONNECT server.example.com:80 HTTP/1.1
+Host: server.example.com:80
+Proxy-Authorization: basic aGVsbG86d29ybGQ=</pre>
+
+<h2 id="Spezifikationen">Spezifikationen</h2>
+
+<table class="standard-table">
+ <tbody>
+  <tr>
+   <th scope="col">Specification</th>
+   <th scope="col">Title</th>
+  </tr>
+  <tr>
+   <td>{{RFC("7231", "CONNECT", "4.3.6")}}</td>
+   <td>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Browser_Kompatibilität">Browser Kompatibilität</h2>
+
+<p class="hidden">The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> and send us a pull request.</p>
+
+<p>{{Compat("http.methods.CONNECT")}}</p>
+
+<h2 id="Siehe_auch">Siehe auch</h2>
+
+<ul>
+ <li>{{Glossary("Proxy server")}}</li>
+ <li>{{HTTPHeader("Proxy-Authorization")}}</li>
+</ul>
diff --git a/files/de/web/http/methods/delete/index.html b/files/de/web/http/methods/delete/index.html
new file mode 100644
index 0000000000..c054a834f9
--- /dev/null
+++ b/files/de/web/http/methods/delete/index.html
@@ -0,0 +1,98 @@
+---
+title: DELETE
+slug: Web/HTTP/Methods/DELETE
+translation_of: Web/HTTP/Methods/DELETE
+---
+<div>{{HTTPSidebar}}</div>
+
+<p>Die <strong>Request-Methode HTTP DELETE</strong> löscht die angegebene Ressource.</p>
+
+<p> </p>
+
+<table class="properties">
+ <tbody>
+  <tr>
+   <th scope="row">Request hat einen Körper</th>
+   <td>Kann</td>
+  </tr>
+  <tr>
+   <th scope="row">Erfolgreiche Response hat Körper</th>
+   <td>Kann</td>
+  </tr>
+  <tr>
+   <th scope="row">{{Glossary("Safe")}}</th>
+   <td>Nein</td>
+  </tr>
+  <tr>
+   <th scope="row">{{Glossary("Idempotent")}}</th>
+   <td>Ja</td>
+  </tr>
+  <tr>
+   <th scope="row">{{Glossary("Cacheable")}}</th>
+   <td>Nein</td>
+  </tr>
+  <tr>
+   <th scope="row">In <a href="https://developer.mozilla.org/en-US/docs/Web/Guide/HTML/Forms">HTML Formularen</a> erlaubt </th>
+   <td>Nein</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Syntax">Syntax</h2>
+
+<pre class="syntaxbox">DELETE /file.html HTTP/1.1
+</pre>
+
+<h2 id="Beispiel">Beispiel</h2>
+
+<h3 id="Request">Request</h3>
+
+<pre>DELETE /file.html HTTP/1.1</pre>
+
+<h3 id="Responses">Responses</h3>
+
+<p>Bei erfolgreicher Anwendung einer <code>DELETE</code>-Methode sind mehrere Antwortzustandscodes möglich:</p>
+
+<ul>
+ <li>Einen {{HTTPStatus("202")}} (<code>Akzeptiert</code>) Statuscode, wenn die Aktion wahrscheinlich erfolgreich sein wird, aber noch nicht durchgeführt wurde.</li>
+ <li>Einen {{HTTPStatus("204")}} (<code>Kein Inhalt</code>) Statuscode, wenn die Aktion durchgeführt wurde und keine weiteren Informationen zu liefern sind.</li>
+ <li>Einen {{HTTPStatus("200")}} (<code>OK</code>) Statuscode, wenn die Aktion ausgeführt wurde und die Antwortnachricht eine Darstellung enthält, die den Status beschreibt.</li>
+</ul>
+
+<pre>HTTP/1.1 200 OK
+Date: Wed, 21 Oct 2015 07:28:00 GMT
+
+&lt;html&gt;
+  &lt;body&gt;
+    &lt;h1&gt;File deleted.&lt;/h1&gt;
+  &lt;/body&gt;
+&lt;/html&gt;</pre>
+
+<h2 id="Spezifikationen">Spezifikationen</h2>
+
+<table class="standard-table">
+ <thead>
+  <tr>
+   <th scope="col">Specification</th>
+   <th scope="col">Title</th>
+  </tr>
+ </thead>
+ <tbody>
+  <tr>
+   <td>{{RFC("7231", "DELETE", "4.3.5")}}</td>
+   <td>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Browser_Kompatibilität">Browser Kompatibilität</h2>
+
+<p class="hidden">The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> and send us a pull request.</p>
+
+<p>{{Compat("http.methods.DELETE")}}</p>
+
+<h2 id="Siehe_auch">Siehe auch</h2>
+
+<ul>
+ <li>HTTP status: {{HTTPStatus("200")}}, {{HTTPStatus("202")}}, {{HTTPStatus("204")}}</li>
+</ul>
diff --git a/files/de/web/http/methods/get/index.html b/files/de/web/http/methods/get/index.html
new file mode 100644
index 0000000000..b0ab2b3654
--- /dev/null
+++ b/files/de/web/http/methods/get/index.html
@@ -0,0 +1,75 @@
+---
+title: GET
+slug: Web/HTTP/Methods/GET
+tags:
+  - Anfragemethode
+  - HTTP
+  - Referenz
+translation_of: Web/HTTP/Methods/GET
+---
+<div>{{HTTPSidebar}}</div>
+
+<p>Die <strong>HTTP <code>GET</code> Methode</strong> fordert eine Darstellung einer spezifischen Ressource an. Anfragen die <code>GET</code> benutzen, sollten nur Daten abholen.</p>
+
+<table class="properties">
+ <tbody>
+  <tr>
+   <th scope="row">Anfrage hat einen Inhalt (Body)</th>
+   <td>Nein</td>
+  </tr>
+  <tr>
+   <th scope="row">Erfolgreiche Antwort hat einen Inhalt (Body)</th>
+   <td>Ja</td>
+  </tr>
+  <tr>
+   <th scope="row">{{Glossary("Safe")}}</th>
+   <td>Ja</td>
+  </tr>
+  <tr>
+   <th scope="row">{{Glossary("Idempotent")}}</th>
+   <td>Ja</td>
+  </tr>
+  <tr>
+   <th scope="row">{{Glossary("Cacheable")}}</th>
+   <td>Ja</td>
+  </tr>
+  <tr>
+   <th scope="row">Erlaubt in HTML Formularen</th>
+   <td>Ja</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Syntax">Syntax</h2>
+
+<pre class="syntaxbox">GET /index.html
+</pre>
+
+<h2 id="Spezifikation">Spezifikation</h2>
+
+<table class="standard-table">
+ <tbody>
+  <tr>
+   <th scope="col">Spezifikation</th>
+   <th scope="col">Titel</th>
+  </tr>
+  <tr>
+   <td>{{RFC("7231", "GET", "4.3.1")}}</td>
+   <td>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Browserkompatibilität">Browserkompatibilität</h2>
+
+<p class="hidden">The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> and send us a pull request.</p>
+
+<p>{{Compat("http.methods.GET")}}</p>
+
+<h2 id="Siehe_auch">Siehe auch</h2>
+
+<ul>
+ <li><a href="/en-US/docs/Web/HTTP/Headers">HTTP Headers</a></li>
+ <li>{{HTTPHeader("Range")}}</li>
+ <li><a href="/en-US/docs/Web/HTTP/Methods/POST">POST</a></li>
+</ul>
diff --git a/files/de/web/http/methods/index.html b/files/de/web/http/methods/index.html
new file mode 100644
index 0000000000..ddeff2a293
--- /dev/null
+++ b/files/de/web/http/methods/index.html
@@ -0,0 +1,75 @@
+---
+title: HTTP request methods
+slug: Web/HTTP/Methods
+tags:
+  - HTTP
+  - Methods
+  - NeedsTranslation
+  - Reference
+  - TopicStub
+translation_of: Web/HTTP/Methods
+---
+<div>{{HTTPSidebar}}</div>
+
+<p>HTTP defines a set of <strong>request methods</strong> to indicate the desired action to be performed for a given resource. Although they can also be nouns, these request methods are sometimes referred as <em>HTTP verbs</em>. Each of them implements a different semantic, but some common features are shared by a group of them: e.g. a request method can be {{glossary("safe")}}, {{glossary("idempotent")}}, or {{glossary("cacheable")}}.</p>
+
+<dl>
+ <dt><code><a href="/en-US/docs/Web/HTTP/Methods/GET">GET</a></code></dt>
+ <dd>The <code>GET</code> method requests a representation of the specified resource. Requests using <code>GET</code> should only retrieve data.</dd>
+ <dt><code><a href="/en-US/docs/Web/HTTP/Methods/HEAD">HEAD</a></code></dt>
+ <dd>The <code>HEAD</code> method asks for a response identical to that of a <code>GET</code> request, but without the response body.</dd>
+ <dt><code><a href="/en-US/docs/Web/HTTP/Methods/POST">POST</a></code></dt>
+ <dd>The <code>POST</code> method is used to submit an entity to the specified resource, often causing a change in state or side effects on the server.</dd>
+ <dt><code><a href="/en-US/docs/Web/HTTP/Methods/PUT">PUT</a></code></dt>
+ <dd>
+ <p>The <code>PUT</code> method replaces all current representations of the target resource with the request payload.</p>
+ </dd>
+ <dt><code><a href="/en-US/docs/Web/HTTP/Methods/DELETE">DELETE</a></code></dt>
+ <dd>The <code>DELETE</code> method deletes the specified resource.</dd>
+ <dt><code><a href="/en-US/docs/Web/HTTP/Methods/CONNECT">CONNECT</a></code></dt>
+ <dd>
+ <p>The <code>CONNECT</code> method establishes a tunnel to the server identified by the target resource.</p>
+ </dd>
+ <dt><code><a href="/en-US/docs/Web/HTTP/Methods/OPTIONS">OPTIONS</a></code></dt>
+ <dd>The <code>OPTIONS</code> method is used to describe the communication options for the target resource.</dd>
+ <dt><code><a href="/en-US/docs/Web/HTTP/Methods/TRACE">TRACE</a></code></dt>
+ <dd>
+ <p>The <code>TRACE</code> method performs a message loop-back test along the path to the target resource.</p>
+ </dd>
+ <dt><code><a href="/en-US/docs/Web/HTTP/Methods/PATCH">PATCH</a></code></dt>
+ <dd>The <code>PATCH</code> method is used to apply partial modifications to a resource.</dd>
+</dl>
+
+<h2 id="Specifications">Specifications</h2>
+
+<table class="standard-table">
+ <tbody>
+  <tr>
+   <th scope="col">Specification</th>
+   <th scope="col">Title</th>
+   <th scope="col">Comment</th>
+  </tr>
+  <tr>
+   <td>{{RFC("7231", "Request methods", "4")}}</td>
+   <td>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</td>
+   <td>Specifies GET, HEAD, POST, PUT, DELETE, CONNECT, OPTIONS, TRACE.</td>
+  </tr>
+  <tr>
+   <td>{{RFC("5789", "Patch method", "2")}}</td>
+   <td>PATCH Method for HTTP</td>
+   <td>Specifies PATCH.</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Browser_compatibility">Browser compatibility</h2>
+
+<p class="hidden">To contribute to this compatibility data, please write a pull request against this file: <a href="https://github.com/mdn/browser-compat-data/blob/master/http/methods.json">https://github.com/mdn/browser-compat-data/blob/master/http/methods.json</a>.</p>
+
+<p>{{Compat("http/methods")}}</p>
+
+<h2 id="See_also">See also</h2>
+
+<ul>
+ <li><a href="/en-US/docs/Web/HTTP/Headers">HTTP headers</a></li>
+</ul>
diff --git a/files/de/web/http/status/100/index.html b/files/de/web/http/status/100/index.html
new file mode 100644
index 0000000000..d409a1cade
--- /dev/null
+++ b/files/de/web/http/status/100/index.html
@@ -0,0 +1,46 @@
+---
+title: 100 Continue
+slug: Web/HTTP/Status/100
+tags:
+  - HTTP
+  - Informationell
+  - Statuscode
+translation_of: Web/HTTP/Status/100
+---
+<div>{{HTTPSidebar}}</div>
+
+<p>Der HTTP <strong><code>100 Continue</code></strong> Statuscode zeigt an, dass bisher alles in Ordnung ist und der Client mit der Anfrage fortfahren oder ihn ignorieren kann, sofern sie schon beendet ist.</p>
+
+<p>Damit ein Server die Header der Anfrage überprüft, muss ein Client in seiner ursprünglichen Anfrage ein <code>Expect: 100-continue</code> senden und einen <code>100 Continue</code> Statuscode als Antwort bekommen bevor der Inhalt gesendet wird.</p>
+
+<h2 id="Status">Status</h2>
+
+<pre class="syntaxbox">100 Continue</pre>
+
+<h2 id="Spezifikationen">Spezifikationen</h2>
+
+<table class="standard-table">
+ <tbody>
+  <tr>
+   <th scope="col">Spezifikation</th>
+   <th scope="col">Titel</th>
+  </tr>
+  <tr>
+   <td>{{RFC("7231", "100 Continue" , "6.2.1")}}</td>
+   <td>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Browser-Kompatibilität">Browser-Kompatibilität</h2>
+
+<p class="hidden">The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> and send us a pull request.</p>
+
+<p>{{Compat("http.status.100")}}</p>
+
+<h2 id="Siehe_auch">Siehe auch</h2>
+
+<ul>
+ <li>{{HTTPHeader("Expect")}}</li>
+ <li>{{HTTPStatus(417)}}</li>
+</ul>
diff --git a/files/de/web/http/status/200/index.html b/files/de/web/http/status/200/index.html
new file mode 100644
index 0000000000..55b7cb9c81
--- /dev/null
+++ b/files/de/web/http/status/200/index.html
@@ -0,0 +1,57 @@
+---
+title: 200 OK
+slug: Web/HTTP/Status/200
+tags:
+  - '200'
+  - Erfolg
+  - HTTP
+  - HTTP-Statuscode
+  - Statuscode
+  - ok
+translation_of: Web/HTTP/Status/200
+---
+<div>{{HTTPSidebar}}</div>
+
+<p>Der HTTP-Statuscode <strong><code>200 OK</code></strong> gibt an, dass eine Anfrage erfolgreich verlaufen ist. Eine 200-Antwort ist standardmäßig im Cache speicherbar.</p>
+
+<p>Die Bedeutung eines Erfolgs hängt von der Art der Anfragemethode ab:</p>
+
+<ul>
+ <li>{{HTTPMethod("GET")}}: Die Datei wurde aufgerufen und wird im Body der Nachricht übertragen.</li>
+ <li>{{HTTPMethod("HEAD")}}: Die Entitätsüberschriften befinden sich im Body der Nachricht</li>
+ <li>{{HTTPMethod("POST")}}: Die Datei, welche das Ergebnis der Aktion darstellt, befindet sich im Body der Nachricht.</li>
+ <li>{{HTTPMethod("TRACE")}}: Der Body der Nachricht enthält die Anfrage so, wie sie der Server erhalten hat.</li>
+</ul>
+
+<p>Der Erfolg eines {{HTTPMethod("PUT")}} oder eines {{HTTPMethod("DELETE")}} ist oft kein <code>200</code> <code>OK</code> sondern ein {{HTTPStatus("204")}} <code>No Content</code> (oder ein {{HTTPStatus("201")}} <code>Created</code>, wenn die Datei das erste mal hochgeladen wird.).</p>
+
+<h2 id="Status">Status</h2>
+
+<pre class="syntaxbox">200 OK</pre>
+
+<h2 id="Spezifikationen">Spezifikationen</h2>
+
+<table class="standard-table">
+ <tbody>
+  <tr>
+   <th scope="col">Spezifikation</th>
+   <th scope="col">Titel</th>
+  </tr>
+  <tr>
+   <td>{{RFC("7231", "200 OK" , "6.3.1")}}</td>
+   <td>Hypertext Transfer Protocol (HTTP/1.1): Semantik und Inhalt</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Browser-Kompatibilität">Browser-Kompatibilität</h2>
+
+<p class="hidden">Die Kompabilitätstabelle welche sich in dieser Seite befindet wurde aus strukturierten Daten generiert. Wenn Sie dazu beitragen wollen, besuchen Sie bitte <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> und schicken Sie uns eine pull-request.</p>
+
+<p>{{Compat("http.status.200")}}</p>
+
+<h2 id="Siehe_auch">Siehe auch</h2>
+
+<ul>
+ <li><a href="/en-US/docs/Web/HTTP/Methods">HTTP request methods</a></li>
+</ul>
diff --git a/files/de/web/http/status/201/index.html b/files/de/web/http/status/201/index.html
new file mode 100644
index 0000000000..e5ff236f90
--- /dev/null
+++ b/files/de/web/http/status/201/index.html
@@ -0,0 +1,43 @@
+---
+title: 201 Created
+slug: Web/HTTP/Status/201
+translation_of: Web/HTTP/Status/201
+---
+<div>{{HTTPSidebar}}</div>
+
+<p>Der Antwortcode HTTP <strong><code>201 Created</code></strong> Erfolgsstatus zeigt an, dass die Anfrage erfolgreich war und zur Erstellung einer Ressource geführt hat. Die neue Ressource wird effektiv erstellt, bevor diese Antwort zurückgesendet wird, und die neue Ressource wird im Hauptteil der Nachricht zurückgegeben, wobei ihre Position entweder die URL der Anforderung oder der Inhalt des {{HTTPHeader("Location")}} Headers ist.</p>
+
+<p>Der übliche Anwendungsfall für diesen Statuscode ist das Ergebnis einer {{HTTPMethod("POST")}} Anfrage.</p>
+
+<h2 id="Status">Status</h2>
+
+<pre class="syntaxbox notranslate">201 Created</pre>
+
+<h2 id="Spezifikationen">Spezifikationen</h2>
+
+<table class="standard-table">
+ <thead>
+  <tr>
+   <th scope="col">Spezifikation</th>
+   <th scope="col">Titel</th>
+  </tr>
+ </thead>
+ <tbody>
+  <tr>
+   <td>{{RFC("7231", "201 Created" , "6.3.2")}}</td>
+   <td>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Browserkompatibilität">Browserkompatibilität</h2>
+
+<div class="hidden">Die Kompatibilitätstabelle auf dieser Seite wird aus strukturierten Daten generiert. Wenn Sie zu den Daten beitragen möchten, besuchen Sie bitte <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> und senden Sie uns eine Pull-Anfrage.</div>
+
+<p>{{Compat("http.status.201")}}</p>
+
+<h2 id="Siehe_auch">Siehe auch</h2>
+
+<ul>
+ <li><a href="/en-US/docs/Web/HTTP/Methods">HTTP request methods</a></li>
+</ul>
diff --git a/files/de/web/http/status/302/index.html b/files/de/web/http/status/302/index.html
new file mode 100644
index 0000000000..4e4df4bb9f
--- /dev/null
+++ b/files/de/web/http/status/302/index.html
@@ -0,0 +1,54 @@
+---
+title: 302 Found
+slug: Web/HTTP/Status/302
+tags:
+  - HTTP
+  - HTTP-Statuscode
+  - Statuscode
+  - Weiterleitung
+translation_of: Web/HTTP/Status/302
+---
+<div>{{HTTPSidebar}}</div>
+
+<div><span lang="de">Der HTTP-Statuscode </span><code><strong>302 Found</strong></code><span lang="de"> besagt, dass die angeforderte Ressource vorübergehend auf die URL verschoben wurde, die durch den {{HTTPHeader("Location")}}-Header angegeben wurde. Ein Browser folgt der Weiterleitung auf diese Seite, aber Suchmaschinen aktualisieren ihre Links auf die Ressource nicht (In SEO-Sprech sagt man, dass der 'link-juice' nicht an die neue URL gesendet wird).</span></div>
+
+<div></div>
+
+<div>Obwohl die Spezifikation verlangt, dass die Anfragemethode (und der Body der Anfrage) beim Folgen auf die Weiterleitung nicht verändert wird, setzen das nicht alle User-Agents um - man findet immer noch Programme, die hier Fehler haben Daher ist zu empfehlen, den Code <code>302</code> nur als Antwort auf die Anfragemethoden {{HTTPMethod("GET")}} und {{HTTPMethod("HEAD")}} auszugeben und ansonsten {{HTTPStatus("307")}} <code>Temporary Redirect</code> zu benutzen, wo ein Wechsel der Methode ausdrücklich verboten ist.</div>
+
+<div></div>
+
+<p>Falls Sie möchten, dass der User-Agent die Anfragemethode auf {{HTTPMethod("GET")}} ändert, benutzen Sie stattdessen den Code {{HTTPStatus("303")}} <code>See Other</code>. Das ist etwa nützlich, wenn Sie eine {{HTTPMethod("PUT")}}-Anfrage nicht mit der hochgeladenen Resource, sondern mit einer bestätigenden Nachricht wie "Sie haben XYZ erfolgreich hochgeladen." beantworten wollen.</p>
+
+<h2 id="Status">Status</h2>
+
+<pre class="syntaxbox">302 Found</pre>
+
+<h2 id="Spezifikationen">Spezifikationen</h2>
+
+<table class="standard-table">
+ <tbody>
+  <tr>
+   <th scope="col">Spezifikation</th>
+   <th scope="col">Titel</th>
+  </tr>
+  <tr>
+   <td>{{RFC("7231", "302 Found" , "6.4.3")}}</td>
+   <td>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Browser-Kompatibilität">Browser-Kompatibilität</h2>
+
+<p class="hidden">The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> and send us a pull request.</p>
+
+<p>{{Compat("http.status.302")}}</p>
+
+<h2 id="Siehe_auch">Siehe auch</h2>
+
+<ul>
+ <li>{{HTTPStatus("307")}} <code>Temporary Redirect</code>, entspricht diesem Statuscode, lässt aber nie eine Änderung der Anfragemethode zu.</li>
+ <li>{{HTTPStatus("303")}} <code>See Other</code>, eine vorübergehende Weiterleitung, bei der die Anfragemethode auf {{HTTPMethod("GET")}} geändert werden soll.</li>
+ <li>{{HTTPStatus("301", "301 Moved Permanently")}} Die dauerhafte Weiterleitung.</li>
+</ul>
diff --git a/files/de/web/http/status/304/index.html b/files/de/web/http/status/304/index.html
new file mode 100644
index 0000000000..a5d5465634
--- /dev/null
+++ b/files/de/web/http/status/304/index.html
@@ -0,0 +1,61 @@
+---
+title: 304 Not Modified
+slug: Web/HTTP/Status/304
+tags:
+  - HTTP
+  - HTTP-Statuscode
+  - Statuscode
+  - Weiterleitung
+translation_of: Web/HTTP/Status/304
+---
+<div>{{HTTPSidebar}}</div>
+
+<div>
+<p>Der HTTP-Statuscode <code><strong>304 Not Modified </strong></code> gibt an, dass die angeforderten Ressourcen nicht erneut übertragen werden müssen. Es handelt sich um eine implizite Weiterleitung zu einer zwischengespeicherten Ressource. Dies geschieht, wenn die Anforderungsmethode {{glossary("safe")}} ist, wie eine {{HTTPMethod("GET")}}- oder {{HTTPMethod("HEAD")}}-Anfrage oder wenn die Anfrage bedingt ist und einen {{HTTPHeader("If-None-Match")}}- oder {{HTTPHeader("If-Modified-Since")}}-Header verwendet.</p>
+
+<p>Eine entsprechende Antwort mit {{HTTPStatus("200")}} <code>OK</code> hätte die Header {{HTTPHeader("Cache-Control")}}, {{HTTPHeader("Content-Location")}}, {{HTTPHeader("Date")}}, {{HTTPHeader("ETag")}}, {{HTTPHeader("Expires")}}, und {{HTTPHeader("Vary")}} enthalten.</p>
+</div>
+
+<div></div>
+
+<div class="note">
+<p>Many <a href="/en-US/docs/Tools/Network_Monitor">developer tools' network panels</a> of browsers create extraneous requests leading to <code>304</code> responses, so that access to the local cache is visible to developers.</p>
+</div>
+
+<h2 id="Status">Status</h2>
+
+<pre class="syntaxbox">304 Not Modified</pre>
+
+<h2 id="Spezifikationen">Spezifikationen</h2>
+
+<table class="standard-table">
+ <tbody>
+  <tr>
+   <th scope="col">Spezifikation</th>
+   <th scope="col">Titel</th>
+  </tr>
+  <tr>
+   <td>{{RFC("7232", "304 Not Modified" , "4.1")}}</td>
+   <td>Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Browserkompatibilität">Browserkompatibilität</h2>
+
+<p class="hidden">The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> and send us a pull request.</p>
+
+<p>{{Compat("http.status.304")}}</p>
+
+<h2 id="Anmerkungen_zur_Kompatibilität">Anmerkungen zur Kompatibilität</h2>
+
+<ul>
+ <li>Browser verhalten sich unterschiedlich, wenn zu dieser Antwort im Rahmen einer persistenten Verbindung fälschlicherweise ein Body geliefert wird. Genaueres siehe <a href="/en-US/docs/Web/HTTP/Status/204">204 No Content</a>.</li>
+</ul>
+
+<h2 id="Siehe_auch">Siehe auch</h2>
+
+<ul>
+ <li>{{HTTPHeader("If-Modified-Since")}}</li>
+ <li>{{HTTPHeader("If-None-Match")}}</li>
+</ul>
diff --git a/files/de/web/http/status/400/index.html b/files/de/web/http/status/400/index.html
new file mode 100644
index 0000000000..c4b5ce6b89
--- /dev/null
+++ b/files/de/web/http/status/400/index.html
@@ -0,0 +1,36 @@
+---
+title: 400 Bad Request
+slug: Web/HTTP/Status/400
+tags:
+  - Clientfehler
+  - HTTP
+  - HTTP-Statuscode
+  - Statuscode
+translation_of: Web/HTTP/Status/400
+---
+<p>{{HTTPSidebar}}</p>
+
+<p>Der <a href="/de/docs/Web/HTTP">HTTP</a>-Statuscode <code><strong>400 Bad Request</strong></code> gibt an, dass der Server die Anfrage nicht verarbeiten kann, weil anscheinend ein clientseitiger Fehler geschehen ist (z.B. eine syntaktisch falsche Anfrage).</p>
+
+<div class="warning">
+<p>Der Client sollte diese Anfrage nicht unmodifiziert wiederholen.</p>
+</div>
+
+<h2 id="Status">Status</h2>
+
+<pre class="syntaxbox">400 Bad Request </pre>
+
+<h2 id="Spezifikationen">Spezifikationen</h2>
+
+<table class="standard-table">
+ <tbody>
+  <tr>
+   <th scope="col">Spezifikation</th>
+   <th scope="col">Titel</th>
+  </tr>
+  <tr>
+   <td>{{RFC("7231", "400 Bad Request" , "6.5.1")}}</td>
+   <td>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</td>
+  </tr>
+ </tbody>
+</table>
diff --git a/files/de/web/http/status/401/index.html b/files/de/web/http/status/401/index.html
new file mode 100644
index 0000000000..be399c6451
--- /dev/null
+++ b/files/de/web/http/status/401/index.html
@@ -0,0 +1,57 @@
+---
+title: 401 Unauthorized
+slug: Web/HTTP/Status/401
+tags:
+  - HTTP
+  - Statuscode
+translation_of: Web/HTTP/Status/401
+---
+<div>{{HTTPSidebar}}</div>
+
+<p>Der <a href="/de/docs/Web/HTTP">HTTP</a>-Statuscode <strong><code>401 Unauthorized</code></strong> gibt an, dass der Server die Anfrage aufgrund fehlender oder ungültiger Authentifizierung abgelehnt hat.</p>
+
+<p>Dieser Statuscode wird zusammen mit dem {{HTTPHeader("WWW-Authenticate")}}-Header gesendet, welcher Informationen zur korrekten Authentifizierung bereithält.</p>
+
+<p>Dieser Statuscode ist ähnlich zu {{HTTPStatus("403")}}, gibt jedoch an, dass eine Authentifizierung möglich ist.</p>
+
+<h2 id="Status">Status</h2>
+
+<pre class="syntaxbox">401 Unauthorized</pre>
+
+<h2 id="Beispiel_für_eine_Antwort">Beispiel für eine Antwort</h2>
+
+<pre>HTTP/1.1 401 Unauthorized
+Date: Wed, 21 Oct 2015 07:28:00 GMT
+WWW-Authenticate: Basic realm="Zugang zu geschuetzter Seite"</pre>
+
+<h2 id="Spezifikationen">Spezifikationen</h2>
+
+<table class="standard-table">
+ <tbody>
+  <tr>
+   <th scope="col">Spezifikation</th>
+   <th scope="col">Titel</th>
+  </tr>
+  <tr>
+   <td>{{RFC("7235", "401 Unauthorized" , "3.1")}}</td>
+   <td>HTTP/1.1: Authentication</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Browser-Kompatibilität">Browser-Kompatibilität</h2>
+
+<p class="hidden">Die Kompatibilitäts-Tabelle wird aus strukturierten Daten generiert. Falls Sie dazu beitragen möchten, besuchen Sie bitte <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> und senden Sie uns dort einen "pull request".</p>
+
+<p>{{Compat("http.status.401")}}</p>
+
+<h2 id="Siehe_auch">Siehe auch</h2>
+
+<ul>
+ <li><a href="/en-US/docs/Web/HTTP/Authentication">HTTP authentication</a></li>
+ <li>{{HTTPHeader("WWW-Authenticate")}}</li>
+ <li>{{HTTPHeader("Authorization")}}</li>
+ <li>{{HTTPHeader("Proxy-Authorization")}}</li>
+ <li>{{HTTPHeader("Proxy-Authenticate")}}</li>
+ <li>{{HTTPStatus("403")}}, {{HTTPStatus("407")}}</li>
+</ul>
diff --git a/files/de/web/http/status/403/index.html b/files/de/web/http/status/403/index.html
new file mode 100644
index 0000000000..64e71e6c5f
--- /dev/null
+++ b/files/de/web/http/status/403/index.html
@@ -0,0 +1,55 @@
+---
+title: 403 Forbidden
+slug: Web/HTTP/Status/403
+tags:
+  - Client-Fehler
+  - Clientfehler
+  - HTTP
+  - HTTP-Statuscode
+  - Statuscode
+translation_of: Web/HTTP/Status/403
+---
+<p>{{HTTPSidebar}}</p>
+
+<p>Der HTTP <strong><code>403 Forbidden</code></strong> Statuscode zeigt an, dass der Server die Anfrage zwar verstanden hat, aber sich weigert, sie zuzulassen.</p>
+
+<p>Dieser Status ist {{HTTPStatus("401")}} ähnlich, aber ein erneutes Anmelden wird am Ergebnis nichts ändern. Der Zugriff ist dauerhaft verboten und liegt an der Anwendungslogik, wie etwa unzureichenden Rechten für eine Ressource.</p>
+
+<h2 id="Status">Status</h2>
+
+<pre class="syntaxbox">403 Forbidden</pre>
+
+<h2 id="Beispielantwort">Beispielantwort</h2>
+
+<pre>HTTP/1.1 403 Forbidden
+Date: Wed, 21 Oct 2015 07:28:00 GMT
+</pre>
+
+<h2 id="Spezifikationen">Spezifikationen</h2>
+
+<table class="standard-table">
+ <thead>
+  <tr>
+   <th scope="col">Spezifikation</th>
+   <th scope="col">Titel</th>
+  </tr>
+ </thead>
+ <tbody>
+  <tr>
+   <td>{{RFC("7231", "403 Forbidden" , "6.5.3")}}</td>
+   <td>HTTP/1.1: Semantics and Content</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Browserkompatibilität">Browserkompatibilität </h2>
+
+<p class="hidden">The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> and send us a pull request.</p>
+
+<p>{{Compat("http.status.403")}}</p>
+
+<h2 id="Siehe_auch">Siehe auch</h2>
+
+<ul>
+ <li>{{HTTPStatus("401")}}</li>
+</ul>
diff --git a/files/de/web/http/status/404/index.html b/files/de/web/http/status/404/index.html
new file mode 100644
index 0000000000..ae28507d6a
--- /dev/null
+++ b/files/de/web/http/status/404/index.html
@@ -0,0 +1,62 @@
+---
+title: 404 Not Found
+slug: Web/HTTP/Status/404
+tags:
+  - Client-Fehler
+  - Clientfehler
+  - HTTP
+  - HTTP-Statuscode
+  - Statuscode
+translation_of: Web/HTTP/Status/404
+---
+<div>{{HTTPSidebar}}</div>
+
+<p>Der HTTP-Statuscode <code><strong>404</strong></code><strong><code> Not Found</code></strong> zeigt an, dass der Server die angeforderte Ressource nicht finden konnte. Dieser Statuscode ist wahrscheinlich einer der bekanntesten, da er so häufig im Web auftritt. Oft spricht man dann von kaputten oder toten Links, die durch <a href="https://de.wikipedia.org/wiki/Toter_Link">Linkverrottung ("link rot")</a> entstehen.</p>
+
+<p>Ein 404-Statuscode zeigt nicht an, ob es sich dabei um einen temporären oder permanenten Zustand handelt. Wenn bekannt ist, dass die Ressource wahrscheinlich dauerhaft nicht verfügbar sein wird, ist {{HTTPStatus(410)}} (Gone) einem Status 404 vorzuziehen.</p>
+
+<h2 id="Status">Status</h2>
+
+<pre class="syntaxbox">404 Not Found</pre>
+
+<h2 id="Eigene_Fehler-Seiten">Eigene Fehler-Seiten</h2>
+
+<p>Viele Webseiten passen das Aussehen einer 404 Seite an, damit sie dem Benutzer Unterstützung anbieten kann. Apache-Server können mit einer <code>.htaccess</code>-Datei und folgendem Code-Schnipsel konfiguriert werden.</p>
+
+<pre>ErrorDocument 404 /notfound.html</pre>
+
+<p>Sie können sich auch von der <a href="/de/404">404 Seite des MDN</a> inspirieren lassen.</p>
+
+<div class="note">
+<p><strong>Hinweis:</strong> Es gibt eine <a href="https://www.google.de/search?q=awesome+404+pages">schier unerschöpfliche Quelle</a> an Inspiration für das Design einer 404-Seite. Beachten Sie aber, dass eine solche Seite nicht nur witzig sein soll, sondern es auch <a href="http://alistapart.com/article/perfect404">gute fachliche Herangehensweisen</a> gibt, die für die Besucher Ihrer Webseite hilfreich sind.</p>
+</div>
+
+<h2 id="Spezifikationen">Spezifikationen</h2>
+
+<table class="standard-table">
+ <tbody>
+  <tr>
+   <th scope="col">Spezifikation</th>
+   <th scope="col">Titel</th>
+  </tr>
+  <tr>
+   <td>{{RFC("7231", "404 Not Found" , "6.5.4")}}</td>
+   <td>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Browser-Kompatibilität">Browser-Kompatibilität</h2>
+
+<p class="hidden">The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> and send us a pull request.</p>
+
+<p>{{Compat}}</p>
+
+<h2 id="Siehe_auch">Siehe auch</h2>
+
+<ul>
+ <li>{{HTTPStatus(410)}}</li>
+ <li>
+  <p>{{interwiki("wikipedia", "HTTP_404", "Wikipedia: HTTP 404")}}</p>
+ </li>
+</ul>
diff --git a/files/de/web/http/status/409/index.html b/files/de/web/http/status/409/index.html
new file mode 100644
index 0000000000..4545b82ffd
--- /dev/null
+++ b/files/de/web/http/status/409/index.html
@@ -0,0 +1,40 @@
+---
+title: 409 Konflikt
+slug: Web/HTTP/Status/409
+tags:
+  - Client fehler
+  - HTTP
+  - HTTP Status Code
+  - Referenz
+translation_of: Web/HTTP/Status/409
+---
+<div>{{HTTPSidebar}}</div>
+
+<p>Der HTTP <code><strong>409 Conflict</strong></code> Antwort Status Code indiziert einen Anfragenkonflikt mit dem aktuellen Status des Servers.</p>
+
+<p>Konflikte entstehen meistens als Antwort auf eine {{HTTPMethod("PUT")}} Anfrage. Zum Beispiel erhält man eine 409 Antwort wenn man eine Datei hochlädt, die älter ist als die Datei auf dem Server, wodurch ein Versionskonflikt entsteht</p>
+
+<h2 id="Status">Status</h2>
+
+<pre class="syntaxbox">409 Conflict</pre>
+
+<h2 id="Specifications">Specifications</h2>
+
+<table class="standard-table">
+ <tbody>
+  <tr>
+   <th scope="col">Specification</th>
+   <th scope="col">Title</th>
+  </tr>
+  <tr>
+   <td>{{RFC("7231", "409 Conflict" , "6.5.8")}}</td>
+   <td>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="See_also">See also</h2>
+
+<ul>
+ <li>{{HTTPMethod("PUT")}}</li>
+</ul>
diff --git a/files/de/web/http/status/410/index.html b/files/de/web/http/status/410/index.html
new file mode 100644
index 0000000000..35524d6806
--- /dev/null
+++ b/files/de/web/http/status/410/index.html
@@ -0,0 +1,53 @@
+---
+title: 410 Gone
+slug: Web/HTTP/Status/410
+tags:
+  - Client-Fehler
+  - HTTP
+  - HTTP-Statuscode
+  - Referenz
+  - Statuscode
+translation_of: Web/HTTP/Status/410
+---
+<div>{{HTTPSidebar}}</div>
+
+<p>Der HTTP-Statuscode <code><strong>410</strong></code><strong><code> Gone</code></strong> zeigt an, dass der Zugriff auf die Zielressource über den Server nicht länger möglich ist und dieser Zustand wahrscheinlich permanent sein wird.</p>
+
+<p>Wenn Sie sich nicht sicher sind, ob es sich um einen temporären oder permanenten Zustand handeln wird, sollte ein {{HTTPStatus(404)}}-Statuscode verwendet werden.</p>
+
+<p>Das Englische "Gone" lässt sich in diesem Zusammenhang am besten mit "weg" oder "verschwunden" übersetzen, im vergleich zum "nicht gefunden" von {{HTTPStatus(404)}}</p>
+
+<div class="note">
+<p>Anmerkung: Eine Antwort mit Statuscode 410 ist standardmäßig im Cache speicherbar.</p>
+</div>
+
+<h2 id="Status">Status</h2>
+
+<pre class="syntaxbox">410 Gone</pre>
+
+<h2 id="Spezifikationen">Spezifikationen</h2>
+
+<table class="standard-table">
+ <tbody>
+  <tr>
+   <th scope="col">Spezifikation</th>
+   <th scope="col">Titel</th>
+  </tr>
+  <tr>
+   <td>{{RFC("7231", "410 Gone" , "6.5.9")}}</td>
+   <td>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Browser-Kompatibilität">Browser-Kompatibilität</h2>
+
+<p class="hidden">The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> and send us a pull request.</p>
+
+<p>{{Compat("http.status.410")}}</p>
+
+<h2 id="Siehe_auch">Siehe auch</h2>
+
+<ul>
+ <li>{{HTTPStatus(404)}}</li>
+</ul>
diff --git a/files/de/web/http/status/414/index.html b/files/de/web/http/status/414/index.html
new file mode 100644
index 0000000000..1a24bd3832
--- /dev/null
+++ b/files/de/web/http/status/414/index.html
@@ -0,0 +1,47 @@
+---
+title: 414 URI Too Long
+slug: Web/HTTP/Status/414
+tags:
+  - Clientfehler
+  - Fehlermeldung
+  - HTTP
+  - HTTP-Statuscode
+  - Statuscode
+translation_of: Web/HTTP/Status/414
+---
+<div>{{HTTPSidebar}}</div>
+
+<p>Der HTTP-Statuscode <code><strong>414 URI Too Long</strong></code> zeigt an, dass die vom Client angefragte URI länger ist als das, was der Server zu verarbeiten bereit ist.</p>
+
+<p>Es gibt einige seltene Fälle, in denen so etwas passieren kann:</p>
+
+<ul>
+ <li>wenn ein Client fälschlicherweise eine {{HTTPMethod("POST")}}- in eine  {{HTTPMethod("GET")}}-Anfrage umgewandelt hat und die bei der Anfrage übergebenen Daten umfangreich sind,</li>
+ <li>wenn der Client in eine Schleife von Weiterleitungen geraten ist (beispielsweise, wenn URIs immer wieder auf eine durch eine Ergänzung verlängerte URI verweisen) oder</li>
+ <li>wenn der Server von einem Client angegriffen wird, der versucht, durch die Anfrage sehr langer URIs Sicherheitslücken auszunutzen.</li>
+</ul>
+
+<h2 id="Status">Status</h2>
+
+<pre class="syntaxbox">414 URI Too Long</pre>
+
+<h2 id="Spezifikationen">Spezifikationen</h2>
+
+<table class="standard-table">
+ <tbody>
+  <tr>
+   <th scope="col">Spezifikation</th>
+   <th scope="col">Titel</th>
+  </tr>
+  <tr>
+   <td>{{RFC("7231", "414 URI Too Long" , "6.5.12")}}</td>
+   <td>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Siehe_auch">Siehe auch</h2>
+
+<ul>
+ <li>{{Glossary("URI")}}</li>
+</ul>
diff --git a/files/de/web/http/status/418/index.html b/files/de/web/http/status/418/index.html
new file mode 100644
index 0000000000..e0bf111cdc
--- /dev/null
+++ b/files/de/web/http/status/418/index.html
@@ -0,0 +1,47 @@
+---
+title: 418 I'm a teapot
+slug: Web/HTTP/Status/418
+tags:
+  - Aprilscherz
+  - Fehlermeldung
+  - HTTP
+  - HTTP-Statuscode
+  - Statuscode
+translation_of: Web/HTTP/Status/418
+---
+<div>{{HTTPSidebar}}</div>
+
+<p>Der HTTP-Statuscode <strong><code>418 I'm a teapot</code></strong> zeigt an, dass der Server sich weigert, Kaffee zu kochen, weil er ein Teekessel ist. Diese Fehlermeldung bezieht sich auf das <em>Hyper Text Coffee Pot Control Protocol</em>, einen Aprilscherz aus 1998.</p>
+
+<h2 id="Status">Status</h2>
+
+<pre class="syntaxbox">418 I'm a teapot</pre>
+
+<h2 id="Spezifikationen">Spezifikationen</h2>
+
+<table class="standard-table">
+ <thead>
+  <tr>
+   <th scope="col">Specification</th>
+   <th scope="col">Title</th>
+  </tr>
+ </thead>
+ <tbody>
+  <tr>
+   <td>{{RFC("2324", "418 I'm a teapot" , "2.3.2")}}</td>
+   <td>Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0): Semantics and Content</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Browserkompatibilität">Browserkompatibilität</h2>
+
+<p class="hidden">The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> and send us a pull request.</p>
+
+<p>{{Compat("http.status.418")}}</p>
+
+<h2 id="Siehe_auch">Siehe auch</h2>
+
+<ul>
+ <li>{{interwiki("wikipedia", "Hyper Text Coffee Pot Control Protocol", "Wikipedia: Hyper Text Coffee Pot Control Protocol")}}</li>
+</ul>
diff --git a/files/de/web/http/status/500/index.html b/files/de/web/http/status/500/index.html
new file mode 100644
index 0000000000..c7c0be2091
--- /dev/null
+++ b/files/de/web/http/status/500/index.html
@@ -0,0 +1,42 @@
+---
+title: 500 Internal Server Error
+slug: Web/HTTP/Status/500
+tags:
+  - Fehlermeldung
+  - HTTP
+  - HTTP-Statuscode
+  - Server-Fehler
+  - Serverfehler
+  - Statuscode
+translation_of: Web/HTTP/Status/500
+---
+<div>{{HTTPSidebar}}</div>
+
+<p>Der HTTP <code><strong>500</strong></code><strong><code> Internal Server Error</code></strong> Statuscode zeigt an, dass der Server durch einen unerwarteten Umstand daran gehindert wurde die an ihn gesendete Anfrage zu erfüllen.</p>
+
+<p>Diese Fehlermeldung ist ein generisches "Auffangbecken". Oft kommt es vor, dass Server-Administratoren Antworten mit Fehlermeldungen wie dem Statuscode 500 mit detaillierteren Angaben protokollieren, um den Fehler in Zukunft vermeiden zu können.</p>
+
+<h2 id="Status">Status</h2>
+
+<pre class="syntaxbox">500 Internal Server Error</pre>
+
+<h2 id="Spezifikationen">Spezifikationen</h2>
+
+<table class="standard-table">
+ <tbody>
+  <tr>
+   <th scope="col">Spezifikation</th>
+   <th scope="col">Titel</th>
+  </tr>
+  <tr>
+   <td>{{RFC("7231", "500 Internal Server Error" , "6.6.1")}}</td>
+   <td>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Browser-Kompatibilität">Browser-Kompatibilität</h2>
+
+<p class="hidden">The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> and send us a pull request.</p>
+
+<p>{{Compat}}</p>
diff --git a/files/de/web/http/status/503/index.html b/files/de/web/http/status/503/index.html
new file mode 100644
index 0000000000..edfcebe11c
--- /dev/null
+++ b/files/de/web/http/status/503/index.html
@@ -0,0 +1,55 @@
+---
+title: 503 Service Unavailable
+slug: Web/HTTP/Status/503
+tags:
+  - Fehlermeldung
+  - HTTP
+  - HTTP-Statuscode
+  - Serverfehler
+  - Statuscode
+translation_of: Web/HTTP/Status/503
+---
+<p>{{HTTPSidebar}}</p>
+
+<p>Der HTTP-Statuscode <code><strong>503 Service Unavailable</strong></code> zeigt an, dass der Server nicht in der Lage ist, die Anfrage zu bearbeiten.</p>
+
+<p>Übliche Gründe dafür sind, dass ein Server wegen Wartungsarbeiten abgeschaltet oder dass er überlastet ist. Dieser Code sollte für vorübergehende Zustände benutzt werden, und der HTTP-Header {{HTTPHeader("Retry-After")}} sollte möglichst angeben, ab wann damit zu rechnen ist, dass der Dienst wieder funktioniert.</p>
+
+<div class="note">
+<p><strong>Anmerkung:</strong> Zusammen mit einer solchen Antwort sollte eine benutzerfreundliche Seite ausgeliefert werden, die das Problem erklärt.</p>
+</div>
+
+<p>Werden mit einer solchen Antwort Header verschickt, die das Caching betreffen, sollten diese beachtet werden, da der Status 503 oft einen vorübergehenden Zustand betrifft und die Antwort daher normalerweise nicht in einem Cache gespeichert werden sollte.</p>
+
+<h2 id="Status">Status</h2>
+
+<pre class="syntaxbox">503 Service Unavailable</pre>
+
+<h2 id="Spezifikationen">Spezifikationen</h2>
+
+<table class="standard-table">
+ <tbody>
+  <tr>
+   <th scope="col">Specification</th>
+   <th scope="col">Title</th>
+  </tr>
+  <tr>
+   <td>{{RFC("7231", "503 Service Unavailable" , "6.6.4")}}</td>
+   <td>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Browser-Kompatibilität">Browser-Kompatibilität</h2>
+
+<p>Die unten genannen Informationen wurden von MDNs GitHub (<a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a>) abgerufen.</p>
+
+<p class="hidden">The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> and send us a pull request.</p>
+
+<p>{{Compat("http.status.503")}}</p>
+
+<h2 id="Siehe_auch">Siehe auch</h2>
+
+<ul>
+ <li>{{HTTPHeader("Retry-After")}}</li>
+</ul>
diff --git a/files/de/web/http/status/504/index.html b/files/de/web/http/status/504/index.html
new file mode 100644
index 0000000000..8d24afe266
--- /dev/null
+++ b/files/de/web/http/status/504/index.html
@@ -0,0 +1,51 @@
+---
+title: 504 Gateway Timeout
+slug: Web/HTTP/Status/504
+tags:
+  - Fehlermeldung
+  - HTTP
+  - HTTP-Statuscode
+  - Serverfehler
+  - Statuscode
+translation_of: Web/HTTP/Status/504
+---
+<div>{{HTTPSidebar}}</div>
+
+<p>Der HTTP-Statuscode <code><strong>504 Gateway Timeout</strong></code> zeigt an, dass der Server, der als Gateway oder Proxy fungiert, keine rechtzeitige Antwort von einem vorgelagerten Serverserver bekommen hat, die nötig gewesen wäre, um die Anfrage vollständig auszuführen.</p>
+
+<div class="note">
+<p><strong>Anmerkung</strong>: Es gibt verschiedene Dinge, die man in der Netzwerktechnik als {{interwiki("wikipedia", "Gateway_(telecommunications)", "Gateway")}} bezeichnet. Bei einer 504-Fehlermeldung können Sie meist nichts tun, um das Problem zu beheben, sondern dies muss auf dem Zielserver oder auf den Proxies, über die Sie den Zugriff versucht haben, geschehen.</p>
+</div>
+
+<h2 id="Status">Status</h2>
+
+<pre class="syntaxbox">504 Gateway Timeout</pre>
+
+<h2 id="Spezifikationen">Spezifikationen</h2>
+
+<table class="standard-table">
+ <tbody>
+  <tr>
+   <th scope="col">Spezifikation</th>
+   <th scope="col">Titel</th>
+  </tr>
+  <tr>
+   <td>{{RFC("7231", "504 Gateway Timeout" , "6.6.4")}}</td>
+   <td>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Browser-Kompatibilität">Browser-Kompatibilität</h2>
+
+<p>Die unten genannen Informationen wurden von MDNs GitHub (<a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a>) abgerufen.</p>
+
+<p class="hidden">The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> and send us a pull request.</p>
+
+<p>{{Compat("http.status.504")}}</p>
+
+<h2 id="Siehe_auch">Siehe auch</h2>
+
+<ul>
+ <li>{{HTTPStatus(502)}}</li>
+</ul>
diff --git a/files/de/web/http/status/505/index.html b/files/de/web/http/status/505/index.html
new file mode 100644
index 0000000000..6cdd25cd12
--- /dev/null
+++ b/files/de/web/http/status/505/index.html
@@ -0,0 +1,39 @@
+---
+title: 505 HTTP Version Not Supported
+slug: Web/HTTP/Status/505
+tags:
+  - Fehlermeldung
+  - HTTP
+  - HTTP-Statuscode
+  - Serverfehler
+  - Statuscode
+translation_of: Web/HTTP/Status/505
+---
+<div>{{HTTPSidebar}}</div>
+
+<p>Der HTTP-Statuscode <code><strong>505 HTTP Version Not Supported</strong></code> zeigt an, dass die für die Anfrage benutzte HTTP-Version vom Server nicht unterstützt wird.</p>
+
+<h2 id="Status">Status</h2>
+
+<pre class="syntaxbox">505 HTTP Version Not Supported</pre>
+
+<h2 id="Spezifikationen">Spezifikationen</h2>
+
+<table class="standard-table">
+ <tbody>
+  <tr>
+   <th scope="col">Spezifikation</th>
+   <th scope="col">Titel</th>
+  </tr>
+  <tr>
+   <td>{{RFC("7231", "505 HTTP Version Not Supported" , "6.6.6")}}</td>
+   <td>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Siehe_auch">Siehe auch</h2>
+
+<ul>
+ <li>{{HTTPHeader("Upgrade")}}</li>
+</ul>
diff --git a/files/de/web/http/status/511/index.html b/files/de/web/http/status/511/index.html
new file mode 100644
index 0000000000..bc9a2028fd
--- /dev/null
+++ b/files/de/web/http/status/511/index.html
@@ -0,0 +1,43 @@
+---
+title: 511 Network Authentication Required
+slug: Web/HTTP/Status/511
+tags:
+  - Fehlermeldung
+  - HTTP
+  - HTTP-Statuscode
+  - Serverfehler
+  - Statuscode
+translation_of: Web/HTTP/Status/511
+---
+<div>{{HTTPSidebar}}</div>
+
+<p>Der HTTP-Statuscode <code><strong>511 Network Authentication Required</strong></code> zeigt an, dass sich der Client authentifizieren muss, um Zugang zu einem Netz zu erhalten.</p>
+
+<p>Dieser Statuscode wird nicht vom angefragten Server ausgegeben, sondern von einem dazwischengeschalteten Proxy, das den Zugang zum Netz kontrolliert.</p>
+
+<p>Netzbetreiber verlangen manchmal eine Authentifizierung, die Zustimmung zu Nutzungsbedingungen oder andere Aktionen des Benutzers, bevor sie Zugang gewähren (z.B. in einem Internet-Café oder an einem Flughafen). Clients, bei denen es daran noch fehlt, werden oft über ihre Media-Access-Control-Adressen ({{Glossary("MAC")}}) identifiziert.</p>
+
+<h2 id="Status">Status</h2>
+
+<pre class="syntaxbox">511 Network Authentication Required</pre>
+
+<h2 id="Spezifikationen">Spezifikationen</h2>
+
+<table class="standard-table">
+ <tbody>
+  <tr>
+   <th scope="col">Spezifikation</th>
+   <th scope="col">Titel</th>
+  </tr>
+  <tr>
+   <td>{{RFC("6585", "511 Network Authentication Required" , "6")}}</td>
+   <td>Additional HTTP Status Codes</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Siehe_auch">Siehe auch</h2>
+
+<ul>
+ <li>{{Glossary("Proxy server")}}</li>
+</ul>
diff --git a/files/de/web/http/status/index.html b/files/de/web/http/status/index.html
new file mode 100644
index 0000000000..91ae3cda58
--- /dev/null
+++ b/files/de/web/http/status/index.html
@@ -0,0 +1,175 @@
+---
+title: HTTP response status codes
+slug: Web/HTTP/Status
+tags:
+  - HTTP
+  - NeedsTranslation
+  - Status codes
+  - TopicStub
+translation_of: Web/HTTP/Status
+---
+<div>{{HTTPSidebar}}</div>
+
+<p>HTTP-Antwortstatuscodes zeigen an, ob eine bestimmte <a href="/en-US/docs/Web/HTTP">HTTP</a>-Anfrage erfolgreich abgeschlossen wurde. Die Antworten sind in fünf Klassen eingeteilt:</p>
+
+<ol>
+ <li>Informative Antworten (100-199)</li>
+ <li>Erfolgreiche Antworten (200-299)</li>
+ <li>Umleitungen (300-399)</li>
+ <li>Client-Fehler (400-499)</li>
+ <li>Server-Fehler (500-599)</li>
+</ol>
+
+<p>Die folgenden Statuscodes sind in <a href="https://tools.ietf.org/html/rfc2616#section-10">Abschnitt 10 von RFC 2616</a> definiert. Eine aktualisierte Spezifikation finden Sie in <a href="https://tools.ietf.org/html/rfc7231#section-6.5.1">RFC 7231</a>.</p>
+
+<h2 id="Informative_Antworten">Informative Antworten</h2>
+
+<dl>
+ <dt>{{HTTPStatus(100, "100 Continue")}}</dt>
+ <dd>Diese vorläufige Antwort zeigt an, dass bisher alles in Ordnung ist und dass der Client mit der Anfrage fortfahren oder sie ignorieren sollte, wenn sie bereits abgeschlossen ist.</dd>
+ <dt>{{HTTPStatus(101, "101 Switching Protocol")}}</dt>
+ <dd>Dieser Code wird als Antwort auf einen {{HTTPHeader("Upgrade")}} Request-Header vom Client gesendet und zeigt an, dass auch der Server das Protokoll wechselt. Er wurde eingeführt, um die Migration zu einer inkompatiblen Protokollversion zu ermöglichen, und wird nicht häufig verwendet.</dd>
+ <dt>{{HTTPStatus(102, "102 Processing")}} ({{Glossary("WebDAV")}})</dt>
+ <dd>Dieser Code zeigt an, dass der Server die Anfrage erhalten hat und bearbeitet, aber noch keine Antwort verfügbar ist.</dd>
+ <dt>{{HTTPStatus(103, "103 Early Hints")}}</dt>
+ <dd>Dieser Statuscode ist in erster Linie für die Verwendung mit dem {{HTTPHeader("Link")}} Header vorgesehen, damit der Benutzeragent mit dem <a href="https://wiki.developer.mozilla.org/en-US/docs/Web/HTML/Preloading_content">Vorladen</a> von Ressourcen beginnen kann, während der Server eine Antwort vorbereitet.</dd>
+</dl>
+
+<h2 id="Erfolgreiche_Antworten">Erfolgreiche Antworten</h2>
+
+<dl>
+ <dt>{{HTTPStatus(200, "200 OK")}}</dt>
+ <dd>
+ <p>Die Anfrage ist erfolgreich. Die Bedeutung eines Erfolgs hängt von der HTTP-Methode ab​​​​:</p>
+
+ <ul>
+  <li><code>GET</code>: Die Ressource wurde geholt und wird im Nachrichtentext übertragen.</li>
+  <li><code>HEAD</code>: Die Entity-Header befinden sich im Nachrichtenkörper.</li>
+  <li><code>POST</code>: Die Ressource, die das Ergebnis der Aktion beschreibt, wird im Hauptteil der Nachricht übertragen.</li>
+  <li><code>TRACE</code>: Der Hauptteil der Nachricht enthält die vom Server empfangene Anforderungsnachricht.</li>
+ </ul>
+ </dd>
+ <dt>{{HTTPStatus(201, "201 Created")}}</dt>
+ <dd>Die Anfrage war erfolgreich, und als Ergebnis wurde eine neue Ressource geschaffen. Dies ist normalerweise die Antwort, die nach einer PUT-Anforderung gesendet wird.</dd>
+ <dt>{{HTTPStatus(202, "202 Accepted")}}</dt>
+ <dd>Die Anfrage ist eingegangen, aber noch nicht bearbeitet worden. Sie ist unverbindlich, was bedeutet, dass es in HTTP keine Möglichkeit gibt, später eine asynchrone Antwort zu senden, die das Ergebnis der Bearbeitung der Anfrage anzeigt. Sie ist für Fälle gedacht, in denen ein anderer Prozess oder Server die Anfrage bearbeitet, oder für die Stapelverarbeitung.</dd>
+ <dt>{{HTTPStatus(203, "203 Non-Authoritative Information")}}</dt>
+ <dd>Dieser Antwortcode bedeutet, dass der zurückgesendete Metainformationssatz nicht exakt dem Satz entspricht, der auf dem ursprünglichen Server verfügbar war, sondern von einer lokalen Kopie oder einer Kopie eines Drittanbieters gesammelt wurde. Abgesehen von dieser Bedingung sollten 200 OK-Antworten anstelle dieser Antwort bevorzugt werden.</dd>
+ <dt>{{HTTPStatus(204, "204 No Content")}}</dt>
+ <dd>Es gibt keinen Inhalt, den man für diese Anfrage senden kann, aber die Kopfzeilen können nützlich sein. Der Benutzer-Agent kann seine zwischengespeicherten Header für diese Ressource mit den neuen Header aktualisieren.</dd>
+ <dt>{{HTTPStatus(205, "205 Reset Content")}}</dt>
+ <dd>Dieser Antwortcode wird nach dem Ausführen der Anforderung gesendet, um dem Benutzeragenten mitzuteilen, der diese Anforderung gesendet hat.</dd>
+ <dt>{{HTTPStatus(206, "206 Partial Content")}}</dt>
+ <dd>Dieser Antwortcode wird aufgrund des vom Client gesendeten Range-Headers verwendet, um den Download in mehrere Streams zu trennen.</dd>
+ <dt>{{HTTPStatus(208, "208 Already Reported")}} ({{Glossary("WebDAV")}})</dt>
+ <dd>Wird innerhalb eines <code>&lt;dav:propstat&gt;</code> Antwortelements verwendet, um die wiederholte Aufzählung der internen Mitglieder mehrerer Bindungen zu derselben Sammlung zu vermeiden.</dd>
+ <dt>{{HTTPStatus(226, "226 IM Used")}} (<a href="https://tools.ietf.org/html/rfc3229">HTTP Delta encoding</a>)</dt>
+ <dd>Der Server hat eine <code>GET</code>-Anforderung für die Ressource erfüllt, und die Antwort ist eine Darstellung des Ergebnisses einer oder mehrerer auf die aktuelle Instanz angewandter Instanzmanipulationen.</dd>
+</dl>
+
+<h2 id="Umleitungen">Umleitungen</h2>
+
+<dl>
+ <dt>{{HTTPStatus(300, "300 Multiple Choice")}}</dt>
+ <dd>Die Anfrage hat mehr als eine mögliche Antwort. Der Benutzer-Agent oder Benutzer sollte eine davon auswählen. Es gibt keine standardisierte Möglichkeit, eine der Antworten auszuwählen.</dd>
+ <dt>{{HTTPStatus(301, "301 Moved Permanently")}}</dt>
+ <dd>Dieser Antwortcode bedeutet, dass der URI der angeforderten Ressource geändert wurde. Wahrscheinlich wird in der Antwort eine neue URI angegeben.</dd>
+ <dt>{{HTTPStatus(302, "302 Found")}}</dt>
+ <dd>Dieser Antwortcode bedeutet, dass der URI der angeforderten Ressource <em>vorübergehend</em> geändert wurde. Möglicherweise werden in der Zukunft neue Änderungen an der URI vorgenommen. Daher sollte derselbe URI vom Kunden in zukünftigen Anfragen verwendet werden.</dd>
+ <dt>{{HTTPStatus(303, "303 See Other")}}</dt>
+ <dd>Der Server sandte diese Antwort an den Client, um die angeforderte Ressource mit einer GET-Anforderung an eine andere URI zu leiten.</dd>
+ <dt>{{HTTPStatus(304, "304 Not Modified")}}</dt>
+ <dd>Dies wird für Cache-Zwecke verwendet. Es teilt dem Client mit, dass die Antwort nicht geändert wurde. Der Client kann also weiterhin dieselbe zwischengespeicherte Version der Antwort verwenden.</dd>
+ <dt>{{HTTPStatus(305, "305 Use Proxy")}}</dt>
+ <dd>Das bedeutet, dass ein Proxy auf die angeforderte Antwort zugreifen muss. Dieser Response-Code wird aus Sicherheitsgründen weitgehend nicht unterstützt.</dd>
+ <dt>{{HTTPStatus(306, "306 unused")}} {{deprecated_inline}}</dt>
+ <dd>Dieser Antwortcode wird nicht mehr verwendet, er ist derzeit nur reserviert. Er wurde in einer früheren Version der HTTP 1.1-Spezifikation verwendet.</dd>
+ <dt>{{HTTPStatus(307, "307 Temporary Redirect")}}</dt>
+ <dd>
+ <p>Der Server schickte diese Antwort an den Client, um die angeforderte Ressource an eine andere URI mit derselben Methode zu senden, die die vorherige Anforderung verwendete. Dies hat die gleiche Semantik wie der <code>302 Found</code> HTTP Response Code, mit der Ausnahme, dass der Benutzeragent die verwendete HTTP-Methode <em>nicht ändern</em> darf: Wenn in der ersten Anforderung ein <code>POST</code> verwendet wurde, muss in der zweiten Anforderung ein <code>POST</code> verwendet werden.</p>
+ </dd>
+ <dt>{{HTTPStatus(308, "308 Permanent Redirect")}}</dt>
+ <dd>Dies bedeutet, dass sich die Ressource nun <em>dauerhaft</em> an einem anderen, vom <code>Location:</code> angegebenen URI befindet: HTTP-Antwort-Header angegeben wird. Dies hat die gleiche Semantik wie der <code>301 Moved Permanently</code> HTTP Response Code, mit der Ausnahme, dass der Benutzeragent die verwendete HTTP-Methode <em>nicht ändern</em> darf: Wenn in der ersten Anfrage ein <code>POST</code> verwendet wurde, muss in der zweiten Anfrage ein <code>POST</code> verwendet werden.</dd>
+</dl>
+
+<h2 id="Antworten_auf_Client-Fehler">Antworten auf Client-Fehler</h2>
+
+<dl>
+ <dt>{{HTTPStatus(400, "400 Bad Request")}}</dt>
+ <dd>Diese Antwort bedeutet, dass der Server die Anfrage aufgrund einer ungültigen Syntax nicht verstehen konnte.</dd>
+ <dt>{{HTTPStatus(401, "401 Unauthorized")}}</dt>
+ <dd>Eine Authentifizierung ist erforderlich, um die angeforderte Antwort zu erhalten. Dies ist ähnlich wie bei 403, aber in diesem Fall ist eine Authentifizierung möglich.</dd>
+ <dt>{{HTTPStatus(402, "402 Payment Required")}}</dt>
+ <dd>Dieser Antwortcode ist für die zukünftige Verwendung reserviert. Ursprüngliches Ziel bei der Erstellung dieses Codes war es, ihn für digitale Zahlungssysteme zu verwenden, doch wird er derzeit nicht verwendet.</dd>
+ <dt>{{HTTPStatus(403, "403 Forbidden")}}</dt>
+ <dd>Der Client hat keine Zugriffsrechte auf den Inhalt, daher verweigert der Server eine ordnungsgemäße Antwort.</dd>
+ <dt>{{HTTPStatus(404, "404 Not Found")}}</dt>
+ <dd>Server kann angeforderte Ressource nicht finden. Dieser Antwort-Code ist wahrscheinlich der bekannteste aufgrund seiner Häufigkeit, mit der er im Web auftritt.</dd>
+ <dt>{{HTTPStatus(405, "405 Method Not Allowed")}}</dt>
+ <dd>Die Anfragemethode ist dem Server bekannt, wurde jedoch deaktiviert und kann nicht verwendet werden. Die beiden obligatorischen Methoden, <code>GET</code> und <code>HEAD</code>, dürfen niemals deaktiviert werden und sollten diesen Fehlercode nicht zurückgeben.</dd>
+ <dt>{{HTTPStatus(406, "406 Not Acceptable")}}</dt>
+ <dd>Diese Antwort wird gesendet, wenn der Webserver nach Durchführung der <a href="/en-US/docs/HTTP/Content_negotiation#Server-driven_negotiation">servergesteuerten Inhaltsaushandlung</a> nach den vom Benutzer-Agenten vorgegebenen Kriterien keinen Inhalt findet.</dd>
+ <dt>{{HTTPStatus(407, "407 Proxy Authentication Required")}}</dt>
+ <dd>Dies ist ähnlich wie 401, aber die Authentifizierung muss von einem Proxy durchgeführt werden.</dd>
+ <dt>{{HTTPStatus(408, "408 Request Timeout")}}</dt>
+ <dd>
+ <p>Diese Antwort wird von einigen Servern auf einer inaktiven Verbindung gesendet, auch ohne vorherige Anfrage durch den Client. Das bedeutet, dass der Server diese unbenutzte Verbindung abschalten möchte. Diese Antwort wird viel häufiger verwendet, da einige Browser, wie Chrome oder IE9, <a href="http://www.belshe.com/2011/02/10/the-era-of-browser-preconnect/">HTTP-Vorverbindungsmechanismen</a> verwenden, um das Surfen zu beschleunigen (siehe {{bug(634278)}}, der die zukünftige Implementierung eines solchen Mechanismus in Firefox verfolgt). Beachten Sie auch, dass einige Server lediglich die Verbindung unterbrechen, ohne diese Nachricht zu senden.</p>
+ </dd>
+ <dt>{{HTTPStatus(409, "409 Conflict")}}</dt>
+ <dd>Diese Antwort würde gesendet, wenn eine Anfrage mit dem aktuellen Zustand des Servers in Konflikt gerät.</dd>
+ <dt>{{HTTPStatus(410, "410 Gone")}}</dt>
+ <dd>Diese Antwort würde gesendet, wenn der angeforderte Inhalt vom Server gelöscht wurde.</dd>
+ <dt>{{HTTPStatus(411, "411 Length Required")}}</dt>
+ <dd>Der Server lehnte die Anforderung ab, weil das Header-Feld <code>Content-Length</code> nicht definiert ist und der Server sie benötigt.</dd>
+ <dt>{{HTTPStatus(412, "412 Precondition Failed")}}</dt>
+ <dd>Der Client hat in seinen Headern Vorbedingungen angegeben, die der Server nicht erfüllt.</dd>
+ <dt>{{HTTPStatus(413, "413 Payload Too Large")}}</dt>
+ <dd>Anforderungsentität ist größer als die vom Server definierten Grenzen; der Server könnte die Verbindung schließen oder ein <code>Retry-After</code> Header-Feld zurückgeben.</dd>
+ <dt>{{HTTPStatus(414, "414 URI Too Long")}}</dt>
+ <dd>Der vom Client angeforderte URI ist länger, als der Server zu interpretieren bereit ist.</dd>
+ <dt>{{HTTPStatus(415, "415 Unsupported Media Type")}}</dt>
+ <dd>Das Medienformat der angeforderten Daten wird vom Server nicht unterstützt, daher lehnt der Server die Anfrage ab.</dd>
+ <dt>{{HTTPStatus(416, "416 Requested Range Not Satisfiable")}}</dt>
+ <dd>Der durch das Header-Feld <code>Range</code> in der Anforderung angegebene Bereich kann nicht erfüllt werden; es ist möglich, dass der Bereich außerhalb der Größe der Daten des Ziel-URIs liegt.</dd>
+ <dt>{{HTTPStatus(417, "417 Expectation Failed")}}</dt>
+ <dd>Dieser Antwort-Code bedeutet, dass die im Header-Feld <code>Expect</code> request angegebene Erwartung vom Server nicht erfüllt werden kann.</dd>
+ <dt>{{HTTPStatus(421, "421 Misdirected Request")}}</dt>
+ <dd>Die Anfrage war an einen Server gerichtet, der nicht in der Lage ist, eine Antwort zu produzieren. Diese kann von einem Server gesendet werden, der nicht so konfiguriert ist, dass er Antworten für die Kombination aus Schema und Autorität erzeugt, die im Anforderungs-URI enthalten sind.</dd>
+ <dt>{{HTTPStatus(426, "426 Upgrade Required")}}</dt>
+ <dd>Der Server weigert sich, die Anforderung mit dem aktuellen Protokoll auszuführen, ist aber möglicherweise bereit, dies zu tun, nachdem der Client auf ein anderes Protokoll aktualisiert wurde. Der Server MUSS ein Upgrade-Header-Feld in einer 426-Antwort senden, um das/die erforderliche(n) Protokoll(e) anzugeben (<a href="https://tools.ietf.org/html/rfc7230#section-6.7">Abschnitt 6.7 von [RFC7230]</a>).</dd>
+ <dt>{{HTTPStatus(428, "428 Precondition Required")}}</dt>
+ <dd>Der Ursprungsserver verlangt, dass die Anfrage bedingt ist. Damit soll "das Problem der 'verlorenen Aktualisierung' verhindert werden, bei dem ein Client den Zustand einer Ressource GETs, modifiziert sie und PUTs zurück an den Server sendet, wenn inzwischen eine dritte Partei den Zustand auf dem Server modifiziert hat, was zu einem Konflikt führt.</dd>
+ <dt>{{HTTPStatus(429, "429 Too Many Requests")}}</dt>
+ <dd>Der Benutzer hat in einer bestimmten Zeitspanne zu viele Anfragen gesendet ("rate limiting").</dd>
+ <dt>{{HTTPStatus(431, "431 Request Header Fields Too Large")}}</dt>
+ <dd>Der Server ist nicht bereit, die Anfrage zu verarbeiten, weil seine Header-Felder zu groß sind. Die Anfrage KANN nach Reduzierung der Größe der Anfrage-Header-Felder erneut eingereicht werden.</dd>
+ <dt>{{HTTPStatus(451, "451 Unavailable For Legal Reasons")}}</dt>
+ <dd>Der Benutzer fordert eine illegale Ressource an, z.B. eine Webseite, die von einer Regierung zensiert wurde.</dd>
+</dl>
+
+<h2 id="Antworten_auf_Server-Fehler">Antworten auf Server-Fehler</h2>
+
+<dl>
+ <dt>{{HTTPStatus(500, "500 Internal Server Error")}}</dt>
+ <dd>Der Server ist auf eine Situation gestoßen, mit der er nicht umzugehen weiß.</dd>
+ <dt>{{HTTPStatus(501, "501 Not Implemented")}}</dt>
+ <dd>Die Anfragemethode wird vom Server nicht unterstützt und kann nicht bearbeitet werden. Die einzigen Methoden, die vom Server unterstützt werden müssen (und die daher diesen Code nicht zurückgeben dürfen), sind <code>GET</code> und <code>HEAD</code>.</dd>
+ <dt>{{HTTPStatus(502, "502 Bad Gateway")}}</dt>
+ <dd>Diese Fehlerreaktion bedeutet, dass der Server, während er als Gateway arbeitete, um eine Antwort zu erhalten, die zur Bearbeitung der Anfrage erforderlich ist, eine ungültige Antwort erhielt.</dd>
+ <dt>{{HTTPStatus(503, "503 Service Unavailable")}}</dt>
+ <dd>Der Server ist nicht bereit, die Anfrage zu bearbeiten. Häufige Ursachen sind ein Server, der wegen Wartungsarbeiten ausfällt oder überlastet ist. Beachten Sie, dass zusammen mit dieser Antwort eine benutzerfreundliche Seite gesendet werden sollte, die das Problem erklärt. Diese Antworten sollten für vorübergehende Bedingungen und <code>Retry-After:</code> verwendet werden: HTTP-Header sollte, wenn möglich, die geschätzte Zeit vor der Wiederherstellung des Dienstes enthalten. Der Webmaster muss sich auch um die Caching-bezogenen Header kümmern, die zusammen mit dieser Antwort gesendet werden, da diese Antworten auf temporäre Bedingungen normalerweise nicht im Cache gespeichert werden sollten.</dd>
+ <dt>{{HTTPStatus(504, "504 Gateway Timeout")}}</dt>
+ <dd>Diese Fehlerantwort wird gegeben, wenn der Server als Gateway fungiert und nicht rechtzeitig eine Antwort erhalten kann.</dd>
+ <dt>{{HTTPStatus(505, "505 HTTP Version Not Supported")}}</dt>
+ <dd>Die in der Anfrage verwendete HTTP-Version wird vom Server nicht unterstützt.</dd>
+ <dt>{{HTTPStatus(506, "506 Variant Also Negotiates")}}</dt>
+ <dd>Der Server weist einen internen Konfigurationsfehler auf: Die gewählte Ressourcenvariante ist so konfiguriert, dass sie selbst transparente Inhaltsverhandlungen führt und daher kein geeigneter Endpunkt im Vermittlungsprozess ist.</dd>
+ <dt>{{HTTPStatus(507, "507 Insufficient Storage")}} ({{Glossary("WebDAV")}})</dt>
+ <dd>Die Methode konnte auf der Ressource nicht ausgeführt werden, weil der Server nicht in der Lage ist, die Darstellung zu speichern, die zum erfolgreichen Abschluss der Anfrage erforderlich ist.</dd>
+ <dt>{{HTTPStatus(508, "508 Loop Detected")}} ({{Glossary("WebDAV")}})</dt>
+ <dd>Der Server hat bei der Verarbeitung der Anfrage eine Endlosschleife festgestellt.</dd>
+ <dt>{{HTTPStatus(510, "510 Not Extended")}}</dt>
+ <dd>Damit der Server den Antrag erfüllen kann, sind weitere Erweiterungen des Antrags erforderlich.</dd>
+ <dt>{{HTTPStatus(511, "511 Network Authentication Required")}}</dt>
+ <dd>Der Statuscode 511 zeigt an, dass sich der Client authentifizieren muss, um Zugang zum Netzwerk zu erhalten.</dd>
+</dl>