W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2017

Re: Question regarding the Cache Digest feature

From: Mark Nottingham <mnot@mnot.net>
Date: Wed, 17 May 2017 19:00:24 +1000
Cc: ietf-http-wg@w3.org
Message-Id: <E4BDD462-98B1-4463-99E1-7237270F457F@mnot.net>
To: Simeon Frid <simeon.frid@gmail.com>
Hi Simeon,

That's not part of the current design; we don't specify a way for the server to tell the client that a stored response is stale outside the context of a request.

You *could* do this with server push, but that hasn't been specified to such a level of detail. Doing that is something we've discussed in the past. See thread starting here:


> On 17 May 2017, at 1:53 am, Simeon Frid <simeon.frid@gmail.com> wrote:
> Hi,
> I have a question regarding how this feature will work on the client-side. From reading the work document I don't quite understand whether this will support invalidating a client asset, even if it has not expired in the client resource cache (i.e. doing a cache bust from the server).
> I'm absolutely new to standard works and am probably not using the correct terminology, but I'll try to explain: Let's say a client sends a cache digest including an asset X, and the server responds: "Your asset X is stale". My question is whether the client will then update asset X, even if asset X is fresh according to the client's resource cache.
> If this mechanism works as I'm thinking, this feature could be used as an alternative to URL cache busting (invalidating a fresh client-cached resource by renaming the resource URL from the server-side). Is that a correct assumption?
> Kindly,
> Simeon

Mark Nottingham   https://www.mnot.net/
Received on Wednesday, 17 May 2017 09:01:00 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:15:03 UTC