On May 3, 2010, at 2:01 PM, Olemis Lang wrote: > On 5/3/10, Remy Blank <[email protected]> wrote: >> Olemis Lang wrote: >>> I am not sure , but I suppose that if a timestamp (e.g. CSS | EGG file >>> creation time) is sent back to the client when requesting static >>> resources then the browser should notice that there's a new file in >>> the server and reload it into its own cache >> >> >> Chrome.process_request() uses Request.send_file() to send the .css files >> back to the client. >> >> send_file() sends a Last-Modified header, and also processes an incoming >> If-Modified-Since header to send a 304 reply if the file hasn't changed. >> However, this has no effect on client-side caching, and the client uses >> the cached copy without validating with the server. AFAIK, there's no >> mechanism for the server to notify the client that it should purge its >> cache. >> > > AFAIK the only thing that can be done is what you mentioned above , > i.e. provide headers indicating modification date and so on on and let > the browser decide what version (cached vs updated) will be used to > render the web page
The way other projects get around this is to put a version-specific query argument in the path of every resource. The argument itself is ignored, but by changing it you can force cache updates (or rather, the new URL isn't in any cache since it is brand new). Never really loved the practice since I think it makes the URLs ugly, but it is an option. --Noah -- You received this message because you are subscribed to the Google Groups "Trac Users" 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/trac-users?hl=en.
