Open cco3 opened 9 years ago
Interesting, but this is complex. Typically cache headers are associated with an http GET, which we are not. For the final page content, which is cacheable, the browser already implements this, not us.
We could create a custom protocol and add to our REST api, but the scan is very likely for a short-url with no cache lifetime, and so you shouldn't circumvent the lookup. (Though this isn't always the case, some urls are short). Other times, the metadata associated with the request affects the reply (like distance), which means clients would have to implement all our filtering logic.
So, I guess we should brainstorm this further. While I'm not convinced this will help very often, some people have asked for an offline solution and I think this is as elegant as I've seen proposed.
On Tue, Jun 16, 2015 at 5:56 PM Conley Owens notifications@github.com wrote:
If a client wants to keep a local cache, the cache headers from the website would make it easier to do that properly.
— Reply to this email directly or view it on GitHub https://github.com/google/physical-web/issues/415.
Well, this isn't so much for an offline solution as it is for the situation where I'm sitting at my desk and every five minutes check the news on my phone. While the scan that I trigger doesn't take up too much battery, I'm going to be seeing the same beacons each time and shouldn't be hitting the radio.
Typically cache headers are associated with an http GET, which we are not.
Could you explain more? PWS does a GET request to the url and receives cache headers. I'm not seeing the issue with forwarding that along in the metadata object.
I mean that the App uses a POST to resolve-scan. We cannot just include the cache-control header as part of the response in the typical way which lets the infrastructure leverage it. We would have to add it to our api and have clients actually implement caching.
At that point, there is no specific reason to use the http cache header format (except that it may be good to borrow concepts).
Oh, right, I wasn't suggesting we keep the format or put it in the http response. I was just saying that the metadata should include a value that lets the client know how long the metadata is going to be good for.
It doesn't make sense to put it in resolve-scan at the http level because you can call resolve-scan on multiple urls at once.
Sounds good. Prerequisite is actually parsing cache-control headers (I thought we had a feature files for this, but cannot find it), and also making we understand all the situations where the cache can get invalidated.
If a client wants to keep a local cache, the cache headers from the website would make it easier to do that properly.