- From: Ben Kelly <notifications@github.com>
- Date: Tue, 24 Sep 2019 08:20:12 -0700
- To: w3c/ServiceWorker <ServiceWorker@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/ServiceWorker/issues/1457/534604126@github.com>
Good questions. > What would be the expected flow for these apps? When the service worker is being installed (or at some later point), requests would be preemptively made to these vanity urls to ensure that they are cached ahead of the user going offline? I recall that there are stability issues with this: i.e. if the request fails, it will invalidate the cache entry (?). We don't have a good solution for how to prime the redirect without the user actually navigating to it. You can force this to happen with an iframe for same-origin urls, but for a cross-origin vanity url this would not reliably work since some browsers double-key storage for nested iframes. I think our position was that for users who have a particular workflow they would like visit the vanity url if they use it and get it cached. Not great, but its an improvement over the current behavior. Also, note the cross-origin issues I note above also make it impossible to register a service worker on cross-origin vanity urls. You can't register the service worker if the url is always redirecting and double-keying in browsers prevents using an iframe to the origin to register the service worker. > Also, would the resource ever be cached beyond the timeframe specified in its caching headers? I assume no? i.e. that the service worker would only prevent eviction up until the time specified by the resource cache headers. What we talked about at TPAC face-to-face was using the heuristic that if max-age is 1 year or more then the redirect would be permanent. As in we would not age it out even after a year. We could try to respect age headers, but it does raise the issue of how a site would re-prime the redirect. With our current idea I think the most natural thing would be for the redirect to expire and it would get re-primed on the next visit by the user. So you would have one request in the middle that is potentially not offlined. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/w3c/ServiceWorker/issues/1457#issuecomment-534604126
Received on Tuesday, 24 September 2019 15:20:34 UTC