Re: Server Push and Caching

> On 8 Sep 2016, at 3:22 AM, Roy T. Fielding <fielding@gbiv.com> wrote:

>>>> Note that HTTP does not put constraints on _how_ the application uses that response after it comes through the API or the cache; it might use it multiple times (e.g., an image might occur more than once on a page, or more than one downstream client might have made the request). It's just that this reuse isn't in the context of a HTTP cache's operation.
>> 
>> You're correct that an HTTP *client* isn't required to revalidate a response, but a cache is.
> 
> A cache isn't required to revalidate.  Only a client revalidates, and only
> when it wants to do so.  A cache never makes requests.  A cache is only required
> to mark the response as stale.

From previous discussions, I know that's your view, and I think it's internally consistent. I'm less convinced that view is shared by implementations, or even the specs.

RFC 7234, Section 4: "A cache that does not have a clock available MUST NOT use stored responses without revalidating them upon every use."

Section 4.2.4: "A cache MUST NOT generate a stale response if it is prohibited by an explicit in-protocol directive (e.g., by a "no-store" or "no-cache" cache directive, a "must-revalidate" cache-response-directive, or an applicable "s-maxage" or "proxy-revalidate" cache-response-directive; see Section 5.2.2)."

Section 4.3.2: "When a cache decides to revalidate its own stored responses for a request..."

Section 5.2.2.1: "The "must-revalidate" response directive indicates that once it has become stale, a cache MUST NOT use the response to satisfy subsequent requests without successful validation on the origin server."

Section 5.5.2:" A cache SHOULD generate this when sending a stale response because an attempt to validate the response failed, due to an inability to reach the server."

2616 contains much the same language.

Cheers,

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

Received on Thursday, 8 September 2016 00:07:23 UTC