readium / readium-js-viewer

👁 ReadiumJS viewer: default web app for Readium.js library
BSD 3-Clause "New" or "Revised" License
551 stars 186 forks source link

Problem with blob URI and Service Worker #718

Open kennedybg opened 5 years ago

kennedybg commented 5 years ago

This issue is a Question

Related issue(s) and/or pull request(s)

See also #433*

Hi! I'm using exploded .epub files, loaded from the backend. Works like a charm. But when I put all these files in cache with Service Worker, the IMG and CSS files fail to load because they are being loaded with blob.

My question is: There is some way to use the absolute path and retrieve data from cache storage directly?

I'm almost finishing the cache feature: list all files, create a cache storage entry named by epub ID on backend, use put(request, response) method to simulate a request from service worker origin. All HTML is loaded normally, but IMG and CSS won't.

Anyone can help?

Thanks in advance!

danielweck commented 5 years ago

To recap: when the Readium cloud/web reader opens exploded / unzipped EPUBs, only the HTML documents are loaded as "blobs" into the host iframes (with their respective origin set via the "base URL"), all other resources (CSS, images, etc.) are loaded from their respective HTTP URLs, as normal. However, if the EPUB contains obfuscated fonts, then this triggers a special code path which requires all publication resources to be loaded via "blobs" (just like when opening packed / zipped EPUBs).

So, I fail to understand how a Service Worker caching strategy would change this pattern, as the SW "proxy" should transparently handle fetch requests, even if the HTTP response payload is ; behind the scenes ; constructed from a resource stored in a local cache. I am aware of issues related to audio/video "streaming" (HTTP partial requests / byte ranges), but this doesn't seem to be the case here, right?

Thank you for clarifying :)