WebViewer Version: 8.3.0
"No" to all of these questions:
- Do you have an issue with a specific file(s)?
- Can you reproduce using one of our samples or online demos?
- Are you using the WebViewer server?
- Does the issue only happen on certain browsers?
- Is your issue related to a front-end framework?
- Is your issue related to annotations?
lib/ directory)? If we were to aggressively cache these, would the cache inherently be broken across WebViewer client upgrades?
Hello, I’m Ron, an automated tech support bot
While you wait for one of our customer support representatives to get back to you, please check out some of these documentation pages:
I don’t think we have any recommended cache headers. There have been a few cases where certain full API methods become unavailable due to caching the worker files and the pathing to fetch them: Unknown action from worker: GetPDFDoc when using WebViewer within PWA. Although it may depend on how this is done.
I would perhaps cache with query strings to denote the version so that changing versions will cause the newer files to get cached instead.
@Andy_Huang, how are we able to configure WebViewer to append a unique query string to the assets it loads? From what we can tell, we are only able to configure a
Sorry for the ambiguity!
For server responses, you could perhaps consider some of the cache directives outlined here: Cache-Control - HTTP | MDN.
If you want to try the query string method, you would have to apply it to the scripts referenced on the page. Specifically
Are you referring to the scripts referenced in the embedded iframe (
We just copy those over from
node_modules/@pdftron/webviewer in the current state of our Next.js application build, and I don’t see a straightforward way of appending query parameters to those assets outside of applying processing to that HTML file. Is that how you typically see users doing this?
For additional context, deploying a new WebViewer version is causing issues for some of our users due to browser asset caching. For example, affected users experience at least this error:
We are looking for a solution that breaks the WebViewer asset cache across version upgrades. Otherwise (across other application deploys in which WebViewer is not upgraded), it seems to make sense to aggressively cache these unchanged assets.
Ah, thanks for the clarification. Some users are manually integrating WebViewer and some are on NPM.
I didn’t notice this, but apparently we have a FAQ on this: PDFTron Systems Inc. | Documentation. You can prefix the lib folder with the version.