[Twisted-web] Twisted and reverse proxies
Maarten ter Huurne
maarten at treewalker.org
Wed Mar 31 05:42:36 EDT 2010
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
More information about the Twisted-web