petter wrote: > I'm using squid in front of weblocks, and it seems like if I update a > static document, i.e. a pdf file or png file I seem to get stale data
It all depends on how you serve those pdf/png files. Can you post code? If your png is part of the page design/css and lives under /pub then imho it's reasonable to require a refresh to see a new page design. If the pdf is generated/retrieved by clicking a link then you can add a handler that renames it and thus neatly sidesteps the issue of caching (see below). > only. Is there a way to make sure the cache is invalidated? If you're using squid as a reverse proxy, then you have to look at the cache-invalidation rules for it (expires header and cache-control). The request simply does not reach Weblocks. We use nginx, and the price of setting an expires header of 1 year on our /pub directory is exactly that: 1) We cannot keep recently generated PDF content there .. 2) If we make changes to some static js and css in /pub we have to use a browser refresh to see changes. Also, afaik, weblocks does a bundling and versioning of dependencies now, or else it is pending inclusion. So any .css and .js files should be automatically taken care of via that mechanism. In this paste [] the function make-actual-pdf runs a LaTeX process and returns a file name, this function can also decide if the data has changed, and therefore a new pdf needs to be generated, or if the existing pdf on disk is "current". In the former case it can simply return the same file name, in the latter, it changes the filename to say orig.1.pdf This makes it possible to use a maximum expiration header on the / reports path, with the code deciding either to return a (possibly cached) original link, or returning a new, cache-busting-filename link. Currently though, we use maximum expiration only for /pub and redirect / with a 0 expiration to the Weblocks port. -- You received this message because you are subscribed to the Google Groups "weblocks" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/weblocks?hl=en.
