'最保守'轉換到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的較早部分更保守。任何需要大量猜測的東西都應該返回錯誤響應。