Caching of Physical Web Destination URLs

[scottjenson]

This issue was raise by @biteknight in the Eddystone repos, I'm just copying it here to be answered by the Physical Web team. cc @mmocny and @adriancretu

---

Issue - When using Google Chrome, upon URI sighting a ‘googleBot’ agent traverses all page re-directs and pulls the final destination url, title, and description. This data is then cached (across devices) for approximately 5 minutes and all interactions with this beacon in this time period will land directly on the final destination URL without going through the original redirects. Additionally cache busters are ignored even when they follow Google’s cache busting schema.

This presents two issues:
Dynamic Query String Parameters are rendered essentially useless. Take Google’s physical web example of a smart parking meter. Consider the following URL structure: https://foo.com/xxxxx?time_remaining=42 where xxxxx represents the parking meeter id. and time_remaining is measured in minutes. The parking meter web app located at foo.com references both the meter ID and time_remaining attribute to set the page state when the user interacts with the nearby URI. Because Android and Chrome cache the entire URL for 5 minutes and subsequent interactions do not go through page re-directs, users will never see an accurate representation of the time remaining on the parking meter.

Accurate reporting is also made impossible when the destination URL differs from the broadcast URL. Fundamentally Eddystone beacons broadcast a short URL that may or may not direct users to a longer destination URL. Many users rely on reporting Physical Web interactions by counting the number of people who land on the broadcast URL. In this way popularity by beacon location can be captured and compared to overall page statistics. Because users are sent directly to the cached destination URL, reporting on a beacon level is not possible for experiences where the destination differs from the broadcast URL.

[biteknight]

@scottjenson Thank you for consolidating the issues and pointing us in the right direction. Looping in @mdamiani84 @artkay

[kevinahuber]

To clarify and add- is this behavior live for Android Chrome/Nearby only?

And no caching of the broadcast URL occurs in iOS Chrome and the Open Source PWS.

Is all of that correct @scottjenson? I appreciate sharing this behavior- it has been tricky finding some of the nuances of nearby without the ability to look at the code. Any and all information possible on the differences between the Chrome/Nearby PWS and the Open Source PWS speeds up Physical Web development.

Related document- https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9

I think the biggest gain would be from honoring the Pragma: no-cache header. Expiration would also help, but just the ability to tell the PWS to not cache is a good start.

[rochforp]

It does seem like this destination caching is limited to Android Nearby/Chrome and is pretty consistent when using the Android PW app with the Google PWS. Not seeing it with the OpenSource versions though which is probably why iOS is not exhibiting it. Correct me if I'm wrong but I think iOS is still on the OS PWS... at least for the time being. Caching the scan (shortened) url and subsequently, the destination url could really slow things down because of the limitations already on the size of the Eddy-URL packets. I'm voting for the Pragma: no-cache I suppose or just making the functionality similar to that of the OS PWS.