[Twisted-web] Twisted and reverse proxies

[Maarten ter Huurne]

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