La gestion des cookies est un champ de mines

• Cookies HTTP : petits fragments de données utilisés pour conserver l’état du web, inclus dans toutes les requêtes HTTP une fois définis par le navigateur jusqu’à leur expiration.
• Problème rencontré : un certain code JavaScript a provoqué une erreur parce que la bibliothèque standard de Go n’arrivait pas à analyser les cookies.

Spécifications

• RFC 2109, 2965, 6265 : définition initiale et mises à jour des cookies. Les spécifications sur les valeurs de cookie ne correspondent pas entre serveurs et navigateurs.
• Problèmes :
  1. Ce que le serveur doit envoyer et ce que le navigateur doit accepter ne coïncident pas.
  2. Il n’existe aucune restriction sur les valeurs de cookie que le navigateur envoie au serveur.
  3. Il n’existe pas de directive claire sur la manière dont les bibliothèques standard doivent traiter les en-têtes de cookie.

Navigateurs web

• Firefox : accepte certains caractères non recommandés par la RFC.
• Chromium : un peu plus restrictif que Firefox, mais accepte encore de nombreux caractères.
• Safari : lorsqu’il rencontre un caractère non autorisé, il n’interrompt pas le traitement du cookie et accepte la valeur jusqu’à ce caractère.

Bibliothèques standard

• Golang : se comporte de façon similaire à la RFC, mais autorise les espaces et les virgules.
• PHP : produit une erreur avec certains caractères de contrôle.
• Python : ignore les cookies qu’il ne comprend pas et arrête de charger les cookies suivants.
• Ruby : accepte tous les caractères et les encode en pourcentage.
• Rust : accepte toutes les chaînes UTF-8.

Pourquoi c’est important pour le web

• Problème concret : à cause de l’ambiguïté des spécifications, de nombreux sites web peuvent facilement provoquer des erreurs.
• Solution : le groupe de travail HTTP de l’IETF doit mettre à jour les spécifications des cookies et clarifier la façon dont les navigateurs et les langages de programmation doivent les traiter.

Tableau récapitulatif

• Gestion des cookies selon les navigateurs et langages : chaque navigateur et langage traite les cookies différemment, avec des niveaux de conformité variables par rapport aux RFC.

[GN⁺]

Avis Hacker News

• Les cookies comportent des problèmes inattendus et des comportements gênants, tout en fonctionnant dans 99,95 % des cas. Le shadowing de cookies survient lorsqu’on définit des cookies portant le même nom mais avec des attributs de clé différents (domaine, chemin, etc.), et ni le backend ni le JS ne peuvent distinguer de quel cookie il s’agit

• Rust ne dispose pas de fonctionnalité de gestion des cookies dans sa bibliothèque standard et se réfère au comportement de la crate tierce "cookie". Celle-ci inclut une option de percent-encoding, comme en Ruby

• Le protocole HTTP renferme une multitude d’autres protocoles, et les navigateurs comme les serveurs web y ajoutent diverses fonctionnalités. Ces fonctionnalités n’ont pas de spécification claire, et le client comme le serveur ne peuvent pas en définir la compatibilité. On se retrouve donc à devoir perpétuer les mauvaises décisions du passé

• Il y a environ 10 ans, lors de l’implémentation de sessions basées sur des cookies dans un projet, un problème est apparu : cela fonctionnait dans Safari mais pas dans Chrome. La différence venait du fait que les navigateurs ne définissaient pas les cookies si le format n’était pas correct

• Le seul usage raisonnable des cookies est de définir un token opaque pour que le serveur puisse reconnaître le client. Le fait que le client puisse traiter des valeurs que le serveur n’enverrait pas ne pose pas problème

• Les cookies sont un problème complexe, et il est presque impossible de les faire évoluer à cause des enjeux de rétrocompatibilité. Il faudrait créer un nouveau mécanisme. Par exemple, un mécanisme NewCookie pourrait intégrer des mesures de sécurité modernes et une spécification stricte

• Les cookies devraient disparaître et être remplacés par des en-têtes d’authentification. Il serait souhaitable que les navigateurs puissent authentifier un site web de manière standard. C’est dommage que l’authentification Basic et Digest n’aient pas suffi

• Comme le code réseau de Safari n’est pas open source, le port de Foundation en Swift pourrait être une bonne alternative. On peut y vérifier les caractères de contrôle et de suppression

• Le parsing de l’en-tête Cookie est déroutant. Le "standard" ne reflète pas réellement ce qui existe, et chaque serveur backend, bibliothèque ou framework accepte des choses différentes. Ce n’est pas un gros problème si l’on contrôle entièrement le frontend et le backend, mais cela devient très complexe dès qu’il faut interagir avec d’autres systèmes

• Lors d’expérimentations avec le langage Crystal, des problèmes similaires sont apparus. En essayant de construire un simple scraper web, le client HTTP par défaut s’arrêtait parce qu’il ne parvenait pas à parser de nombreux cookies définis dans la réponse