7
votes

While reading http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html, I found that the caching algorithm is more complex than I thought.

According to RFC2616, HTTP request is sent if response is fresh. and

response_is_fresh = (freshness_lifetime > current_age)

The current_age can be derived from max-age or Expires header, which both have nothing to do with local clock. However, the calculation of freshness_lifetime depends on local clock.

So, if local clock of browser is not consistent with clock at server side. Is it possible that HTTP caching doesn't exempt unnecessary request sent?

Thanks

1
Now, I suppose browses just compute current_age as now - "time response is received". It is easy and simple. Anyway, application should not depend its behavior on cache.Morgan Cheng

1 Answers

2
votes

Their clocks do not have to be in sync, but the client needs a working clock to be able to determine the age of a cached resource and match that against max-age. If max-age is not present in the response, a client could calculate it by comparing the Date and Expires headers to each other.

However, if the client were to suffer from extreme clock skew, the cache would break down and resources could get cached incorrectly since their age can not reliably be determined.