'最保守'转换为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(而不是拒绝它),那么它必须使用最保守的可能转换？

对于所涉及的领域而言,这实际上比通常应用的东西更具体.有一个工作组草案,可以通过RFC 2616来解释缓存中的转换:

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

什么是"最保守的可能转换"？

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

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