'最保守'转换为GMT？

Question

HTTP 1.1 RFC（2616）的第19.3节“容忍应用程序”说明了从HTTP客户端应用程序解析日期的主题：

  

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

两个问题：

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

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

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

Answer 1

  

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

对于所涉及的领域而言，这实际上比通常应用的东西更具体。有一个working group draft that would obselete RFC 2616可以说明缓存中的转换：

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

  

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

在这种背景下，除了面对2个结果时，它似乎没有任何明确的意义，根据日期的背景选择最“保守”的日期。

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