Qiita Teams that are logged in
You are not logged in to any team

Log in to Qiita Team
Community
OrganizationAdvent CalendarQiitadon (β)
Service
Qiita JobsQiita ZineQiita Blog
20
Help us understand the problem. What is going on with this article?
@0xfffffff7

webにおけるキャッシュと時刻の話

More than 5 years have passed since last update.

RFC7234でキャッシュについて定義されている。
https://tools.ietf.org/html/rfc7234

こちらのサイトも参考になりそう。
https://www.mnot.net/cache_docs/

Expires

その時刻まで有効の意味。

Expires: Fri, 30 Oct 1998 14:19:41 GMT

これは1年以上未来の日付にするべきではない。

Cache-Control

有効期限を秒数で表す。開始基準はDateヘッダーの時刻。
Expiresより優先される。

Cache-Control: max-age 3600

キャッシュさせたくない場合。

Cache-Control: no-cache

プロキシサーバーなどにキャッシュさせたくない場合。

Cache-Control: no-store

その他にプロキシサーバを制御する指定ができる。

キャッシュ名 意味
Cache-Control: public プロキシでキャッシュする時にユーザーが違う場合でも共有可能
Cache-Control: private ユーザーごとに異なる必要がある
Cache-Control: no-transform プロキシがコンテンツタイプなどを変更してはいけない
Cache-Control: must-revalidate プロキシは必ずオリジンサーバーへの検証が必要
Cache-Control: proxy-revalidat プロキシはオリジンサーバーへの検証が必要
Cache-Control: s-maxage プロキシに対して適用されるmaxage
Cache-Control: stale-while-revalidate プロキシが有効期限切れデータをクライアントに返していい猶予秒数
Cache-Control: stale-if-error 上位サーバーがエラーだった場合に保持しているコンテンツをクライアントに返してもいい秒数

 
 

Last-Modified

まずサーバー側が最終更新日付とコンテンツのハッシュをレスポンスで返す。

Last-Modified: Thu, 18 Dec 2014 23:45:00 GMT
Etag: "ffjjlfee38fd879fjfe78988dfg"

Etagはサーバーが様々な条件で生成する。

広告などで毎回内容が変わる場合でも中身のコンテンツが同じなら同じになるように工夫する必要がある。このハッシュの計算に、ディスクノードを使用すると冗長構成時に別の値になるので使用しない方がいい。
コンテンツの意味にも注意する。なんらかの一覧を取得する場合は、その一覧のどれかが更新されていれば意味的にはコンテンツが新しいことを返した方がいい。

クライアントは条件付きリクエストでコンテンツを調べる。

if-Modified-Since: Thu, 18 Dec 2014 23:45:00 GMT

もしくは、

if-None-Match: "ffjjlfee38fd879fjfe78988dfg"
if-None-Match: W/ "ffjjlfee38fd879fjfe78988dfg"

と書けば、弱い検証となり、完全一致ではないがデータの意味が一致する場合に利用する。動的に毎回一部が必ず変わるページなど。

サーバーはコンテンツに変更がなければ304を返す。

Vary

リクエストヘッダーによってレスポンスが変化する場合は、そのことをレスポンスヘッダーであらかじめ教えておく。カンマ区切りで複数指定可能。

Vary: Accept

 
 

HTTP時間

RFC 2616で定義されている。
HTTPで使えるのは三つ。

RFC
RFC 822 (RFC 1123) Thu, 18 Dec 2014 23:45:00 GMT
RFC 850 (RFC 1036から廃止) Thursday, 18 Dec 2014 23:45:00 GMT
ANSI C Thu Dec 18 23:45:00 2014

 
 
RFC 822はRFC 1123でアップデートされた。
現在はRFC 1123を使う事が望ましい。

インターネット標準時間

HTTPヘッダに限ってはRFC 1123が標準だが、それ以外のケースでプログラム的に日付を扱う場合はRFC 3339で定義されているインターネット標準の時刻を使う。

2014-12-19T23:30:00+00:00

+09:00を使うよりも世界標準に合わせて+00:00を使った方がいい。
その場合は、

2014-12-19T23:30:00Z

と記述する事が可能。

ただし、現実には+09:00はよく使われる。

UNIXタイムスタンプ(epoch秒)

1970年1月1日からの経過秒数。
機械的に時刻を処理する際によく使われる。
内部的な実装でこちらの方が都合がよければ、こちらを採用しても良い。
外と通信ならインターネット標準のRFC 3339を使用する。

GMT(グリニッジ標準時)とUTC(世界協定時)

HTTPでは時刻はGMTを使う。
二つはほぼ同時刻を表している。
UTCの方が正確だが、100年で18秒ずれる。

日本時間は9時間プラスされるので、「UTC時刻+09:00」と表記する。

20
Help us understand the problem. What is going on with this article?
Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away

Comments

No comments
Sign up for free and join this conversation.
Sign Up
If you already have a Qiita account Login
20
Help us understand the problem. What is going on with this article?