search

google / physical-web

The Physical Web: walk up and use anything
http://physical-web.org
Apache License 2.0
5.99k stars 665 forks source link

PWS should report cache headers to clients #415

Open cco3 opened 9 years ago

cco3 commented 9 years ago

If a client wants to keep a local cache, the cache headers from the website would make it easier to do that properly.

mmocny commented 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.

cco3 commented 9 years ago

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.

cco3 commented 9 years ago

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.

mmocny commented 9 years ago

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).

cco3 commented 9 years ago

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.

mmocny commented 9 years ago

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.

mmocny commented 9 years ago

416