Résumé

  • HTTP 431 sépare un ensemble de champs trop volumineux d'un contenu trop volumineux, alors que HTTP ne fixe aucun plafond identique pour tous les relais.
  • Le refus peut viser l'ensemble ou un champ précis ; réduire puis renvoyer reste possible, mais supprimer aveuglément un contexte peut changer l'autorisation ou le sens.

L'échec qui précède le contenu

Une opération sans corps, ou avec quelques octets seulement, arrive à une passerelle. Pourtant elle est refusée. Au fil des échanges, la requête a accumulé cookies, justificatifs d'accès, préférences de représentation, traces et informations de transfert. Chaque élément peut sembler raisonnable ; leur somme dépasse le budget d'un récepteur.

RFC 6585 a donné en 2012 un nom précis à cette situation : 431 Request Header Fields Too Large. Le serveur refuse de traiter la requête parce que ses champs sont trop grands. Le client peut la reconstruire avec des champs plus courts et la présenter de nouveau.

Il ne s'agit pas du contenu visé par 413 dans RFC 9110. L'excès se trouve dans l'enveloppe qui porte contexte, conditions et autorité. La requête peut donc être trop grande avant que son corps ne commence.

Une réponse commune, pas une taille commune

RFC 9110 ne définit de limite préalable ni pour une ligne, ni pour une valeur, ni pour la section de champs entière. Les implémentations ont néanmoins une mémoire et un temps de calcul finis. Chacune choisit ce qu'elle veut traiter.

Une même chaîne contient alors plusieurs budgets. La bibliothèque du client accepte la construction, le mandataire local la transmet, une passerelle de bord la refuse, tandis qu'un autre chemin atteindrait une origine dotée d'une limite différente. Aucun nombre universel ne permet de déduire à l'avance le résultat.

431 rend cette décision locale lisible. Il n'indique pas à lui seul quel relais possède la plus petite limite. Il n'ordonne pas davantage de l'augmenter : cette limite peut protéger une ressource réelle.

Un champ fautif n'est pas un total fautif

RFC 6585 prévoit deux diagnostics. La section complète peut être excessive, ou un seul champ peut l'être. Dans le second cas, la représentation devrait nommer le champ concerné.

La réparation diffère. Un champ isolé peut parfois être renouvelé ou réduit. Un excès global peut provenir de dizaines d'ajouts indépendants. Retirer le plus grand ne garantit pas que l'ensemble franchira le prochain relais. Le nom d'un champ est une piste, pas une certification de compatibilité.

La responsabilité peut aussi être distribuée. Un cookie agrège l'état de plusieurs réponses. Un champ de transfert grandit à chaque intermédiaire. Une identité change lors d'une rotation de jeton. Une plateforme de trace ajoute des valeurs sans que l'application appelante les voie.

Tronquer en silence changerait l'autorité

RFC 9110 impose un 4xx approprié plutôt que l'ignorance d'un champ de requête trop grand. Ignorer augmente notamment le risque de désaccord exploitable dans le traitement des requêtes.

Les champs ne sont pas une décoration. Ils peuvent porter une condition d'écriture, une authentification, une destination ou une règle d'interprétation. Si un relais ignore ce qu'un autre applique, les deux n'exécutent plus la même requête. Une coupe apparemment pratique peut rendre une mise à jour inconditionnelle ou retirer le justificatif qui l'autorisait.

Le serveur doit recevoir toute la section avant d'appliquer la méthode : un champ tardif peut modifier les conditions, l'identité ou la lecture de doublons trompeurs. L'option sûre est donc le refus explicite, puis une reconstruction par l'acteur qui connaît la sémantique.

Renvoyer n'est ni garanti ni toujours sûr

La possibilité de renvoi après réduction n'est pas une promesse de succès. Un relais suivant peut avoir une limite moindre. Le champ retiré peut être obligatoire. L'opération peut avoir expiré. Après une incertitude de transport, le client peut ignorer si un essai précédent a produit un effet.

Un bon renvoi repart d'un état de référence, conserve identifiants et conditions nécessaires, emploie un mécanisme d'idempotence lorsque l'application en offre un, et vérifie que l'action a encore un sens. La rapidité ne répare pas une autorité amputée.

Le cache ne doit pas prolonger une limite locale

RFC 6585 interdit de stocker une réponse 431. Le verdict dépend d'une section précise, d'un chemin et d'un budget de réception actuel. Le rejouer pourrait refuser une requête réduite ou transformer la configuration ancienne d'un relais en règle générale.

Un récepteur peut produire un nouveau 431 à partir de son état présent. Un cache ne peut pas conserver cette décision comme s'il s'agissait d'un contenu réutilisable.

Sous attaque, l'explication peut disparaître

RFC 6585 n'oblige pas les serveurs à émettre 431. Sous attaque, fermer la connexion ou agir autrement peut être préférable. Lire assez de données pour expliquer le dépassement consomme justement les ressources protégées, et publier des seuils trop précis peut aider à les sonder.

Lorsque la capacité le permet, un diagnostic borné aide le client légitime. Sous pression hostile, l'arrêt précoce peut primer. Mais une connexion fermée ne prouve pas publiquement que les champs étaient en cause ; les preuves internes doivent garder cette distinction.

La vérité étroite de 431

431 ne signifie ni que le corps est trop grand, ni qu'une taille Internet a été dépassée, ni que le client est malveillant. Il signifie qu'un récepteur a refusé une enveloppe de contrôle qu'il ne voulait pas traiter.

Cette précision transforme une contrainte cachée en branche réparable sans nationaliser le budget. La leçon durable est d'avoir un propriétaire, une limite et un moyen de reconstruction pour chaque contexte ajouté — jamais d'abandonner une condition de sécurité pour faire tenir la requête.

Sources