Re: Cache information [was: Support for page/resource size]

On 27 Aug 2014, at 5:29 am, Ilya Grigorik <igrigorik@google.com> wrote:

> 
> On Sun, Aug 24, 2014 at 9:06 PM, Nottingham, Mark <mnotting@akamai.com> wrote:
> FWIW - I've brought this up a number of times, IIRC on-list as well as privately with various folks.
> 
> AIUI implementers remain unconvinced of the value here -- at least enough to overcome the privacy concerns (which IMO are fairly minimal, but if you don't see the value in something, why take the risk?).
> 
> Maybe it's time to have the conversation again. I have a proposal that I can dust off...
> 
> We're exposing resource "age" via Resource-Freshness [1]... It seems reasonable to make same data available on the client via Resource/Nav Timing.

Yes. It struck me that if exposing the information through a JS API was problematic for privacy reasons, maybe putting it in a request header on the validation would be good enough; I mentioned that to Kenji in one of the bugs I opened.

BTW, Resource-Freshness is a *horrible* name, please change.


> In fact, wondering if "age" attribute could do the trick:
> 
> r = performance.getEntriesByName('https://www.example.com/resource');
> r.age # nil = resource is not cacheable by HTTP cache (e.g. no-cache, no-store, etc)
> r.age # 0 = resource was just placed in HTTP cache
> r.age # 1+ = resource was fetched from HTTP cache, and its age is...
> 
> For {nil, 0}, you'd know that a request was made, whereas 1+ indicates that request was served from local HTTP cache.

Iíll dust off the proposal I put together and forword it. 


> The one complication I can see here is interaction with ServiceWorker.. since SW could have intercepted the request and synthesized the response on its own, or served it from own cache. It's not clear to me how and if that should be communicated via Resource/NavTiming.

A separable problem, I think.

Cheers,

> 
> ig
> 
> [1] https://github.com/KenjiBaheux/resource-freshness/blob/master/specification.txt#L53

--
Mark Nottingham    mnot@akamai.com   http://www.mnot.net/

Received on Tuesday, 26 August 2014 22:05:44 UTC