Résumé

  • Incremental: ?1 exprime, pour un message HTTP précis, la demande de transmettre son contenu avant de l’avoir reçu en entier. La requête et la réponse sont deux messages : chacune doit porter le champ si les deux sens comptent.
  • Un intermédiaire qui comprend le champ et refuse catégoriquement cette transmission doit produire une erreur au lieu de mettre silencieusement tout le corps en tampon. La RFC distingue l’incompatibilité durable d’inspection (501 et incremental_refused) de la saturation temporaire (429 et connection_limit_reached).
  • Le signal n’est pas une garantie de bout en bout. Un relais ignorant peut le négliger, et un relais compatible peut conserver un tampon borné. La preuve utile relie donc intention, sens, chemin, politique, seuils, erreur et latence réellement observée.

Prenons une console qui affiche les résultats d’une opération longue. Le serveur commence à produire des données, mais l’écran reste vide pendant deux minutes avant de tout recevoir d’un coup. Aucun paquet n’est nécessairement perdu. Un proxy a pu décider qu’il était plus efficace, ou plus sûr, d’attendre le message complet.

Pour une simple page, l’effet ressemble à de la lenteur. Pour un échange bidirectionnel, il peut bloquer le mécanisme lui-même : le client continue son envoi en attendant une réponse précoce, le serveur répond avant la fin de la requête, et un relais qui retient l’un des deux messages empêche l’autre côté d’avancer.

La RFC 10036, publiée en août 2026 comme norme proposée de l’IETF, traite cette propriété de temps sans la confondre avec la livraison HTTP ordinaire. Elle est signée collectivement par Kazuho Oku, Tommy Pauly et Martin Thomson. La fiche IETF d’Oku conservée le 31 août 2026 recense quatre RFC ; Fastly le présente comme Principal OSS Engineer et auteur de H2O, quicly et picoTLS. Ces éléments situent sa contribution dans le logiciel Internet à haute performance. Ils ne lui attribuent ni l’invention solitaire du champ ni l’autorité sur les réseaux qui le déploient.

Un booléen, deux directions

Le champ Incremental est un Item de Structured Fields. Seule une valeur booléenne est valide ; une autre forme doit être ignorée. ?1 demande au relais de commencer à transmettre avant la réception complète. ?0 laisse le comportement HTTP habituel, où la totalité du message peut être mise en tampon, et rend même ce choix plus explicite.

Cette grammaire minuscule empêche une grande imprécision. Le champ s’applique au message, pas à la connexion ni à la marque d’un produit. Une requête porte sa propre intention ; la réponse doit porter la sienne. Une démonstration qui n’observe que la réponse ne prouve rien sur l’envoi progressif de la requête.

Lorsqu’il comprend ?1, l’intermédiaire ne devrait pas retenir tout le corps. Il devrait transmettre la section d’en-têtes puis relayer continuellement les octets de contenu. Il reste libre de recevoir entièrement les en-têtes et les trailers, car le signal vise le contenu. Même avec le champ dans les deux sens, la RFC rappelle qu’Extended CONNECT correspond généralement mieux à l’architecture HTTP pour un protocole véritablement bidirectionnel.

Le choix technique reste donc ouvert. Le champ rend une intention transportable ; il ne transforme pas une chaîne de proxies en canal garanti.

Le refus devient une branche exploitable

La nouveauté opérationnelle tient dans l’interdiction du faux succès. Si un intermédiaire compatible décide franchement de ne pas relayer le corps progressivement, il doit répondre par une erreur. Il ne peut pas satisfaire la forme finale de la transaction tout en détruisant silencieusement sa propriété temporelle.

Une application peut agir sur une erreur : basculer vers un autre chemin, réduire la fonction, choisir un autre protocole, différer l’opération ou expliquer l’indisponibilité. Elle ne peut pas agir proprement sur un flux qui semble ouvert alors que ses octets attendent derrière un tampon inconnu.

Cette règle ne signifie pas que tout retard est un refus. Elle ne commande pas non plus l’émission immédiate de chaque fragment. Elle rend lisible une décision précise d’un relais participant. La nuance est fondamentale pour l’observabilité : une erreur identifie une politique exercée ; le silence conserve plusieurs hypothèses.

La primauté du code en fonctionnement fournit le critère. Il faut envoyer des fragments reconnaissables à travers le chemin réel, mesurer leur entrée et leur sortie, provoquer les conditions de refus et vérifier que l’erreur et son contexte atteignent bien l’extrémité. La présence du champ dans un exemple de configuration ne suffit pas.

Une contrainte durable, une pression passagère

