On Wednesday 31 March 2010, Ray Cote wrote:
One note, you ask how your static resources 'will react' to being reverse proxied. When running Twisted behind Apache, we find it most useful to serve all the static files directly from Apache and leave Twisted to serve only the dynamic content. No reason to use Twisted to serve static files when there's a perfectly good Apache server available.
In most cases you are right, but there can be a reason to let Twisted serve the static files. For performance it is best to set the expiery date of a static resource a long time (1 year) into the future. That way, the browser can load it once and uses its cached version ever after. However, if you change the resoure, for example to add elements to your style sheet, you want the new version to be used instead of the outdated cached version. To force the new version to be loaded without reducing the expiery time dramatically or having to manually flush the browser's cache, you can give the new version a new URL. You could put the release version in the URL: "app/static/1.0", "app/static/1.1" etc. That works well for deployed apps, but is still a pain for development. So what I did instead was generate a unique ID on startup of the app and use that ID in the URL: "app/static-HDUI89BDY3/main.css", "app/static-HDUI89BDY3/icon.png" etc. So after a content chance, an app restart ensures the browser will refetch everything. An alternative would be to compute a hash of the static content and use that hash the URL. That way you would not need an application restart when static content changes. Bye, Maarten