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 115 matching lines @@
   bool is_continuation() const { return name_begin == name_end; }
 
   std::string::const_iterator name_begin;
   std::string::const_iterator name_end;
   std::string::const_iterator value_begin;
   std::string::const_iterator value_end;
 };
 
 //-----------------------------------------------------------------------------
 
+HttpResponseHeaders::Freshness::Freshness() : usable(false) {}
+HttpResponseHeaders::Freshness::Freshness(const TimeDelta& lifetime)
+    : usable(true), lifetime(lifetime) {}
+HttpResponseHeaders::Freshness::~Freshness() {}
+
+//-----------------------------------------------------------------------------
+
 HttpResponseHeaders::HttpResponseHeaders(const std::string& raw_input)
     : response_code_(-1) {
   Parse(raw_input);
 
   // The most important thing to do with this histogram is find out
   // the existence of unusual HTTP status codes.  As it happens
   // right now, there aren't double-constructions of response headers
   // using this constructor, so our counts should also be accurate,
   // without instantiating the histogram in two places.  It is also
   // important that this histogram not collect data in the other
@@ skipping 803 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(
+    const Time& request_time,
+    const Time& response_time,
+    const Time& current_time) const {
+  Freshness freshness = GetFreshnessLifetime(response_time);
+  if (!freshness.usable)
+    return VALIDATION_SYNCHRONOUS;
+  TimeDelta age = GetCurrentAge(request_time, response_time, current_time);
 
-  return lifetime <= GetCurrentAge(request_time, response_time, current_time);
+  if (freshness.lifetime > age)
+    return VALIDATION_NONE;
+
+  TimeDelta stale_while_revalidate;
+  if (GetStaleWhileRevalidateValue(&stale_while_revalidate) &&
+      freshness.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(
+HttpResponseHeaders::Freshness HttpResponseHeaders::GetFreshnessLifetime(
     const Time& response_time) const {
   // 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 Freshness();
 
   // 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;
+  TimeDelta lifetime;
+  if (GetMaxAgeValue(&lifetime))
+    return Freshness(lifetime);

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

We have to look at must-revalidate before deciding if this could be usable.

[rvargas (doing something else), 2014/09/11 02:33:06]

?

[Adam Rice, 2014/09/12 01:46:48]

The existing code doesn't look at must-revalidate in this case. I don't want to
change behaviour.

[rvargas (doing something else), 2014/09/12 18:33:12]

must-revalidate doesn't matter for the current code as there is a clear signal
about when to consider the resource fresh. However, the new code extends that
clear signal with another one, saying that if it is not fresh, it still can be
used... that last part depends on must-revalidate so it has to be considered.

[Adam Rice, 2014/09/16 11:53:00]

Done.

 
   // 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) {
+      return Freshness(expires_value - date_value);
+    }
 
-    return TimeDelta();  // not fresh
+    return Freshness();

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

This may be usable

[Adam Rice, 2014/09/09 12:36:45]

Acknowledged.

   }
 
   // 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) {
+        return Freshness((date_value - last_modified_value) / 10);
+      }
     }
   }
 
   // These responses are implicitly fresh (unless otherwise overruled):
   if (response_code_ == 300 || response_code_ == 301 || response_code_ == 308 ||
       response_code_ == 410) {
-    return TimeDelta::Max();
+    return Freshness(TimeDelta::Max());

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

must-revalidate again

[Adam Rice, 2014/09/09 12:36:46]

This never becomes stale, so must-revalidate is a no-op.

[rvargas (doing something else), 2014/09/11 02:33:05]

doh!

   }
 
-  return TimeDelta();  // not fresh
+  return Freshness();

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

may be usable.

I think things are simpler if this becomes GetFreshnessLifetimes() and returns
two deltas instead of one.

The current structure of this method is to look at all relevant headers and come
up with _the_ delta when this resource is considered fresh (and keep
RequiresValidation  trivial).

Now we know that there could be an extra delta after that, when the resource may
be used. Given that we are looking at all other headers, except SWR, it makes
more sense to look at the new header and return the two values that
RequiresValidation would need.

[Adam Rice, 2014/09/09 12:36:46]

Done.

 }
 
 // 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