4

不同时区的服务器和客户端。6小时之差。服务器设置一个 cookie 1 小时，但客户端正确接收它并保持一个小时，尽管客户端当前是 5 小时前。客户端如何在整点正确设置 cookie？浏览器可能会查看标题“日期”吗？如果是这样，如果服务器将位于另一个代理服务器之后，它将设置自己的“日期”标头怎么办？

必须提供参考 rfc 或其他地方的证明。

4

2 回答 2

4

有 2 种方法可以指定 cookie 的最长期限：

Max-Age 是相对于设置时间的。所以 Texpiration = Tsetting + Max-Age

否则，Expires 属性设置包含时区的日期/时间值： https ://www.rfc-editor.org/rfc/rfc6265#section-5.1.1

来自 RFC 本身的示例：

Expires=Wed, 09 Jun 2021 10:18:14 GMT

有许多标准（旧的和新的）支持 GMT（UTC）作为日期/时间格式：

从RFC2616我们得到了所谓的HTTP 格式：

所有 HTTP 日期/时间戳必须以格林威治标准时间 (GMT) 表示，无一例外。就 HTTP 而言，GMT 与 UTC（协调世界时）完全相同。

Expires 属性还应该以 HTTP 格式设置时间：

例如Set-Cookie: reg_fb_gate=deleted; Expires=Thu, 01-Jan-1970 00:00:01 GMT; Path=/; Domain=.example.com; HttpOnly （来自维基百科）

于 2016-03-01T17:54:33.200 回答
2

时区实际上并不重要，因为无论如何 HTTP 日期都应该是 UTC（历史上是 GMT）（参见RFC7231，sec. 7.1.1.1）：

HTTP-date 值将时间表示为协调世界时 (UTC) 的一个实例。前两种格式用格林威治标准时间的三个字母缩写“GMT”来表示 UTC，它是 UTC 名称的前身；asctime 格式的值假定为 UTC。

然后，Date服务器的标头应该是权威的，因为Set-Cookie标头本身不知道日期（参见RFC6265，第 4.1.1 节）。您认为下一个代理将添加自己的Date标头的假设有点不对劲。只有在原始服务器本身没有设置 1 时才会发生这种情况（参见RFC7231，第 7.1.1.2 节）：

如果源服务器没有能够以协调世界时提供当前实例的合理近似值的时钟，则源服务器不得发送 Date 头字段。如果响应在 1xx（信息）或 5xx（服务器错误）类状态代码中，源服务器可以发送 Date 头字段。在所有其他情况下，源服务器必须发送 Date 头字段。

具有时钟的接收者接收没有 Date 头字段的响应消息，必须记录它被接收到的时间，如果消息被缓存或转发到下游，则将相应的 Date 头字段附加到消息的头部分。

于 2016-03-01T18:02:31.967 回答