Set-Cookie

所述Set-CookieHTTP 响应报头被用于从服务器向用户代理发送 cookie。

有关更多信息，请参阅 HTTP cookie 指南。

句法

Set-Cookie: <cookie-name>=<cookie-value> Set-Cookie: <cookie-name>=<cookie-value>; Expires=<date>Set-Cookie: <cookie-name>=<cookie-value>; Max-Age=<non-zero-digit>Set-Cookie: <cookie-name>=<cookie-value>; Domain=<domain-value>Set-Cookie: <cookie-name>=<cookie-value>; Path=<path-value>Set-Cookie: <cookie-name>=<cookie-value>; Secure
Set-Cookie: <cookie-name>=<cookie-value>; HttpOnly

Set-Cookie: <cookie-name>=<cookie-value>; SameSite=Strict
Set-Cookie: <cookie-name>=<cookie-value>; SameSite=Lax// Multiple directives are also possible, for example:Set-Cookie: <cookie-name>=<cookie-value>; Domain=<domain-value>; Secure; HttpOnly

指令

<cookie-name>=<cookie-value>Cookie 以名称 - 值对开头：

• <cookie-name>可以是除控制字符（CTL），空格或制表符之外的任何US-ASCII字符。它也不能包含像下面这样的分隔符：（）<> @，; ：\“/？= {}。

• <cookie-value>可以有选择地用双引号设置，并且任何 US-ASCII 字符（不包括 CTL，空格，双引号，逗号，分号和反斜线）都是允许的。编码：许多实现在 cookie 值上执行 URL 编码，但不是每个 RFC 规范都要求的。它确实有助于满足 <cookie-value> 允许哪些字符被允许的要求。

• __Secure-：名称以__Secure-（破折号为前缀的一部分）开头的Cookie 必须使用该secure标志进行设置，并且必须来自安全页面（HTTPS）。

• __Host-：以名称开头的 Cookie __Host-必须设置为secure标志，必须来自安全页面（HTTPS），不得指定域（因此不会发送到子域），路径必须为“/”。

Expires=<date> Optional

作为 HTTP 日期时间戳的 cookie 的最大生存期。请参阅Date详细格式。如果未指定，则 Cookie 将具有会话 cookie 的生存期。会话在客户端关闭时结束，意味着会话 cookie 将在此时被删除。但是，许多 Web 浏览器都有一项称为会话恢复的功能，可以保存所有选项卡，并在下次使用浏览器时让它们恢复。 Cookies 也将出现，就像您从未真正关闭浏览器一样。

如果设置了到期日期，则设置的时间和日期与相关 Cookie 的客户端设置相关，而不是服务器。

Max-Age = <非零数字>直到 Cookie 过期的可选秒数。一个或多个数字1到9.较旧的浏览器（ie6，ie7 和 ie8）不支持最大年龄。对于其他浏览器，如果（Expires和Max-Age）都设置了，Max-Age将具有优先权。域= <域值>可选指定将向其发送 cookie 的那些主机。如果未指定，则默认为当前文档位置的主机部分（但不包括子域）。与之前的规范相反，域名中的前导点被忽略。如果指定了域，则始终包含子域。Path = <path-value>可选指示发送Cookie标头之前必须存在于请求的资源中的URL路径。％x2F（“/”）字符被解释为目录分隔符，并且子目录也将被匹配（例如 path = / docs，“/ docs”，“/ docs / Web /”或“/ docs / Web / HTTP“ 将全部匹配）.Secure 可选只有在使用SSL和HTTPS协议进行请求时才会将安全 cookie 发送到服务器。然而，

注意：不安全的网站（http:）不能使用“安全”指令设置 cookie（Chrome 52 +和Firefox 52+中的新增功能）。

HttpOnly 无法通过 JavaScript 访问可选 HTTP ,HTTP cookie，通过此Document.cookie属性XMLHttpRequest和RequestAPI来缓解对跨站点脚本攻击（XSS）的攻击 .SameSite = Strict

SameSite=Lax Optional

允许服务器声明 Cookie 不应与跨站点请求一起发送，这为跨站点请求伪造攻击（CSRF）提供了一些保护。

例子

会话 cookie

会话 cookie 将在客户端关闭时被删除。他们没有指定Expires或Max-Age指令。请注意，Web 浏览器通常会启用会话恢复。

Set-Cookie: sessionid=38afes7a8; HttpOnly; Path=/

永久 cookie

永久性 cookies 不是在客户关闭时到期，而是在特定日期（Expires）或特定时间长度（）后过期Max-Age。

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

无效的网域

属于不包含原始服务器的域的 cookie 应该被用户代理拒绝。如果以下 cookie 由托管在 originalcompany.com 上的服务器设置，则它将被拒绝。

Set-Cookie: qwerty=219ffwef9w0f; Domain=somecompany.co.uk; Path=/; Expires=Wed, 30 Aug 2019 00:00:00 GMT

Cookie 前缀

与前缀饼干名称__Secure-和__Host-可如果它们设置与只使用secure从安全（HTTPS）的起源指令。另外，带__Host-前缀的 cookies 必须有一个“/”（整个主机）的路径，并且不能有域属性。对于不实施 cookie 前缀的客户，您不能指望获得这些额外保证，cookies 将始终被接受。

// 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 directiveSet-Cookie: __Secure-id=1// Rejected due to the missing Path=/ directiveSet-Cookie: __Host-id=1; Secure// Rejected due to setting a domainSet-Cookie: __Host-id=1; Secure; Path=/; domain=example.com

产品规格

浏览器兼容性

• 请参阅 Bugzilla.Compatibility 说明中的错误795346

• 从 Chrome 52 和 Firefox 52 开始，不安全的站点（http:）不能再使用“安全”指令来设置 cookie。