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

On 7/05/2015 6:12 a.m., Will Sargent wrote:
> 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?
> 

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

Received on Thursday, 7 May 2015 04:40:07 UTC