La première forme de refus vient de l’inspection. Certains relais doivent voir le corps entier pour décider s’il est sûr. Cette fonction et la transmission progressive sont incompatibles. La RFC recommande alors 501 Not Implemented avec l’erreur Proxy-Status incremental_refused.

La répétition immédiate a peu de chances de réussir. Il faut modifier le chemin, la politique d’inspection, l’emplacement de la fonction ou la forme protocolaire. C’est une incompatibilité structurelle tant qu’une décision d’architecture ne change pas.

La seconde forme vient de la capacité. Un échange progressif peut occuper longtemps une ressource. Un relais peut donc lui réserver un pool de concurrence plus strict afin de protéger les requêtes ordinaires. Quand ce pool est plein, la RFC recommande 429 Too Many Requests accompagné de connection_limit_reached dans Proxy-Status.

Ici, la ressource peut être compatible et seulement indisponible à cet instant. Admission, priorité, temporisation, capacité ou solution de repli deviennent les leviers pertinents. Réunir les deux cas sous « le streaming est cassé » ferait perdre l’information décisionnelle.

Le code d’état n’est pas suffisant. Un 501 ou un 429 peut avoir d’autres causes. Il faut le membre Proxy-Status, l’identité du relais, la ressource, l’heure et la version de politique. Et même cette chaîne ne décrit pas les équipements qui ne participent pas au mécanisme.

Le relais ignorant demeure invisible

Un intermédiaire qui ne connaît pas Incremental ne change pas son comportement. Un relais qui connaît le nom sans le prendre en charge peut également mettre en tampon. L’émetteur ne peut donc pas déduire une prise en charge universelle de l’absence d’erreur.

C’est le paradoxe utile de la RFC : le relais compatible qui refuse est plus visible que le relais ignorant qui laisse finalement passer la transaction. Un en-tête observé au départ et une réponse reçue à l’arrivée ne localisent pas l’attente.

Une connaissance préalable testée peut réduire cette zone aveugle sur un chemin maîtrisé. Sinon, la RFC invite à sonder les ressources individuellement. L’unité pertinente est bien la ressource, car un même domaine peut varier selon le chemin, la région, le type de corps, la classe de client ou la charge. Un test réussi constitue une preuve datée de ses conditions, pas un label perpétuel pour un fournisseur.

La frontière d’agence est nette : l’émetteur exprime une intention ; chaque intermédiaire garde la maîtrise de sa sécurité, de sa capacité et de son transfert ; le client ou le serveur décide quoi faire du résultat. Un champ ne peut agir au nom d’un logiciel qui ne le comprend pas.

Un petit tampon peut manquer l’objectif

Même un relais compatible peut conserver un volume limité pour gagner en efficacité et éviter l’abus de nombreux fragments minuscules. Il peut utiliser un seuil en octets ou une durée maximale. Il doit transmettre quand l’un des deux seuils est atteint et ne peut retenir les données indéfiniment.

Cette marge explique pourquoi « compatible » ne veut pas dire « conforme à notre budget de latence ». Un seuil bénin pour une réponse abondante peut retarder fortement un flux d’événements rare. Un minuteur acceptable pour une interface humaine peut casser une boucle de contrôle.

Il faut donc versionner les seuils et les rapprocher des mesures de premier octet. Une modification de politique peut changer l’expérience sans modifier le logiciel ni le champ. Le minimum commun appartient au standard ; les budgets, exceptions, capacités et remèdes appartiennent au déploiement local.

Construire la quittance du chemin

La quittance commence par le client, le serveur, la ressource, la version et le sens du message. Elle conserve la valeur exacte du champ, sa validité booléenne et le composant qui l’a posée. Pour chaque relais contrôlé ou participant, elle note le protocole, la reconnaissance du champ, la règle d’inspection, la politique de transfert, les seuils d’octets et de temps, le pool de concurrence et son occupation.

Elle joint ensuite le résultat : état HTTP, membre Proxy-Status, type d’erreur, relais responsable, heure du premier et du dernier octet reçu puis transmis, budget applicatif et nature de l’issue. Acceptation progressive, tampon borné, refus structurel, refus temporaire, tampon silencieux probable et résultat indéterminé sont des catégories différentes.

Enfin viennent la décision et son propriétaire : nouvelle route, autre protocole, reprise, capacité, exception de sécurité, repli produit ou investigation. Nul besoin de conserver les corps sensibles. Des identifiants corrélables, des versions de politique et des horodatages suffisent souvent à reconstruire la chaîne.

Une bonne preuve conserve aussi ses lacunes. Si un relais reste inconnu ou si Proxy-Status a disparu, il faut le dire. L’incertitude explicitée protège mieux qu’une certification inventée.

Sources