NekR / offline-plugin

Offline plugin (ServiceWorker, AppCache) for webpack (https://webpack.js.org/)
MIT License
4.52k stars 294 forks source link

CDN #84

Open NekR opened 8 years ago

NekR commented 8 years ago

It's common to use CDN when you develop web applications and other that CDN lives on separate sub-domain, like cdn.example.com.

There is no problem handling CDN resources with ServiceWorker (except that those resources must have CORS headers). But with AppCache it isn't essentially possible to cache cross-domain resources over HTTPS.

One possible solution is to generate 2 manifests: 1 for main domain (the app) and 2 for the CDN. Roughly, it can look like this:

new OfflinePlugin({
  cdn: {
    assets: ['*.js']
  }
})
navgarcha commented 7 years ago

Is the problem that if you utilise mode: no-cors that the non local assets are responding with response.ok === false? As this is what I'm getting. If this is the case do we have to ensure all assets respond with CORS headers?

Having said this, if we do indeed have mode: no-cors set and we make requests with type: 'opaque' do we not ALWAYS get response.ok === false even on successful requests. In this situation the logic to check response.ok will be inaccurate. Perhaps !response.ok && response.type !== 'opaque' would be better suited? Granted I don't really know what the knock on affects are of caching a potential 404 response..

See: http://stackoverflow.com/questions/36292537/what-is-an-opaque-request-and-what-it-serves-for

NekR commented 7 years ago

Is the problem that if you utilise mode: no-cors that the non local assets are responding with response.ok === false? As this is what I'm getting. If this is the case do we have to ensure all assets respond with CORS headers?

Yes, exactly. With mode: no-cors response.ok is false for cross-origin requests unless those responses provide correct CORS headers.

do we not ALWAYS get response.ok === false even on successful requests. In this situation the logic to check response.ok will be inaccurate

It's accurate is possible. You don't response status there and don't want to cache 404 or 500 or other responses with error status. Hence, not allowing to cache opaque responses. Otherwise users may get broken app for a very long time and you certainly don't want it.

Granted I don't really know what the knock on affects are of caching a potential 404 response..

If you cache 404 response, you always server assets with 404 from the cache.

navgarcha commented 7 years ago

That makes sense - was thinking out loud slightly there :)

Perhaps a note in the README or a more informative error message might be useful around the 'no-cors' mode?

NekR commented 7 years ago

@navgarcha Yeah, I think it makes sense to add it to README or to the FAQ. Would you mind to do the PR?

navgarcha commented 7 years ago

Done: https://github.com/NekR/offline-plugin/pull/158