Der HTTPSet-CookieAntwort-Header wird verwendet, um ein Cookie vom Server an den Benutzer-Agent zu senden, sodass dieser es später wieder an den Server senden kann. Um mehrere Cookies zu senden, sollten mehrereSet-Cookie-Header in derselben Antwort gesendet werden.

Weitere Informationen finden Sie im Leitfaden zuVerwendung von HTTP-Cookies.

Syntax

Set-Cookie: <cookie-name>=<cookie-value>Set-Cookie: <cookie-name>=<cookie-value>; Domain=<domain-value>Set-Cookie: <cookie-name>=<cookie-value>; Expires=<date>Set-Cookie: <cookie-name>=<cookie-value>; HttpOnlySet-Cookie: <cookie-name>=<cookie-value>; Max-Age=<number>Set-Cookie: <cookie-name>=<cookie-value>; PartitionedSet-Cookie: <cookie-name>=<cookie-value>; Path=<path-value>Set-Cookie: <cookie-name>=<cookie-value>; SecureSet-Cookie: <cookie-name>=<cookie-value>; SameSite=StrictSet-Cookie: <cookie-name>=<cookie-value>; SameSite=LaxSet-Cookie: <cookie-name>=<cookie-value>; SameSite=None; Secure// Multiple attributes are also possible, for example:Set-Cookie: <cookie-name>=<cookie-value>; Domain=<domain-value>; Secure; HttpOnly

Attribute

<cookie-name>=<cookie-value>

Definiert den Namen des Cookies und dessen Wert.Die Definition eines Cookies beginnt mit einem Name-Wert-Paar.

