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

Re: [Moderator Action] Question regarding the Cache Digest feature

From: Simeon Frid <simeon.frid@gmail.com>
Date: Wed, 17 May 2017 14:52:37 +0000
Cc: ietf-http-wg@w3.org
Message-Id: <CAGp_bqdMUf4oihakK6j96x9WRiT-T6V5J-98ZXfahEkENB+mCg@mail.gmail.com>
To: Mark Nottingham <mnot@mnot.net>
Thanks a lot!


ons 17 maj 2017 kl 11:00 skrev Mark Nottingham <mnot@mnot.net <mailto:mnot@mnot.net>>:
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:
  http://www.w3.org/mid/3904FEC0-4362-47A0-886A-B97FB97E2515@mnot.net <http://www.w3.org/mid/3904FEC0-4362-47A0-886A-B97FB97E2515@mnot.net>


> On 17 May 2017, at 1:53 am, Simeon Frid <simeon.frid@gmail.com <mailto: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/ <https://www.mnot.net/>

Received on Thursday, 18 May 2017 11:37:37 UTC

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