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

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 <will.sargent@gmail.com> 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.
> 
> On Wed, May 6, 2015 at 9:39 PM, Amos Jeffries <squid3@treenet.co.nz> wrote:
> 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
> 
> 
> 

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

Received on Saturday, 9 May 2015 05:49:11 UTC