stale-while-revalidate experimental implementation.

net/http/http_response_headers.cc

 // Copyright (c) 2012 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 // The rules for header parsing were borrowed from Firefox:
 // http://lxr.mozilla.org/seamonkey/source/netwerk/protocol/http/src/nsHttpResponseHead.cpp
 // The rules for parsing content-types were also borrowed from Firefox:
 // http://lxr.mozilla.org/mozilla/source/netwerk/base/src/nsURLHelper.cpp#834
 
 #include "net/http/http_response_headers.h"
@@ skipping 938 matching lines @@
 
 // From RFC 2616 section 13.2.4:
 //
 // The calculation to determine if a response has expired is quite simple:
 //
 //   response_is_fresh = (freshness_lifetime > current_age)
 //
 // Of course, there are other factors that can force a response to always be
 // validated or re-fetched.
 //
-bool HttpResponseHeaders::RequiresValidation(const Time& request_time,
-                                             const Time& response_time,
-                                             const Time& current_time) const {
-  TimeDelta lifetime =
-      GetFreshnessLifetime(response_time);
-  if (lifetime == TimeDelta())
-    return true;
+// From RFC 5861 section 3, a stale response may be used while revalidation is
+// performed in the background if
+//
+//   freshness_lifetime + stale_while_revalidate > current_age
+//
+HttpResponseHeaders::ValidationType HttpResponseHeaders::RequiresValidation(

[rvargas (doing something else), 2014/08/29 23:36:07]

We don't need the class name on the return value, do we?

[Adam Rice, 2014/09/01 14:43:00]

Yes, we do.

+    const Time& request_time,
+    const Time& response_time,
+    const Time& current_time) const {
+  TimeDelta lifetime;
+  if (GetFreshnessLifetime(response_time, &lifetime) == NEVER_FRESH)
+    return VALIDATION_SYNCHRONOUS;
+  TimeDelta age = GetCurrentAge(request_time, response_time, current_time);
 
-  return lifetime <= GetCurrentAge(request_time, response_time, current_time);
+  if (lifetime > age)
+    return VALIDATION_NONE;
+
+  TimeDelta stale_while_revalidate;
+  if (GetStaleWhileRevalidateValue(&stale_while_revalidate) &&
+      lifetime + stale_while_revalidate > age)
+    return VALIDATION_ASYNCHRONOUS;
+
+  return VALIDATION_SYNCHRONOUS;
 }
 
 // From RFC 2616 section 13.2.4:
 //
 // The max-age directive takes priority over Expires, so if max-age is present
 // in a response, the calculation is simply:
 //
 //   freshness_lifetime = max_age_value
 //
 // Otherwise, if Expires is present in the response, the calculation is:
 //
 //   freshness_lifetime = expires_value - date_value
 //
 // Note that neither of these calculations is vulnerable to clock skew, since
 // all of the information comes from the origin server.
 //
 // Also, if the response does have a Last-Modified time, the heuristic
 // expiration value SHOULD be no more than some fraction of the interval since
 // that time. A typical setting of this fraction might be 10%:
 //
 //   freshness_lifetime = (date_value - last_modified_value) * 0.10
 //
-TimeDelta HttpResponseHeaders::GetFreshnessLifetime(
-    const Time& response_time) const {
+HttpResponseHeaders::FreshnessType HttpResponseHeaders::GetFreshnessLifetime(

[rvargas (doing something else), 2014/08/29 23:36:07]

:(

Can we just say that in order to have async revalidations the lifetime has to be
grater than zero? If a server is changing to add the new header, it might as
well set max_age or similar. Use revalidation with lifetime of zero is a
confusing signal to me: "always check with the server, and by the way, use it
for a while without checking with the server"

[Adam Rice, 2014/09/01 14:43:00]

The problem is that max-age=0,stale-while-revalidate=300 does have a
well-defined behaviour, and is indeed in use.
http://www.myspass.de/myspass/media/images/pix.gif and a number of other URLs
from that domain are served with:

Cache-Control:
must-revalidate,max-age=0,s-maxage=300,stale-while-revalidate=300,stale-if-error=420,
must-revalidate,max-age=0,s-maxage=300,stale-while-revalidate=300,stale-if-error=420

I can try to make the implementation less ugly, but I don't think we should
ignore this case just because it makes the code ugly.

[rvargas (doing something else), 2014/09/03 01:25:53]

The ugly code (two, maybe contradictory outputs) is just the consequence of the
conceptual contradiction I mentioned, which is what I don't like.

Note that the spec says:
  "Note that "stale" implies that the response will have a non-zero Age
   header and a warning header, as per HTTP's requirements."

So I read that as saying that the headers from that site are invalid, or at
least that we can ignore the SWR part.

[Adam Rice, 2014/09/05 15:17:11]

If this is true, then it should apply also for max-age=0 by itself, regardless
of any other Cache-Control directives.

There are 4 sites in the HTTP Archive that set max-age=0 along with a Warning:
110 and an Age: header. And 53,000 that don't.

I think people are voting with their feet that max-age=0 does not mean stale.
Although it definitely doesn't mean fresh either.

I personally don't see a contradiction. The way I see it, max-age=0 is slightly
different from Cache-Control: no-cache and distinctly different from
Cache-Control: no-store, and Chrome's cache has only gotten away with treating
them the same up until now because it never supported stale resources.

Once we support stale resources then the differences start to matter and we
can't treat them the same any more.

For what it's worth, I've changed the "Freshness" type slightly so that it is
impossible to set contradictory values (at least not without doing ugly tricky
with const_cast).

[rvargas (doing something else), 2014/09/05 22:52:39]

I don't follow what you mean.
Same here.
Well... I guess I know where you're going. The Warning header is meant to be
used by proxies to tell clients that they are returning resources that may be
stale. I don't think we will ever show a dialog to the user saying that
something may be stale, in the context of stale as understood by the HTTP spec.
(nor in the context of the SWR RFC). So the appearance in the quote that I made
was circumstantial.

But you are right, max-age and no-cache are different if we return stale entries
:(

(see the other comments)

+    const Time& response_time,
+    TimeDelta* lifetime) const {
+  *lifetime = TimeDelta();
+
   // Check for headers that force a response to never be fresh.  For backwards
   // compat, we treat "Pragma: no-cache" as a synonym for "Cache-Control:
   // no-cache" even though RFC 2616 does not specify it.
   if (HasHeaderValue("cache-control", "no-cache") ||
       HasHeaderValue("cache-control", "no-store") ||
       HasHeaderValue("pragma", "no-cache") ||
       HasHeaderValue("vary", "*"))  // see RFC 2616 section 13.6
-    return TimeDelta();  // not fresh
+    return NEVER_FRESH;
 
   // NOTE: "Cache-Control: max-age" overrides Expires, so we only check the
   // Expires header after checking for max-age in GetFreshnessLifetime.  This
   // is important since "Expires: <date in the past>" means not fresh, but
   // it should not trump a max-age value.
 
-  TimeDelta max_age_value;
-  if (GetMaxAgeValue(&max_age_value))
-    return max_age_value;
+  if (GetMaxAgeValue(lifetime))
+    return MAYBE_FRESH;
 
   // If there is no Date header, then assume that the server response was
   // generated at the time when we received the response.
   Time date_value;
   if (!GetDateValue(&date_value))
     date_value = response_time;
 
   Time expires_value;
   if (GetExpiresValue(&expires_value)) {
     // The expires value can be a date in the past!
-    if (expires_value > date_value)
-      return expires_value - date_value;
+    if (expires_value > date_value) {
+      *lifetime = expires_value - date_value;
+      return MAYBE_FRESH;
+    }
 
-    return TimeDelta();  // not fresh
+    return NEVER_FRESH;
   }
 
   // From RFC 2616 section 13.4:
   //
   //   A response received with a status code of 200, 203, 206, 300, 301 or 410
   //   MAY be stored by a cache and used in reply to a subsequent request,
   //   subject to the expiration mechanism, unless a cache-control directive
   //   prohibits caching.
   //   ...
   //   A response received with any other status code (e.g. status codes 302
@@ skipping 12 matching lines @@
   //
   // https://datatracker.ietf.org/doc/draft-reschke-http-status-308/ is an
   // experimental RFC that adds 308 permanent redirect as well, for which "any
   // future references ... SHOULD use one of the returned URIs."
   if ((response_code_ == 200 || response_code_ == 203 ||
        response_code_ == 206) &&
       !HasHeaderValue("cache-control", "must-revalidate")) {
     // TODO(darin): Implement a smarter heuristic.
     Time last_modified_value;
     if (GetLastModifiedValue(&last_modified_value)) {
-      // The last-modified value can be a date in the past!
-      if (last_modified_value <= date_value)
-        return (date_value - last_modified_value) / 10;
+      // The last-modified value can be a date in the future!
+      if (last_modified_value <= date_value) {
+        *lifetime = (date_value - last_modified_value) / 10;
+        return MAYBE_FRESH;
+      }
     }
   }
 
   // These responses are implicitly fresh (unless otherwise overruled):
   if (response_code_ == 300 || response_code_ == 301 || response_code_ == 308 ||
       response_code_ == 410) {
-    return TimeDelta::Max();
+    *lifetime = TimeDelta::Max();
+    return MAYBE_FRESH;
   }
 
-  return TimeDelta();  // not fresh
+  return NEVER_FRESH;
 }
 
 // From RFC 2616 section 13.2.3:
 //
 // Summary of age calculation algorithm, when a cache receives a response:
 //
 //   /*
 //    * age_value
 //    *      is the value of Age: header received by the cache with
 //    *              this response.
@@ skipping 319 matching lines @@
   return true;
 }
 
 bool HttpResponseHeaders::IsChunkEncoded() const {
   // Ignore spurious chunked responses from HTTP/1.0 servers and proxies.
   return GetHttpVersion() >= HttpVersion(1, 1) &&
       HasHeaderValue("Transfer-Encoding", "chunked");
 }
 
 }  // namespace net