Blog van Jeroen van der Gun

Cachemanifesten en het halve werk van Safari

De specificatie van HTML5 (‘de toekomst van het Internet’) voorziet in de behoefte om webapplicaties offline beschikbaar te maken. Met dit mechanisme kan een webmaster alles zodanig programmeren dat zijn website geen internetverbinding nodig heeft om te functioneren.

Dit systeem bestaat uit local storage en cache manifests. Het eerste is een offline databasesysteem, gebaseerd op SQL, om data op te slaan; het tweede is een manier om te zorgen dat alle benodigede HTML-, CSS- en JavaScript-bestanden van de website in de cache beschikbaar zijn. Dit laatste heb ik onderzocht in verband met een nieuwe website die ik aan het maken ben die extra comfort zou kunnen bieden door eenvoudige en volledige offline toegang te faciliteren zonder de hele site handmatig te moeten downloaden in een zip-bestand.

Wat direct opvalt aan de specificatie is dat het vooral gericht lijkt te zijn op compacte webapplicaties met databases en niet op grote websites zonder databases. Het voorbeeld is een eenvoudige klokapplicatie van slechts drie bestanden.

Mijn website krijgt honderden pagina’s. Dat is op zich niet erg, behalve dat de specificatie een ware denial of service-aanval uitvoert op de server door deze honderden aanvragen achter elkaar uit te voeren zonder enige vorm van pauze. De benodigde bestanden voor offlinegebruik moeten immers gewoon worden gedownload en een Web Hypertext Applications Techonogy Working Group (WHATWG) kan er natuurlijk geen rekening mee houden dat dit een grote Web 1.0-site zou kunnen zijn. Bij het verspreiden van updates introduceert de WHATWG hetzelfde probleem: je kunt met je manifest niet aangeven welke bestanden precies opnieuw moeten worden gedownload, alleen dat alles of niets opnieuw moet worden gedownload. Dus voor een kleine verbetering van een spelfout komen weer alle honderden pagina’s door de kabel. De schaalbaarheid van de specificatie laat dus te wensen over.

Tot nu toe zijn er twee browsers die cachemanifesten geïmplementeerd hebben: Firefox en Safari. Firefox verzacht de ellende door reguliere HTTP-caching toe te passen op de bestanden: bij het updaten is er dus de dataverkeerbesparende 304-statuscode mogelijk. Safari vergeet echter elke ETag en Last-Modified voor zowel het manifest als de andere honderden bestanden. In tegenstelling tot Firefox heeft Safari tevens oneindige wijsheid om niet om toestemming voor het cachen te vragen, maar dit automatisch te doen, met als grote kans dat een zeer groot deel van de honderden pagina’s voor niets wordt gedownload.

Safari brengt echter nog meer ellende naar de manifesten. De zogenaamde network online wildcard flag wordt ten eerste niet ondersteund, waardoor elk netwerkverkeer naar een niet-gespecificeerde domeinnaam wordt geblokkeerd. Zie hier ook de combinatie met het automatisch toepassen van manifesten en de ramp met gebroken afbeeldingen, scripts e.d. is voorspelbaar.

Ten tweede worden door Safari URL’s met fragment identifiers nooit uit de cache geladen, maar altijd via het netwerk. Als dus één van de honderden pagina’s verwijst naar een plaats halverwege een van de andere pagina’s, dan maakt Safari daar dus een gebroken link van. Zelfs de WHATWG heeft problemen hiermee voorzien en vraagt aandacht van browsermakers voor deze mogelijke valkuil in de specificatie, maar dat mocht voor Safari niet baten. De impact wordt hier overigens mogelijk vergroot door het vorige punt.

Ten derde zijn ETag en Last-Modified niet de enige HTTP-headers die verloren gaan bij opslag in de offline-cache van Safari: de cruciale Content-Type-header raakt ook verloren. Dus toen ging mijn mooie XHTML plotseling in de tag-soep-parser, met desastreuse gevolgen voor eventueel SVG en MathML op de pagina.

De conclusie is dat Safari er maar op los implementeert zonder stil te staan bij de gevolgen van onvolledige implementaties. Déjà vu van het video-element. Ook daar ging overigens een slecht doordachte specificatie aan vooraf.

Reacties (0)

Er zijn nog geen reacties. Wees de eerste.