これは、サーバーがGMT以外の日付値をGMTに変換する必要があることを意味しますか?または、(オプションで)GMT以外の日付値を(拒否するのではなく)GMTに変換することを選択した場合、可能な限り最も保守的な変換を使用する必要があることを意味しますか?
これは実際には、一般的に適用されるものよりも、問題の分野に固有のものです。キャッシュでの変換について次のように述べているRFC2616を廃止するワーキンググループドラフトがあります。
- HTTP / 1.1クライアントとキャッシュは、50年以上先のように見えるRFC-850の日付が実際には過去のものであると想定する必要があります(これは「2000年」問題の解決に役立ちます)。
- すべての日付形式は大文字と小文字を区別するように指定されていますが、受信者は曜日、週、タイムゾーンの名前を大文字と小文字を区別せずに一致させる必要があります。
- HTTP / 1.1実装は、解析された有効期限を適切な値よりも前に内部的に表すことができますが、解析された有効期限を適切な値よりも後に表すことはできません。
- 有効期限に関連するすべての計算は、GMTで実行する必要があります。ローカルタイムゾーンは、年齢または有効期限の計算または比較に影響を与えてはなりません(MUSTNOT)。
- キャッシュは、「GMT」以外のタイムゾーンの日付を無効と見なす必要があります。
「可能な限り最も保守的な変換」とはどういう意味ですか?
この文脈では、2つの結果に直面した場合を除いて、特に何も意味しないようです。日付の文脈に基づいて、最も「保守的な」日付を選択してください。
ファジー解析された2つの日付を考えると、Last-modified
ヘッダーのコンテキストでは、最も保守的なのは「後の」日付です。ただし、ヘッダーのコンテキストではExpires
、2つのうち早い方の方が保守的です。かなりの量の推測が必要なものは、エラー応答を返すだけです。