Summary

  • RFC 6265 décrit le circuit : le serveur envoie Set-Cookie; le navigateur renvoie les paires applicables dans Cookie lors des requêtes suivantes. La norme demande aux serveurs de limiter leur nombre et leur taille.
  • RFC 6585 a introduit en avril 2012 le code 431 pour un ensemble de champs d'en-tête trop gros, ou pour un seul champ excessif. Une réponse 431 ne doit pas être conservée en cache.
  • Les spécifications HTTP/2 et HTTP/3 permettent toujours au serveur de refuser des champs qu'il ne veut pas traiter. La compression du transport ne supprime pas ce choix.

Le colis revient à l'expéditeur

Un client revient sur un site marchand. Le navigateur demande la page d'accueil et ajoute un champ Cookie. Ce champ contient les valeurs que le site a fait conserver lors des visites précédentes : une session, une préférence, des choix d'expérience. À l'entrée, un serveur ou une passerelle applique sa limite de taille. La requête la dépasse. Le client reçoit 431, ou parfois simplement une connexion interrompue. Le site a expédié le contenu du colis et refuse maintenant de le réceptionner.

La mécanique est inscrite dans RFC 6265, publié en avril 2011. Le serveur peut déposer une paire nom-valeur par Set-Cookie. Le navigateur vérifie ensuite le domaine, le chemin et les autres conditions avant de renvoyer la paire par Cookie. Les attributs de portée et de durée ne reviennent pas dans ce champ; le nom et la valeur y reviennent. Une décision prise au moment d'une réponse devient ainsi une charge répétée dans les requêtes suivantes.

Les chiffres de la norme rendent le piège plus visible. Elle demande aux navigateurs généralistes de pouvoir garder au moins 4 096 octets par cookie et au moins 50 cookies par domaine. Elle demande dans le même passage aux serveurs d'en créer peu et de les garder petits, car le champ Cookie accompagne chaque requête. Les 4 096 octets décrivent une capacité minimale de stockage du navigateur. Ils ne définissent aucune limite commune que toutes les passerelles accepteront pour l'en-tête complet. La mémoire accordée d'un côté peut dépasser le budget de lecture fixé de l'autre.

Un numéro pour une porte bloquée

En avril 2012, RFC 6585 a ajouté quatre codes d'état à HTTP. Le 431, « Request Header Fields Too Large », dit que le destinataire refuse de traiter des champs d'en-tête trop volumineux. L'excès peut venir du total ou d'un seul champ. Dans le second cas, la réponse devrait préciser lequel. Le document autorise une nouvelle tentative après réduction des champs. Il interdit aussi de garder une réponse 431 dans un cache.

Cette dernière règle évite qu'un refus lié à une requête précise soit recyclé pour d'autres requêtes. Elle ne réduit pas le prochain Cookie. Si le navigateur renvoie les mêmes valeurs, le même barrage se présente. Le code d'état ne fixe pas un plafond universel en octets et ne choisit pas le cookie à supprimer. RFC 6585 précise même que, pendant une attaque, le serveur peut préférer couper la connexion à la production d'un 431. Un écran blanc ne révèle donc ni le seuil ni l'élément qui a rejeté le message.

Supprimer tous les cookies peut faire disparaître l'encombrement; cela peut aussi effacer la session et les préférences dont le client a besoin. Ce geste transfère la réparation à celui qui n'a pas dessiné les règles de stockage. L'exploitant, lui, connaît la taille de ses valeurs, les durées qu'il a choisies, les composants à l'entrée et l'endroit où il pourrait aménager une route de secours qui accepte une petite requête.

Le protocole change, le plafond reste

On pourrait croire que les versions plus récentes d'HTTP ont réglé le problème en comprimant les en-têtes. Les textes de 2022 gardent pourtant le droit de refuser. RFC 9113 indique qu'un serveur HTTP/2 peut répondre 431 lorsqu'un bloc de champs est plus grand que ce qu'il veut traiter. RFC 9114 prévoit la même réponse pour une section d'en-tête HTTP/3. La représentation transportée et la taille des champs que le destinataire doit interpréter répondent à deux comptes différents.

Dans une enquête opérationnelle, cette différence compte. Une équipe peut voir un transfert comprimé modeste; une autre mesure l'ensemble décodé qui dépasse la limite d'une passerelle. Le 431 couvre également un unique champ énorme et l'addition de nombreux champs ordinaires. Cookie est un suspect naturel parce que le site en commande le contenu, mais un champ d'autorisation ou un autre en-tête peut aussi remplir l'enveloppe. Les RFC ne donnent aucun décompte d'incidents réels attribués aux cookies. Pour un cas précis, il faut saisir la requête et identifier le premier composant qui la rejette.

Le sujet véritable est la possibilité d'entrer pour réparer. Si la page d'aide exige exactement la même requête surchargée, elle reste derrière la porte fermée. La norme de 2011 avait déjà demandé à l'émetteur de ménager les cookies; celle de 2012 a offert au récepteur un refus lisible. Entre les deux, quelqu'un doit réduire l'état accumulé et accorder les limites des composants. Le numéro 431 nomme le désaccord. Il ne convoque pas les équipes pour le résoudre.