Ein<cookie-name> kann alle US-ASCII-Zeichen enthalten, außer Steuerzeichen (ASCII-Zeichen 0 bis 31 und ASCII-Zeichen 127) oder Trennzeichen (Leerzeichen, Tabulator und die Zeichen:( ) < > @ , ; : \ " / [ ] ? = { }).

Ein<cookie-value> kann optional in Anführungszeichen gesetzt sein und jedes US-ASCII-Zeichen enthalten, außer Steuerzeichen (ASCII-Zeichen 0 bis 31 und ASCII-Zeichen 127),Leerzeichen, Anführungszeichen, Kommas, Semikolons und Backslashes.

Kodierung: Viele Implementierungen führen eineProzentkodierung der Cookie-Werte durch. Dies ist jedoch nicht durch die RFC-Spezifikation vorgeschrieben. Die Prozentkodierung hilft jedoch, die Anforderungen der erlaubten Zeichen für<cookie-value> zu erfüllen.

Hinweis:Einige Cookienamen enthalten Präfixe, die spezifische Einschränkungen auf die Attribute des Cookies in unterstützenden Benutzeragenten auferlegen. Weitere Informationen finden Sie unterCookie-Präfixe.

Domain=<domain-value>Optional

Definiert den Host, an den das Cookie gesendet wird.

Als Wert kann nur die aktuelle Domain oder eine Domain höherer Ordnung gesetzt werden, es sei denn, es handelt sich um ein öffentliches Suffix. Das Setzen der Domain macht das Cookie sowohl für diese als auch für alle ihre Subdomains verfügbar.

Wenn es weggelassen wird, wird das Cookie nur an den Host zurückgesendet, der es gesendet hat (d.h. es wird zu einem "host-only cookie").Dies ist restriktiver, als den Hostnamen zu setzen, da das Cookie nicht für Subdomains des Hosts verfügbar gemacht wird.

Im Gegensatz zu früheren Spezifikationen werden führende Punkte in Domainnamen (.example.com) ignoriert.

Mehrere Host-/Domain-Werte sindnicht erlaubt, aber wenn eine Domainangegeben ist, dann sind Subdomains immer eingeschlossen.

Expires=<date>Optional

Gibt die maximale Lebensdauer des Cookies als HTTP-Datum-Zeitstempel an.SieheDate für das erforderliche Format.

Wenn nicht angegeben, wird das Cookie zu einemSitzungs-Cookie.Eine Sitzung endet, wenn der Client heruntergefahren wird, danach wird das Sitzungs-Cookie entfernt.

Warnung:Viele Webbrowser verfügen über eineSitzungswiederherstellung-Funktion, die alle Tabs speichert und diese beim nächsten Gebrauch des Browsers wiederherstellt. Sitzungs-Cookies werden ebenfalls wiederhergestellt, als ob der Browser nie geschlossen wurde.

DasExpires-Attribut wird vom Server mit einem Wert relativ zu seiner eigenen internen Uhr gesetzt, die von der des Client-Browsers abweichen kann.Firefox und Chromium-basierte Browser verwenden intern einen Ablaufwert (max-age), der angepasst wird, um den Unterschied in der Uhrzeit auszugleichen. Cookies werden basierend auf der vom Server beabsichtigten Zeit gespeichert und ablaufen gelassen.Die Anpassung für die Uhrdifferenz wird aus dem Wert desDATE Headers berechnet.Beachten Sie, dass die Spezifikation erklärt, wie das Attribut geparst werden sollte, aber nicht, ob/wie der Wert vom Empfänger korrigiert werden sollte.

HttpOnlyOptional

Verbietet JavaScript den Zugriff auf das Cookie, beispielsweise über dieDocument.cookie-Eigenschaft.Beachten Sie, dass ein Cookie, das mitHttpOnly erstellt wurde, weiterhin mit JavaScript-initiierten Anfragen gesendet wird, z. B. beim Aufruf vonXMLHttpRequest.send() oderfetch().Dies mindert Angriffe gegen Cross-Site Scripting (XSS).

Max-Age=<number>Optional

Gibt die Anzahl von Sekunden an, bis das Cookie abläuft. Eine Null oder eine negative Zahl wird das Cookie sofort ablaufen lassen. Wenn sowohlExpires als auchMax-Age gesetzt sind, hatMax-Age Vorrang.

PartitionedOptional

Gibt an, dass das Cookie unter Verwendung einer partitionierten Speicherung gespeichert werden soll.Beachten Sie, dass, wenn dies gesetzt ist, dieSecure-Direktive ebenfalls gesetzt werden muss.Weitere Einzelheiten finden Sie unterCookies mit unabhängigem partitioniertem Status (CHIPS).

Path=<path-value>Optional

Gibt den Pfad an, derin der angeforderten URL existierenmuss, damit der Browser denCookie-Header sendet.

Wenn weggelassen, wird dieses Attribut standardmäßig auf den Pfad der Anfrage-URL gesetzt. Wenn ein Cookie beispielsweise durch eine Anfrage anhttps://example.com/docs/Web/HTTP/index.html gesetzt wird, würde der Standardpfad/docs/Web/HTTP/ sein.

Das Schrägstrich-Zeichen (/) wird als Verzeichnis-Trennzeichen interpretiert, und Subverzeichnisse werden ebenfalls abgeglichen. Zum Beispiel, fürPath=/docs,

• werden die Anfragen für die Pfade/docs,/docs/,/docs/Web/ und/docs/Web/HTTP alle abgeglichen.
• werden die Anfragen für die Pfade/,/docsets,/fr/docs nicht abgeglichen.

Hinweis:Daspath-Attribut lässt Sie steuern, welche Cookies der Browser basierend auf den verschiedenen Teilen einer Website sendet.Es ist nicht als Sicherheitsmaßnahme gedacht undschützt nicht vor unbefugtem Lesen des Cookies von einem anderen Pfad.

SameSite=<samesite-value>Optional

Steuert, ob ein Cookie bei Anfragen von anderenSeiten gesendet wird, einschließlich des Schemas, von der Seite, die das Cookie gesetzt hat. Dies bietet einen gewissen Schutz gegen bestimmte Cross-Site-Angriffe, einschließlichCross-Site Request Forgery (CSRF)-Angriffe.

Die möglichen Attributwerte sind:

Strict

Sendet das Cookie nur für Anfragen, die von derselbenSeite stammen, die das Cookie gesetzt hat.

Lax

Sendet das Cookie nur für Anfragen, die von derselbenSeite stammen, die das Cookie gesetzt hat, und für Anfragen von anderen Seiten, die beide der folgenden Kriterien erfüllen:

• Die Anfrage ist eine Top-Level-Navigation: Das bedeutet im Wesentlichen, dass die Anfrage dazu führt, dass die URL in der Adressleiste des Browsers wechselt.

  • Dies würde zum Beispiel Anfragen ausschließen, die mit derfetch()-API gemacht werden, oder Anfragen für Subressourcen aus<img>- oder<script>-Elementen, oder Navigieren innerhalb von<iframe>-Elementen.

  • Es würde Anfragen einschließen, die auftauchen, wenn der Benutzer auf einen Link im Top-Level-Browsing-Kontext von einer Seite zu einer anderen klickt, oder eine Zuweisung zudocument.location, oder einen<form>-Absenden.

• Die Anfrage verwendet einesichere Methode: Im Besonderen schließt diesPOST,PUT undDELETE aus.

Einige Browser verwendenLax als Standardwert, wennSameSite nicht angegeben ist: SieheBrowser-Kompatibilität für Details.

Hinweis:WennLax als Standard angewendet wird, wird eine permissivere Version verwendet. In dieser permissiveren Version werden Cookies auch inPOST-Anfragen einbezogen, solange sie nicht mehr als zwei Minuten vor der gestellten Anfrage gesetzt wurden.

None

Sendet das Cookie mit sowohl cross-site als auch same-site Anfragen.DasSecure-Attribut muss ebenfalls gesetzt sein, wenn Sie diesen Wert verwenden.

SecureOptional

Gibt an, dass das Cookie nur dann an den Server gesendet wird, wenn eine Anfrage mit demhttps:-Schema gemacht wird (außer bei localhost) und ist daher resistenter gegenMan-in-the-Middle-Angriffe.

Hinweis:Gehen Sie nicht davon aus, dassSecure jeglichen Zugriff auf sensible Informationen in Cookies (Sitzungsschlüssel, Anmeldedaten etc.) verhindert.Cookies mit diesem Attribut können noch durch Zugriff auf die Festplatte des Clients oder durch JavaScript gelesen/modifiziert werden, wenn dasHttpOnly-Cookie-Attribut nicht gesetzt ist.

Unsichere Seiten (http:) können keine Cookies mit demSecure-Attribut setzen. Diehttps:-Anforderungen werden ignoriert, wenn dasSecure-Attribut von localhost gesetzt wird.

Cookie-Präfixe

Einige Cookienamen enthalten Präfixe, die spezifische Einschränkungen auf die Attribute des Cookies in unterstützenden Benutzeragenten auferlegen. Alle Cookie-Präfixe beginnen mit einem Doppel-Underscore (__) und enden mit einem Bindestrich (-). Die folgenden Präfixe sind definiert:

• __Secure-: Cookies, deren Namen mit__Secure- beginnen, müssen mit demSecure-Attribut von einer sicheren Seite (HTTPS) gesetzt werden.
• __Host-: Cookies, deren Namen mit__Host- beginnen, müssen mit demSecure-Attribut von einer sicheren Seite (HTTPS) gesetzt werden. Zusätzlich dürfen sie keinDomain-Attribut spezifiziert haben, und dasPath-Attribut muss auf/ gesetzt werden. Dies garantiert, dass solche Cookies nur an den Host gesendet werden, der sie gesetzt hat, und nicht an irgendeinen anderen Host auf der Domain. Es wird auch garantiert, dass sie hostweit gesetzt sind und auf keinem Pfad auf diesem Host überschrieben werden können. Diese Kombination führt zu einem Cookie, das dem Konzept einer Sicherheitsgrenze für den Ursprung so nahe wie möglich kommt.
• __Http-: Cookies, deren Namen mit__Http- beginnen, müssen mit demSecure-Flag von einer sicheren Seite (HTTPS) gesetzt werden und zusätzlich muss dasHttpOnly-Attribut gesetzt sein, um zu beweisen, dass sie über denSet-Cookie-Header gesetzt wurden (sie können nicht über JavaScript-Funktionen wieDocument.cookie oder dieCookie Store API gesetzt oder modifiziert werden).
• __Host-Http-: Cookies, deren Namen mit__Host-Http- beginnen, müssen mit demSecure-Flag von einer sicheren Seite (HTTPS) gesetzt werden und müssen dasHttpOnly-Attribut haben, um zu beweisen, dass sie über denSet-Cookie-Header gesetzt wurden. Zusätzlich haben sie auch dieselben Einschränkungen wie die mit__Host--Präfix gesetzten Cookies. Diese Kombination führt zu einem Cookie, das dem Konzept einer Sicherheitsgrenze für den Ursprung so nahe wie möglich kommt, während gleichzeitig sichergestellt wird, dass Entwickler und Serverbetreiber wissen, dass sein Gültigkeitsbereich auf HTTP-Anfragen beschränkt ist.

Beispiele

Sitzungscookie

Sitzungscookies werden entfernt, wenn der Client heruntergefahren wird. Cookies sind Sitzungscookies, wenn sie das AttributExpires oderMax-Age nicht spezifizieren.

Set-Cookie: sessionId=38afes7a8

Permanentes Cookie

Permanente Cookies werden an einem bestimmten Datum (Expires) oder nach einer bestimmten Zeitdauer (Max-Age) entfernt, und nicht, wenn der Client geschlossen wird.

Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT

Set-Cookie: id=a3fWa; Max-Age=2592000

Ungültige Domains

Ein Cookie für eine Domain, die den Server, der es gesetzt hat, nicht einschließt,sollte vom Benutzeragenten abgelehnt werden.

Das folgende Cookie wird abgelehnt, wenn es von einem Server auforiginal-company.com gesetzt wird:

Set-Cookie: qwerty=219ffwef9w0f; Domain=some-company.co.uk

Ein Cookie für eine Subdomain der dienenden Domain wird abgelehnt.

Das folgende Cookie wird abgelehnt, wenn es von einem Server aufexample.com gesetzt wird:

Set-Cookie: sessionId=e8bb43229de9; Domain=foo.example.com

Cookie-Präfixe

Cookienamen mit dem Präfix__Secure- oder__Host- können nur verwendet werden, wenn sie mit demSecure-Attribut von einem sicheren (HTTPS) Ursprung gesetzt werden.

Cookienamen mit dem Präfix__Http- oder__Host-Http- können nur verwendet werden, wenn sie mit demSecure-Attribut von einem sicheren (HTTPS) Ursprung gesetzt werden und zusätzlich dasHttpOnly-Attribut haben müssen, um zu beweisen, dass sie über denSet-Cookie-Header gesetzt wurden und nicht clientseitig über JavaScript.

Zusätzlich müssen Cookies mit dem__Host- oder__Host-Http- Präfix einen Pfad von/ haben (bedeutet jeden Pfad beim Host) und dürfen keinDomain-Attribut haben.

// Both accepted when from a secure origin (HTTPS)Set-Cookie: __Secure-ID=123; Secure; Domain=example.comSet-Cookie: __Host-ID=123; Secure; Path=/// Rejected due to missing Secure attributeSet-Cookie: __Secure-id=1// Rejected due to the missing Path=/ attributeSet-Cookie: __Host-id=1; Secure// Rejected due to setting a DomainSet-Cookie: __Host-id=1; Secure; Path=/; Domain=example.com// Only settable via Set-CookieSet-Cookie: __Http-ID=123; Secure; Domain=example.comSet-Cookie: __Host-Http-ID=123; Secure; Path=/

Partitioniertes Cookie

Set-Cookie: __Host-example=34d8g; SameSite=None; Secure; Path=/; Partitioned;

Spezifikationen

Browser-Kompatibilität

Siehe auch

• HTTP-Cookies
• Cookie
• Document.cookie
• Samesite cookies explained (web.dev blog)