オリジンWebサーバーが応答ヘッダーのexpires値を、比較的ずっと前に経過した時間として設定した場合はどうなりますか。
たとえば、現在の時刻が2013年1月25日GMTの金曜日であり、expireヘッダーが->として設定されているとします。
有効期限:1994年12月1日木曜日16:00:00 GMT
クライアントは上記のインスタンスに対してどのように応答しますか?
どんな助けでもいただければ幸いです
オリジンWebサーバーが応答ヘッダーのexpires値を、比較的ずっと前に経過した時間として設定した場合はどうなりますか。
たとえば、現在の時刻が2013年1月25日GMTの金曜日であり、expireヘッダーが->として設定されているとします。
有効期限:1994年12月1日木曜日16:00:00 GMT
クライアントは上記のインスタンスに対してどのように応答しますか?
どんな助けでもいただければ幸いです
ヘッダー内の過去の日付Expired
(ヘッダー値より前Date
)で応答することは意味がなく、重大な構成ミスの兆候となる可能性があります。そうは言っても、クライアントはそのような応答を「すでに期限切れ」として扱い、キャッシュしません。Expires
日付がヘッダー値と等しいDate
場合(サーバーが応答を「すでに期限切れ」としてマークする正しい方法です)、または無効な形式の場合も同様です。
詳細については、RFC2616の「有効期限」セクションを参照してください。
過去の特定の固定された日付を指す有効期限は、比較的貧弱な構成や比較的貧弱な(スターター)コードでよく見られます。そのため、HTTP1.1クライアントが応答をキャッシュしないようにすることが目的です。これは機能しますが、過去の特定の固定された日付は明らかにばかげています。の値の0
方が理にかなっている、またはDate
応答ヘッダーとまったく同じ値です。これはあまり見られませんが、以下に引用するHTTPExpires
ヘッダー仕様で推奨されています(私の強調)。
..。
HTTP / 1.1クライアントとキャッシュは、他の無効な日付形式、特に値「0」を過去のように(つまり、「すでに期限切れ」)処理する必要があります。
応答を「すでに期限切れ」としてマークするために、オリジンサーバーはDateヘッダー値と等しいExpires日付を送信します。(セクション13.2.4の有効期限計算のルールを参照してください。)
..。
RFC 7234から:
If an origin server wishes to force a cache to validate every
request, it can assign an explicit expiration time in the past to
indicate that the response is already stale.
これにより、これが有効な動作であり、クライアントは応答を古いものとして扱い、後続のすべての呼び出しで検証する必要があることが明確になります。