Summary

  • Le premier brouillon W3C de Web Storage, daté du 23 avril 2009, prend l’exemple d’un voyageur qui compare deux vols dans deux fenêtres. Un cookie utilisé pour mémoriser le vol en cours peut mêler les deux réservations.
  • sessionStorage suit la fenêtre et l’origine ; localStorage suit l’origine au-delà de cette fenêtre. Le navigateur peut ainsi garder des données sans les joindre à chaque requête HTTP.

Le voyageur hésite. Le premier vol part à l’aube, le second à une heure où l’aéroport vend surtout du courage en gobelet. Il ouvre une fenêtre pour chaque option. Dans la première, il remplit ses coordonnées. Dans la seconde, il regarde le supplément bagage. Il revient au premier onglet, clique pour payer et découvre que le site a retenu l’autre voyage. On entend presque le cookie répondre : « Vous aviez demandé de mémoriser un vol. J’en ai mémorisé un. »

Cette mésaventure figure dans le brouillon W3C de Web Storage du 23 avril 2009. Le document imagine même qu’un client achète deux billets pour le même vol sans s’en apercevoir. Il vise un défaut très précis : quand deux fenêtres d’un même site partagent un cookie qui représente « le vol actuel », chacune peut écraser le choix de l’autre. La facture donne à la question du périmètre des données une netteté remarquable.

Le cookie accompagne les requêtes adressées au site. Il rend service au serveur qui veut reconnaître le navigateur et suivre une session. Mais le voyageur, lui, mène deux opérations simultanées. Il lui faut une mémoire attachée à chaque fenêtre. Le navigateur connaît déjà cette frontière : chaque document appartient à un contexte de navigation de premier niveau. La proposition de Web Storage transforme cette frontière en espace de rangement pour les scripts.

Le premier tiroir porte le nom de sessionStorage. La Recommandation de 2013 attribue à chaque contexte de premier niveau un ensemble de zones de stockage, une par origine. Les pages du même site qui se succèdent dans une fenêtre retrouvent les choix du voyageur. Une autre fenêtre dispose de sa propre zone. Lorsqu’une fenêtre apparentée s’ouvre, elle peut recevoir une copie initiale ; ensuite, les deux copies vivent séparément. On peut donc comparer deux vols sans que le choix « aller à Lyon » colonise soudain la réservation « aller à Lisbonne ».

L’origine compte autant que la fenêtre. Elle désigne le site auquel appartient la zone. Deux sites différents ne fouillent pas librement dans le même tiroir. Pour la réservation en cours, l’adresse complète des données comporte ainsi le site et la fenêtre. Le programme n’a plus à inventer une ruse pour reconnaître lequel des deux voyages l’utilisateur poursuit.

Le second tiroir, localStorage, répond à une autre durée. Il conserve des paires clé-valeur pour une origine, accessibles entre ses fenêtres et au-delà d’une séance de navigation. Le texte envisage des documents rédigés par l’utilisateur ou une boîte aux lettres gardés dans le navigateur. Un cookie serait renvoyé avec chaque requête ; une valeur locale demeure côté navigateur jusqu’à ce que le script la lise et que l’application décide de l’envoyer. Pour montrer le mécanisme, la spécification choisit même un compteur de visites. C’est un souvenir modeste, mais il n’a pas besoin de voyager dans toutes les enveloppes.

La deuxième édition de 2016 précise la mécanique. setItem, getItem, removeItem et clear manipulent les entrées. Une écriture qui échoue faute de place ou à cause d’une restriction laisse la zone intacte ; setItem peut lever QuotaExceededError. Les autres documents ayant accès à la même zone peuvent recevoir un événement storage après une modification. La cohérence entre scripts est exigée, sans imposer qu’une écriture attende la fin d’une opération physique sur le disque.

Une dispute d’ingénieurs affleure dans la section « Issues » de la version 2013. Le verrou proposé pour prévenir les courses entre scripts paraissait trop coûteux à certains implémenteurs. La commodité d’un petit tiroir partagé soulevait donc une question beaucoup moins pittoresque : combien de travail le navigateur devait-il accomplir pour que deux fenêtres voient un état cohérent ? Le billet d’avion a une histoire de concurrence cachée sous son étiquette.

L’historique de publication du W3C déroule le trajet du brouillon de 2009 aux Recommandations de 2013 et 2016. L’exemple des deux réservations survit à ces étapes parce qu’il met le doigt sur le bon problème. Une transaction en cours habite une fenêtre ; des données conservées pour le site habitent l’origine ; le cookie prend la route vers le serveur. Trois adresses, trois usages. Le voyageur, lui, voulait simplement choisir son vol.