'最保守'转换到GMT？

Question

科HTTP 1.1 RFC（2616）的19.3“容错应用程序”上，从HTTP客户端应用程序解析日期的主题说：

如果HTTP报头错误地承载具有比GMT以外的时区中的日期值，它必须转换成格林威治标准时间使用最保守的可能转换。

两个问题：

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

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

编辑虽然这现在是一个老问题了，我还是想知道答案，如果任何人有它。

Answer 1

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

这实际上是一个更具体的问题领域比什么是普遍适用的东西。有一个working group draft that would obselete RFC 2616有这样说的转换在缓存：

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

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

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

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