Er is veel te doen over HTTP versus HTTPS en met de “gratis” SSL-offloaders in de systemen van Sun Microsystems met de UltraSPARC T1, T2 en T2+ processor wordt het interessant om af te stappen van HTTP. Gelukkig hebben oa Intel-processoren optimalisatie voor oa AES en is met de juiste aanpassing aan het besturingssysteem en middleware zoals Apache mogelijk om SSL-verkeer sneller te laten afhandelen.
Nu kan je in de webapplicatie inbouwen dat dit moet gebeuren, maar als je massaal HTTP-verkeer naar HTTPS wilt migreren is het verstandiger om dit af te dwingen in de webserver. Zo ook voor een webmail-applicatie in dit geval waarbij de configuratie fouten kan opleveren en programmeurs snel fouten kunnen maken.
Door de volgende regels in de .htaccess-file te zetten in de documentroot van de website zal Apache tegen de webbrowser vertellen dat dit moet worden aangeleverd via HTTPS. Elke webbrowser die de HTTP statuscodes begrijpt zal dit vlekkeloos uitvoeren.
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
Aan deze oplossing zit wel een performance penalty verbonden. De initiale opbouw naar de website kan iets langer duren door de redirect naar de HTTPS-site, maar de grootste penalty zal zitten in de .htaccess-file. Bij productie websites is het dan ook verstandig om dit op te nemen in de virtual host configuratie binnen Apache zelf en de ondersteuning voor .htaccess-files uit te zetten. Hierdoor hoeft we webserver minder de documentroot voor de website af te zoeken naar oa de .htaccess-file.
Door te cachen kan veel worden versnelt, maar tot welke prijs? Elke applicatie lijkt tegenwoordig zijn eigen cache-oplossing te hebben voor bv favicons, data binnen gehaald via HTTP, avatars, icons, maar ook sessies. En dit is natuurlijk allemaal leuk en aardig, maar als je regelmatig een backup wilt maken dan begint dit langzaam een probleem te worden. Een kleine scan in mijn homedirectory levert al z’n 1,6GB aan data op wat te bestempelen is als vluchtig.
$ du -sk .thumbnails .cache .gnome2/epiphany/favicon_cache .liferea_1.6/cache .evolution/cache .evolution/mail/{imap,nntp} .mozilla/*/*/Cache .nautilus/metafiles .purple/icons .config/gnome-session .config/session-state | sort -nr
983740 .cache
573764 .thumbnails
38088 .evolution/mail/nntp
30296 .evolution/mail/imap
3324 .gnome2/epiphany/favicon_cache
3284 .mozilla/firefox/h18d1d1h.default/Cache
1268 .nautilus/metafiles
428 .purple/icons
368 .evolution/cache
188 .liferea_1.6/cache
108 .config/gnome-session
100 .config/session-state
Nu zal het veel nut hebben, maar heeft het echt zin om thumbnails te bewaren van bestanden die al lang zijn gearchiveerd in /dev/null. En is het zinvol dat verschillende applicaties een eigen cache vullen om zo snel mogelijk een favicon op het scherm te toveren. Gelukkig volgen steeds meer applicaties de guidelines van Freedesktop.org om cache bestanden op te slaan in $HOME/.cache zodat ze makkelijk te excluden zijn voor oa backup en timemachine-achtige applicaties.
De vraag blijft dan eigenlijk over hoe lang een item in een cache moet blijven staan. Als het oorsponkelijk object niet meer bestaat? Als het al 30 dagen niet meer is geraadpleegd? Als de expiretime van bv het originele object is verlopen? Of laten we dit afhangen van de hoeveelheid vrije schrijfruimte of van de ondegelegen storage zoals een harddisk vs solid state disk. Een andere beslissing kan zijn dan lokaal cachen goedkoper is dan van ver ophalen. Bij dit laatste vraag ik me af of een HTTP HEAD-request echt veel extra kost.
Recente reacties