stale-while-revalidate experimental implementation.

net/http/http_response_headers.cc

Index: net/http/http_response_headers.cc
diff --git a/net/http/http_response_headers.cc b/net/http/http_response_headers.cc
index 3a9f7e04fe0c4bad6a232ae52270e55427532d03..8075b12dfd82c86f6714f5c50983dfbd5ea757e1 100644
--- a/net/http/http_response_headers.cc
+++ b/net/http/http_response_headers.cc
@@ -956,15 +956,29 @@ bool HttpResponseHeaders::IsRedirectResponseCode(int response_code) {
 // 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;
-
-  return lifetime <= GetCurrentAge(request_time, response_time, current_time);
+// 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);
+
+  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:
@@ -987,8 +1001,11 @@ bool HttpResponseHeaders::RequiresValidation(const Time& request_time,
 //
 //   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.
@@ -996,16 +1013,15 @@ TimeDelta HttpResponseHeaders::GetFreshnessLifetime(
       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.
@@ -1016,10 +1032,12 @@ TimeDelta HttpResponseHeaders::GetFreshnessLifetime(
   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:
@@ -1052,19 +1070,22 @@ TimeDelta HttpResponseHeaders::GetFreshnessLifetime(
     // 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: