6

HTTP 1.1 RFC (2616) 的第 19.3 节“容忍应用程序”关于从 HTTP 客户端应用程序解析日期的主题说：

如果 HTTP 标头错误地携带了时区不是 GMT 的日期值，则必须使用最保守的可能转换将其转换为 GMT。

两个问题：

  1. 这是否意味着服务器必须将非 GMT 日期值转换为 GMT？或者这是否意味着如果（可选）它选择将非 GMT 日期值转换为 GMT（而不是拒绝它），那么它必须使用最保守的可能转换？

  2. “最保守的可能转换”是什么意思？

编辑虽然这是一个老问题，但如果有人知道答案，我仍然很感兴趣。

4

1 回答 1

5

这是否意味着服务器必须将非 GMT 日期值转换为 GMT？或者这是否意味着如果（可选）它选择将非 GMT 日期值转换为 GMT（而不是拒绝它），那么它必须使用最保守的可能转换？

这实际上比一般应用的东西更具体到所讨论的领域。有一个工作组草案将淘汰 RFC 2616，它对缓存中的转换有这样的说法：

  • HTTP/1.1 客户端和缓存应该假设 RFC-850 日期看起来超过 50 年实际上是过去（这有助于解决“2000 年”问题）。
  • 尽管所有日期格式都指定为区分大小写，但收件人应该不区分大小写匹配日、周和时区名称。
  • HTTP/1.1 实现可以在内部将解析的过期日期表示为早于正确的值，但不能在内部将解析的过期日期表示为晚于正确的值。
  • 所有与到期相关的计算必须在 GMT 中完成。本地时区不得影响年龄或到期时间的计算或比较。
  • 缓存应该认为时区不是“GMT”的日期无效。

“最保守的可能转换”是什么意思？

在这种情况下，它似乎并没有什么特别的意思，除了面对 2 个结果时，根据日期的上下文选择最“保守”的日期。

给定 2 个模糊解析的日期，在Last-modified标题的上下文中，最保守的将是“较晚”的日期。但在Expires标题的上下文中，2 中的较早者更为保守。任何需要大量猜测的东西都应该只返回一个错误响应。

于 2012-08-25T17:35:14.803 回答