Google 的 http 服务器会返回日期/时间格式错误的 header 吗？

Question

问题

此问题不仅限于 Google 服务器； 我的客户与大多数 HTTP 服务器有同样的问题。

我使用一些框架向 Google 发送 HTTP 请求。 只有curl，但它适用于所有框架。

curl -i --http1.1 https://www.google.com

我收到了两个有趣的标题，我们应该讨论一下。 我将标头中未使用的值更改为“*”以更好地关注问题。

Date: Wed, 25 Jan 2023 13:45:10 GMT
Set-Cookie:**********; expires=Fri, 24-Feb-2023 13:45:10 GMT; ************************

如您所见，我们从set-cookie header 和date header 中得到了两种不同的日期和时间格式。

还有一个 HTTP 状态行，它告诉我们服务器响应是 HTTP/1.1。

HTTP/1.1 200 OK

我阅读了 rfc 7231 以更好地理解哪种格式是正确的。 这是我在“7.1.1.1 日期/时间格式”一节中发现的。

超文本传输协议 (HTTP/1.1)：语义和内容 RFC 7231

7.1.1.1. 日期/时间格式

内容：

在 1995 年之前，服务器通常使用三种不同的格式来传达时间戳。 为了与旧实现兼容，所有三个都在此处定义。 首选格式是 Inte.net 消息格式 [RFC5322] 使用的日期和时间规范的固定长度和单区域子集。

 HTTP-date = IMF-fixdate / obs-date

首选格式的一个例子是

 Sun, 06 Nov 1994 08:49:37 GMT; IMF-fixdate

两种过时格式的示例是

 Sunday, 06-Nov-94 08:49:37 GMT; obsolete RFC 850 format Sun Nov 6 08:49:37 1994; ANSI C's asctime() format

解析 HTTP header 字段中的时间戳值的接收者必须接受所有三种 HTTP 日期格式。 当发送方生成一个 header 字段，其中包含一个或多个定义为 HTTP-date的时间戳时，发送方必须以 IMF-fixdate 格式生成这些时间戳。

我的 HTTP 客户端支持所有三种格式，但是当我尝试解析 Google 响应时，我收到错误消息，因为 Google 发送的 set-cookie 属性为“Expires”，但与这些格式中的任何一种都不匹配。

结果

我从谷歌收到日期时间文本“Fri, 24-Feb-2023 13:45:10 GMT”

然而，rfc 告诉我们，我们的客户端应该只解析三种格式。

• 格林威治标准时间 2094 年 11 月 6 日星期日 08:49:37

• 1994 年 11 月 6 日星期日 08:49:37

• 1994 年 11 月 6 日，星期日 08:49:37 GMT

此列表中没有任何内容与谷歌的格式匹配。

有没有可能是我误解了什么或者 RFC 被忽略了？

我试图找到有关大多数 http 服务器使用的格式的信息，但没有任何结果。

Answer 1

RFC 7231 中描述的日期格式（BTW 已被 RFC 9110 废弃）仅适用于使用该特定 ABNF 的 header 字段 - cookies 不在 scope 中。

Answer 2

Cookies 由RFC 6265描述，因此可以在此处查找expires的语法。 但是，问题仍然如您所描述的那样：服务器使用的日期格式似乎与所需的语法不匹配。

我认为答案（正如 Julian Reschke 在评论中指出的那样）可以在第 5 节中找到，该节说出于互操作性的原因，用户代理应该准备好处理正式规范之外的语法。

本节详细说明了Cookie和Set-Cookie标头，以便实现这些要求的用户代理可以精确地与现有服务器进行互操作（即使那些不符合第 4 节中描述的良好行为配置文件的服务器）。

用户代理可以实施比此处指定的限制更多的限制（例如，为了提高安全性）； 然而，实验表明，这种严格性降低了用户代理与现有服务器进行互操作的可能性。

第 5.1.1 节列出了解析日期应遵循的特定算法：

用户代理必须使用与以下算法等效的算法来解析 cookie-date。

您看到的expires值与该算法兼容。

总而言之，当用户代理无论如何都被迫接受更宽松的语法时，服务提供商似乎并不觉得有必要生成符合严格语法的标头。