Cache header magic (or how I learned to love http response headers)

Is your site dead slow? Does it use excessive bandwidth? Let me take you on a short journey to the place where you can lessen your worries: the http-response-headers, where some wee small lines of text can define how your site is loaded in cached.
So you’re interested and you are going to read on? In that case let me skip the foolishness (I’m too tired already) and move on to the real stuff. There are 3 types of caching-directives that can be put in the http response: permission-, expiry- and validation-related headers:

  1. Permission-related http response headers tell the caching algorithm if an object can be kept in cache at all. The primary way to do this (in HTTP/1.1-land) is by using cache-control:public, cache-control:private or cache-control:nocache. Nocache should be obvious, private indicates individual browser caches can keep a copy but shared caches (mainly proxies) cannot and public allows all caches to keep the object. Pre-http/1.1 this is mainly done by issuing a Last-Modified-date (Last-Modified; although that in theory is a validation-related cache directive) which is set in the future.
  2. The aim of expiry-related directives is to tell the caching mechanism (in a browser or e.g. a proxy) that upon reload the object can be reused without reconnecting to the originating server. These directives can thus help you avoid network roundtrips while your page is being reloaded. The following expiry-related directives exist: expires, cache-control:max-age, and cache-control:s-maxage. Expires sets a date/time (in GMT) at which the object in cache expires and will have to be revalidated. Cache-control:Max-age and Cache-control:s-maxage (both of which which take precedence if used in conjunction with expires) define how old an object may get in cache (using either the ‘age’ http response header or calculating the age using (Expires – Current date/time). s-maxage is to be used by shared caches (and takes precedence over max-age there), whereas max-age is used by all caches (you could use this to e.g. allow a browser to cache a personalised page, but prohibit a proxy from doing so). If neither expires, cache-control:max-age or cache-control:s-maxage are defined, the caching mechanism will be allowed to make an estimate (this is called “heuristic expiration“) of the time an object can remain in cache, based on the Last-Modified-header (the true workhorse of caching in http/1.0).
  3. Validation-related directives give the browser (or caching proxy) a means by which an object can be (re-)validated, allowing for conditional requests to be made to the server and thus limiting bandwith usage. Response-headers used in this respect are principally Last-Modified (date/timestamp the object was … indeed modified the last time) and ETag (which should be a unique string for each object, only changing if the object got changed).

And there you have it, those are the basics. So what should you do next? Perform a small functional analysis of how you want your site (html, images, css, js, …) to be cached at proxy or browser-level. Based on that tweak settings of your webserver (for static files served from the filesystem, mostly images, css, js) to allow for caching. The application that spits out html should include the correct headers for your pages so these can be cached as well (if you want this to happen, off course). And always keep in mind that no matter how good you analyze your caching-needs and how well you set everything up, it all depends on the http-standards (be it HTTP/1.0 or 1.1) the caching applications follows (so you probably want to include directives for both HTTP/1.0 and 1.1) and how well they adhere to those standards … Happy caching!
Sources/ read on:

(Disclaimer: there might well be some errors in here, feel free to correct me if I missed something!)

Koffieculturen

Als de kwaliteit van de koffie een bepalende factor is in mijn beroepsgeluk (en geloof me, dat is zo), dan ben ik hier in Brussel een tevreden drinker. Net zoals in Mechelen (bij dat andere telco-bedrijf) brouwen hier grote, donkere machines van Maas International echt goeie koffie op verzoek. Bekertje voor bekertje, met echte gemalen koffie, de eerste twee van de dag gratis, daarna 15 cent per portie.
Absoluut geen reden om een Starbucks in de buurt te zoeken dus en voor zover ik weet is dat er ook niet in Brussel. Misschien staan we nog niet op die sport van de koffie-ontwikkelingsladder, want in de USA lijkt het cafeĆÆne-snobisme (“a Venti Caramel Macchiato to go please”) veel meer aanwezig, als je films en televisie-series als Sex and the City of Ally McBeal mag geloven. En anderzijds zie je bv. in de coffee-loving “Gilmore girls” die andere uiting van koffie in de States; achter de toog van de diner een grote kan met urenlang verwarmde zwarte prut die -beeld ik me in- toch echt niet beter kan zijn dan het zurige afwaswater dat bij mijn ex-werkgever uit Gent uit de grote Miko-percolator in schilferende thermoskannen kwam gepist?
Nee, laat mij maar aanschuiven bij Maas’ machines voor mijn fix. En thuis, thuis zet ik hem zelf, en bedenk ik dat ik ook daarvoor de Atlantische Oceaan niet over moet.

Gevaar; je toekomstig werkgever leest mee!

Dat je moet oppassen wat je op internet schrijft over je werkgever, wist je wel al. Maar in de V.S. blijken HR-officers nu ook meer en meer de online capriolen van sollicitanten te screenen. Blogs, maar ook youtube-publicaties en onzin op online communities (myspace, forums, …) kunnen immers veel meer vertellen dan wat je over jezelf zou meedelen, wanneer die strenge mevrouw vraagt om 3 negatieve karaktereigenschappen op te noemen.
Meer op cnet.com: Want a job? Clean up your web act!
En dat verklaart direct waarom ik amper geheadhunt word šŸ˜‰

Migratie-migraine

Met het opdoeken van de gratis typepad-gehoste telenetblogs moest ik op zoek naar een nieuwe blogwoonst. Alhoewel ik over een serverke op internet beschik, had ik weinig goesting om me met installatie en configuratie en onderhoud van de software bezig te houden. En zo kwam ik algauw bij de gratis wordpress.com-blogs uit. Bleef dan de kwestie van het importeren van mijn oude blogposts. De Typepad-blogs konden geĆ«xporteerd worden, importeren was ‘a piece of cake’ (enkele html-tag-problemen daargelaten).
Waar net iets meer werk in kroop, was het importeren van mijn nog oudere posts uit een antieke nucleus 2-installatie. Niet eenvoudig (want in de nucleus-rss ontbrak heel wat en in de hosted wordpress kun je geen rss importeren). Maar volgende stappen hebben me uiteindelijk het verhoopte resultaat opgeleverd:

  • aanpassen nucleus-code om in de rss zowel ‘body’ en ‘more’ (samen) te tonen in de description-tag
  • aanpassen nucleus-code om in de rss de maximum lengte van de string in de description-tag te vergroten
  • opvragen en bewaren van de rss, de al via typepad geĆ«xporteerde posts handmatig verwijderen
  • installeren en configureren van wordpress op mijn serverke (toch ja ..)
  • php.ini op mijn serverke aanpassen om file-uploads mogelijk te maken
  • aanpassen van rechten op filesysteem zodat wordpress zelf upload-directory kan aanmaken
  • de rss-import op mijn tijdelijke blog gebruiken om de nucleus-rss te importeren
  • de wordpress export-functie op mijn tijdelijke blog gebruiken om te exporteren
  • de wordpress-export gebruiken om in mijn wordpress.com-blog te importeren
  • en dan de tijdelijke blog op mijn serverke verwijderen en -nu ik er aan denk- de wijzigingen in php.ini ongedaan maken …

Maar we zijn er, al mijn blogposts staan nu proper op 1 plaats en ik voel me dus al een beetje thuis. Nu nog gelezen worden šŸ˜‰

Doe open die proxy!

Omdat het op het werk niet altijd eenvoudig surfen is naar porno- of hacker-sites, heeft een mens al eens alternatieven voor de almachtige coorporate proxy nodig.
Dat je met firefox + putty + openssh-op-je-linux-serverken al veel kunt bereiken, is ongetwijfeld al gekend. Samengevat: de ‘dynamic port forwarding‘ optie in putty (en andere ssh-clients) opent een socks proxy op je eigen computer. Firefox kan via die socks proxy dan over de ssh-tunnel requests voor de meest ongepaste wwwebpagina’s de wereld insturen, zonder dat de bigcompany-proxy daar weet van heeft. En met de Firefox Switchproxy-extensie kun makkelijk switchen tussen bedrijfs- en je persoonlijke proxy.
EĆ©n probleem rest er ons nog; de dns-requests gebeuren in bovenstaand scenario wel nog op het bedrijfsnetwerk. Als je in Firefox een URL intikt, zal die eerst moeten worden omgezet in een ip-adres. Die “vertaling” gebeurt door de DNS-servers van je werkgever en zo laat je de coorporate wwwatchdogs toch weer weten dat je de duistere kant van het net op wilt.
De oplossing daarvoor zit verborgen in de kelders van je Firefox-preferences; in about:config vind je de setting network.proxy.socks_remote_dns. De waarde van die instelling staat standaard op “false” maar wanneer die op “true” staat, wordt de vertaling van URL naar IP-adres effectief in alle privacy via je socks-proxy aan de andere kant van de ssh-tunnel afgehandeld. Nu alleen nog zorgen dat die collega die achter je zit, die blote schoon madammen op je scherm niet ziet … šŸ˜‰

Mijn kleine scatologie

Er is iets magisch aan mijn dochterken
en aan haar pis en aan haar kak
want elke keer we haar verversen
– “kijk mama, mooie strontjes” of
“da’s weer flink geplast ze lieze” –
dan grijnzen we alledrie voldaan,
blij met ons welriekend geluk.
Een Gelukkig Nieuw Jaar!
frank, veerle & elise