Slimmer dan je proxy(-admins)!

Proxies zijn vreemde dingen met een olifantengeheugen en bezorgen je soms een oude versie van een file die je van internet wilt plukken. Dat willen we niet en gelukkig is daar een simpele oplossing voor, een eenvoudige “bookmarklet” (stukje javascript-code dat vanuit de bookmarks wordt opgeroepen) zal die proxy wel even voor U temmen.
Een voorbeeld: om de meest recente versie van het fantastische Gilles Peterson’s Worldwide van de StuBru servers te plukken, zonder dat de bedrijfsproxy me de versie van bv. vorige week of afgelopen maand geeft, heb ik ipv dit:

http://download.streampower.be/vrt/stubru/41_41gpwo-hi.mp3

het volgende in mijn bookmarks:

“javascript:(function(){rnd=Math.floor(Math.random()*1000000);url = ‘http://download.streampower.be/vrt/stubru/41_41gpwo-hi.mp3?n=’ + rnd;location.href=url;})()

Deze bookmarklet zal elke keer opnieuw een willekeurig cijfer generen en dat aan de URL plakken (die wordt dan bv. http://download.streampower.be/vrt/stubru/41_41gpwo-hi.mp3?n=234219). Omdat proxies bestanden in cache bijhouden aan de hand van de volledige URL, zal de proxy die file (inclusief random number) niet in zijn geheugen kunnen terugvinden en wordt er speciaal voor jou een nieuwe versie van dat bestand afgehaald. Veel luistergenot!

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!)

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 … 😉

how google stole my video

zsazu, zo wilde ik het geesteskind noemen waarmee ik de wereld ging veroveren. de toekomst van nternetvideo, mee op de golf van web 2.0: cross-platform flash-gebaseerde video publishing als een service! tot google video met elke nieuwe release meer van mijn ideeen bleek te valideren en daarmee zsazu naar het mindmap-kerkhof verwees, waar menig concept om middernacht jammerend met de kettingen rammelt .. gooogle! gooooooooogle!!
met zsazu (of zou het toch zazu geworden zijn?) zou ik video-publishers (AV-media en gelieerde bedrijven in eerste instantie, portaal- en webbouwers in tweede instantie) de mogelijkheid bieden om op eenvoudige wijze cross-platform video-bestanden te publiceren.
ik brainstormde elke avond met mezelf (mindmapping for dummies), mailde met macromedia en kleine would-be concurrenten, deed testen met software-componenten en werkte zelfs al aan een prototype.
het idee was krachtig én eenvoudig: de originele file laten uploaden via een web-interface, op de server zou die file verwerkt en geconverteerd worden naar een flv-bestand en de eigenaar zou dan per mail een klein blokje html of javascript ontvangen waarmee de flash video in de eigen site gepublished kon worden. dat stukje javascript zou een geavanceerde flash applicatie oproepen die de eigenlijke video-file (flv) zou ophalen (met een security-laag errond waardoor een gebruiker nooit aan de eigenlijke flv-file zou kunnen) en (eventueel na betaling, want dat moest ook mogelijk zijn) afspelen. daar zou tenslotte nog een laag logging en reporting-functies rond geschreven worden om de eigenaar alle nodige inzicht in consumptie van zijn of haar online video-materiaal te geven.
dat alles zou met een paar bestaande en bewezen componenten (beginnen met 1 linux webserver met apache webserver, php voor administratie en flv-wrapper-functies, mysql database voor sessiebeheer en 1 linux server voor videoconversie met ffmpeg, aangestuurd door shellscripts of in extremis perl, python of php-cli-scripts) en een keigoeie flash applicatie op betrekkelijk korte tijd (ik dacht aan pakweg 3 maand) in test op te zetten zijn.
en dan, met een goeie demo als breekijzer, dan was het een kwestie van een paar vissen aan de haak te slaan die met mij in zee wilden (paar investeerders, paar klanten die vroeg aan boord zouden springen) en we zouden op weg geweest zijn om een leuk web 2.0-bedrijfje uit te bouwen. tot pakweg vorige week.
want vorige week las ik dat google begin q4 van 2005 voor hun video-project -dat al een tijdje ontwikkeld wordt- beslist had om de switch te maken van een eigen ontwikkelde client-applicatie (een stand-alone google videoplayer) naar publishing in flash video. en naarmate de google video hype groter werd (naar aanleiding van de aankondiging van het feit dat google ook video van oa broadcasters ging verkopen) en er dagelijks functionaliteit bij gereleaset werd, bleek dat zsuza ook bestond in de knappe koppen van de verlichte zoekdespoten. google was me voor en deed het beter dan ik het ooit gedaan zou kunnen hebben. een pracht van een applicatie, op alle vlakken!
en zsazu, .. die naam hou ik in mijn achterhoofd voor het volgende lumineuze idee. want ooit moet ik alle nitwits ter wereld toch voor kunnen zijn. toch? 😉