Cache Busting Breaks S3 Pre-Signed Requests

[mohammad-matini]

Description

The cacheBust option appends a random query parameter to the request URL, which forces the browser to re-request the resource. This, however, does not work with servers that refuse additional query parameters, or require involved steps to use them, like S3 for example. Simply using cacheBust with S3 signed URLs will result in 403 Forbidden errors, as the request signature will no longer match.

(No example fiddle, hard to reproduce without backend code).

Solution

Add option to completely disable cache using HTTP headers

HTTP caching can be disabled completely by using the appropriate headers; Cache-Control: no-store and Pragma: no-store. This will force the browser to re-request the resources, without modifying the request URL.

We have implemented HTTP header-based cache busting in our own fork. A bit rough around the edges, but we've been using it in production at Workiom for five months so far, and it works like a charm. You can find the code on: https://github.com/mohammad-matini/dom-to-image/commit/cce60295f88ef7d192bbf72b70d9a4fbbe867f47

Library Version

2.6.0

Browsers

• [X] Chrome 49+
• [X] Firefox 45+

[aminsaedi]

Exact same issue here.

I still get CORS error when using your fork with setting cacheDisable to true.

can you please help me how to resolve it?

[mohammad-matini]

@aminsaedi

Exact same issue here. I still get CORS error when using your fork with setting cacheDisable to true.

The issue I'm talking about here is not a CORS issue, but rejected signed URLs after dom-to-image changes them.

There are many reasons why a CORS error might be happening, most of them do not have anything to do with dom-to-image. Please take a look at Mozilla's guide for debugging CORS errors and determine the exact reason why the CORS error is happening. If you think it is an issue with the caching of CORS-related headers, and dom-to-image not busting the cache correctly, then please open a new issue to discuss that.