Subject: Clarification on stale-while-revalidate / stale-if-error

From: Will Sargent <[email-masked]>
Date: Wed, 6 May 2015 11:12:10 -0700

In RFC 5861, stale-while-revalidate has MAY priority
https://tools.ietf.org/html/rfc5861#section-3

When present in an HTTP response, the stale-while-revalidate
Cache-Control extension indicates that caches MAY serve the response
in which it appears after it becomes stale, up to the indicated number
of seconds.

Meanwhile, in RFC 7234,

   A cache MUST write through requests with methods that are unsafe
   (Section 4.2.1 of [RFC7231]
<https://tools.ietf.org/html/rfc7231#section-4.2.1>) to the origin
server; i.e., a cache is
   not allowed to generate a reply to such a request before having
   forwarded the request and having received a corresponding response.

So this means that stale-while-revalidate have no effect on unsafe methods
-- you can specify it on POST, but you'll have to wait for successful
revalidation.

However, stale-if-error doesn't have this problem -- it's just a 500, even
on an unsafe method.  So you ARE allowed to return stale in that case.
This would be interest in services which return a Location: header on
success, but could return errors because they don't deal with idempotency
well.

Does this sound right?

---

From: Amos Jeffries <[email-masked]>
Date: Thu, 07 May 2015 16:39:19 +1200

> success, but could return errors because they don't deal with idempotency

The specification seems right to me. stale-if-error is both passing teh
request through to server AND waiting for a server response (the error)
before anything gets sent to the client. So it already meets the
criteria for unsafe methods.

In regards to your statement about services that return Location
headers. That does not follow. stale-if-error could return the *wrong*
Location header if it was selected based on something in the POST.
Whether its useful to use stale-if-error on POST replies is a separate
decision based on intentions, which only the author of the service can make.

Amos

---

From: Will Sargent <[email-masked]>
Date: Thu, 7 May 2015 14:43:45 -0700

I agree that stale-if-error could return the wrong Location header -- my
understanding is that it's still allowable according to RFC 7234 for the
cache to return a stale response with incorrect data on a POST -- rather
than the 500 error -- if the origin server sends a Cache-Control header
containing stale-if-error.

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 9 May 2015 15:48:40 +1000

If there's something in-cache for a given URL, it's returned upon GET, not POST - see the description of POST's caching semantics here:
  http://httpwg.github.io/specs/rfc7231.html#POST

Cheers,

> On 8 May 2015, at 7:43 am, Will Sargent <[email-masked]> wrote:
> 
> I agree that stale-if-error could return the wrong Location header -- my understanding is that it's still allowable according to RFC 7234 for the cache to return a stale response with incorrect data on a POST -- rather than the 500 error -- if the origin server sends a Cache-Control header containing stale-if-error.
> 

--
Mark Nottingham   https://www.mnot.net/

---

From: Will Sargent <[email-masked]>
Date: Sun, 10 May 2015 12:39:36 -0700

So "write-through" here means the cache MUST reply with the response from
the origin server on an unsafe method, not a stale reply.  Got it.

On Fri, May 8, 2015 at 10:48 PM, Mark Nottingham <[email-masked]> wrote:

> If there's something in-cache for a given URL, it's returned upon GET, not
> POST - see the description of POST's caching semantics here: