Mit Hilfe von URL-Fingerprinting ist es möglich, Dateien sehr lange zu cachen (für ein Jahr), jedoch auch gleichzeitig eine Änderung ohne Wartezeit zu publizieren. Was darunter genau zu verstehen ist und wie eine Implementierung aussehen könnte, zeigt dieser Artikel auf.
In der Dokumentation des Tools Page Speed von Google wird auf das Cacheverhalten von Webbrowsern eingegangen. Es ist möglich durch senden von Headern eine Datei bis zu einem Jahr zu Cachen – was den Seitenaufbau signifikant beschleunigt. Theoretisch ist es auch möglich eine Datei länger als ein Jahr im Cache zu halten – dies verstösst jedoch gegen die RFC, es ist also nicht garantiert dass sich jede Client-Applikation daran hält, bzw. korrekt reagiert. Doch was genau ist jetzt URL-Fingerprinting.
Definition URL-Fingerprinting
Beim URL-Fingerprinting wird ein Fingerprint, eine alhphanumerische Zeichenkette in den Link integriert, meist als Präfix für die Datei. Beispiel:
gewöhnliche URL: images/thumb/logo.png
URL mit Fingerprint: images/thumb/e4d909c290d0fb1ca068ffaddf22cbd0logo.png
Doch wieso sollte man die URLs komplizierter machen, als diese in Realität sind?
Warum URL-Fingerprinting
Der Fingerprint ist imaginärer Bestandteil der URI zum Datenobjekt, das heißt, selbst wenn wir den Fingerprint ändern, erhalten wir – je nach Implementierung – ggf. auch das Datenobjekt, in diesem Fall das Bild. So ist es möglich dass folgende URIs alle auf die gleiche Datei verweisen:
- images/thumb/e4d909c290d0fb1ca068ffaddf22cbd0logo.png
- images/thumb/d41d8cd98f00b204e9800998ecf8427elogo.png
- images/thumb/9e107d9d372bb6826bd81d3542a419d6logo.png
Der Vorteil ist nun, dass ich für die Datei logo.png festlegen kann, sie soll für ein Jahr im Browser gecached werden. Muss ich aber nach 5 Monaten eine Änderung machen, ändere ich einfach den Fingerprint: der Browser interpretiert die neue URI als unbekanntes, neues Objekt und lädt deshalb das Element herunter. Dadurch ist gewährleistet, dass ich meine Daten sehr lange Cachen und jederzeit eine Änderung erzwingen kann.
Wann URL-Fingerprinting nutzen
URL-Fingerprinting sollte immer dann benutzt werden, wenn absehbar ist, dass eine Datei lange nicht geändert wird. Der Mimetyp der Datei ist hierbei egal: die Methode kann auf CSS, Javascript, Bilder und/oder Binär-Dateien angewandt werden. Theoretisch kann jedes Objekt über URL-Fingerprinting angesprochen werden, jedoch macht dies URLs unleserlich und weniger komfortabel – deshalb ist es besser dies auf “nicht sichtbare URIs” wie die von Bildern, CSS/JS und Co zu verwenden.
Was macht einen guten Fingerprint aus
Ein Fingerprint sollte nur aus Zeichen bestehen, welche auch ohne Probleme in einer URL verwendet werden dürfen (Buchstaben und Zahlen). Auf Umlaute sollte genauso wie auf den / bzw. \ verzichtet werden, da dies zu Schwierigkeiten bei der Darstellung bzw. Pfadangabe führen kann. In der Praxis hat sich eingebürgert Fingerprints mit dem Aufbau [a-z0-9] zu verwenden, also Kleinbuchstaben und Zahlen.
Auch muss der Fingerprint eine gewisse Länge haben. Ein Bug im Firefox welcher zu Kollisionen mit Cachedateien führt kann dadurch umgangen werden, dass sich die URL mindestens um acht Zeichen unterscheidet.
Google setzt beim Google Kalender eine 128-Bit hexadezimalzahl ein (32 Stellen), um CSS-Dateien mit einem entsprechenden Fingerprint zu versehen:
URL-Fingerprinting bei Google Kalender
Mögliche Implementierung von URL-Fingerprinting
Der Fingerprint wird als imaginäres Verzeichnis in den Dateipfad eingeklingt
gewöhnliche URL: static/images/thumb/logo.png
URL mit Fingerprint: static/images/thumb/9e107d9d372bb6826bd81d3542a419d6/logo.png
Hier prüft eine Rewrite-Engine die URI auf den Aufbau static/…/<fingerprint>/logo.png und leidet auf static/…/logo.png weiter.
Realisiert werden kann dies z.B. unter Apache mit mod_rewrite.
Weitere Informationen findet man hierzu unter http://www.modrewrite.de/ und in der offiziellen Dokumenation zu mod_rewrite.
