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

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 <mnot@mnot.net> 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:
>   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/
>
>
>
>
>