Résumé

  • La RFC 10036 définit le champ HTTP booléen Incremental. La valeur vraie demande aux intermédiaires informés de transmettre le contenu au fil de son arrivée ; celui qui refuse ce mode doit répondre par une erreur, plutôt que d’accepter puis de conserver tout le message en silence.
  • Ce champ n’est ni une négociation de capacité ni un accusé de livraison. Un intermédiaire non informé peut l’ignorer, chaque sens du dialogue exige son propre signal, et un regroupement limité en octets ou en temps reste autorisé. La progression doit donc être mesurée à chaque saut.

Le premier saut ne répond pas pour toute la chaîne

L’exemple du flux sans fin révèle le périmètre exact de la nouvelle règle. Le premier proxy peut choisir un mode de traitement incrémental parce qu’il comprend le champ. Le suivant applique son comportement HTTP habituel. S’il met normalement une réponse en mémoire jusqu’à sa fin, rien dans un champ inconnu ne lui ordonne de faire autrement.

La RFC 10036 ne prévoit pas d’accusé positif envoyé par chaque intermédiaire. Observer le champ à la sortie du serveur démontre une intention locale. Observer les premiers octets à la sortie d’un proxy démontre le comportement de ce seul saut. Même un statut 200 ne prouve pas que le client a reçu le premier élément utile.

La question est différente de celle de la priorité HTTP. Une priorité arbitre entre des octets déjà éligibles lorsque plusieurs travaux se disputent une ressource. Incremental demande si le contenu peut franchir un saut avant l’arrivée du dernier octet. Une route peut donner une priorité forte à une réponse que le proxy suivant conserve encore intégralement ; elle peut aussi transmettre tôt un flux auquel elle réserve peu de capacité.

Une obligation étroite, mais désormais vérifiable

Publiée en août 2026 sur la voie des normes de l’IETF, la RFC 10036 est issue du groupe de travail HTTP. L’IANA a inscrit Incremental de manière permanente dans le registre des champs HTTP, avec le type Item des Structured Fields, et a ajouté incremental_refused aux types d’erreur de Proxy-Status.

La syntaxe utile est volontairement petite. ?1 demande le traitement incrémental. ?0 conserve le comportement par défaut et peut conforter un intermédiaire dans l’idée qu’une mise en mémoire complète convient. Une valeur qui n’est pas booléenne doit être ignorée. Les paramètres inconnus sont eux aussi ignorés : ils ne transforment pas ce signal en protocole de négociation extensible.

Le champ porte sur un message HTTP, pas sur une session entière. Une application qui envoie encore son corps de requête pendant que la réponse commence doit signaler séparément la requête et la réponse. La valeur placée dans un sens ne confère aucune autorité sur le traitement de l’autre sens.

Lorsqu’un intermédiaire conscient accepte la demande, il devrait transmettre la section d’en-tête puis faire progresser le contenu à mesure qu’il arrive. Il peut toutefois attendre une section d’en-tête ou de fin complète. La règle décrit le mode de transfert du contenu ; elle n’abolit pas toutes les limites d’analyse du message.

Refuser clairement vaut mieux qu’attendre sans limite

Certaines fonctions de sécurité doivent voir l’intégralité d’un message avant de décider si elles peuvent le laisser passer. Le champ n’autorise pas l’émetteur à désactiver une telle inspection. Il retire plutôt une ambiguïté : un intermédiaire qui comprend la demande et ne peut jamais la respecter doit le dire, au lieu de feindre l’acceptation puis d’attendre la fin.

Pour une incompatibilité durable liée à la politique d’inspection du contenu, la recommandation est une réponse 501 accompagnée de l’erreur Proxy-Status incremental_refused. Ce couple fournit une preuve classée d’un refus. Il aide à distinguer une impossibilité de politique d’une lenteur du serveur ou d’une perte de transport.

La capacité produit un cas différent. Les flux longs occupent des connexions et de l’état concurrent. Un proxy peut leur imposer une limite particulière afin de préserver les autres services. Lorsque cette limite est atteinte, la RFC recommande 429 avec connection_limit_reached dans Proxy-Status.

Ces diagnostics ne sont pas une vue omnisciente de la route. Un intermédiaire peut supprimer des détails afin de ne pas révéler sa topologie ; un autre peut retirer Proxy-Status ; les champs de fin peuvent disparaître. Une enquête fiable rapproche donc le signal public de l’identité du saut, de sa configuration, de son état de capacité et de sa télémétrie locale.

Incrémental ne signifie pas sans mémoire tampon

Émettre chaque minuscule fragment par une écriture distincte gaspillerait du processeur, du réseau et du travail en aval. La norme autorise un regroupement limité. Une implémentation peut accumuler quelques octets ou attendre un court délai avant d’envoyer.

La frontière opérationnelle n’est donc pas « aucune mémoire ». Elle sépare une fenêtre bornée de l’attente de la fin du message. Un seuil de 16 kilo-octets accompagné d’un minuteur de 20 millisecondes donne une enveloppe testable. « Jusqu’à la fin du corps » n’en donne aucune lorsque le corps peut durer des heures.

Le ?1 n’annonce pas ces seuils. Il ne réserve pas de bande passante, ne contourne ni contrôle de flux ni congestion, et n’exige pas l’émission immédiate d’un paquet. Bibliothèque HTTP, proxy, TLS, noyau et transport peuvent chacun ajouter un délai après la décision applicative.

Un objectif de service utile mesure donc le temps et le volume entre l’arrivée sur une face du saut et la première sortie, puis la cadence continue sur l’autre face. Il précise les tailles, la cadence des événements, la charge simultanée et les cas de panne. Le simple décompte des champs reçus ne mesure pas la livraison.

L’intermédiaire ignorant reste la limite difficile

Un proxy informé doit produire une erreur s’il décide explicitement de ne pas honorer le mode demandé. Un proxy qui ne reconnaît pas le champ n’est pas en mesure d’obéir à cette obligation. Il peut ignorer la valeur et conserver le message comme auparavant.

C’est pourquoi la spécification renvoie à une connaissance préalable ou à des sondes propres à une ressource. Le champ coordonne des implémentations compatibles ; il ne découvre pas universellement les capacités. Une sonde réussie sur une URL, un point de présence, une version HTTP ou une route ne constitue pas une preuve permanente ailleurs.

Les chemins évoluent. Un CDN ajoute un filtre, répartit le trafic entre deux générations de logiciel, déplace un client vers une autre passerelle ou négocie une autre version en amont. Une mesure limitée au trajet origine-edge peut manquer la mémoire tampon edge-client. Une petite réponse qui finit toujours peut masquer la panne propre à un flux interminable.

La preuve de capacité doit donc avoir un chemin et une date. Elle comprend la sélection DNS et réseau, les identités des proxies, les versions HTTP, les révisions de configuration, la conservation du champ, les seuils, les horodatages du premier en-tête et du premier contenu, la cadence suivante et ce que le client a réellement observé.

Les usages longs et bidirectionnels ne cassent pas de la même façon

Server-Sent Events est le cas le plus net côté réponse : la mise en mémoire du message entier devient une attente indéfinie. L’application doit vérifier la sortie des événements à la cadence attendue sur chacune de ses routes de production, pas uniquement l’arrivée des en-têtes.

Chunked Oblivious HTTP motive les deux sens : le client peut continuer à envoyer pendant que le serveur commence à répondre. Chacun des deux messages exige sa valeur. Le rapport de l’IESG indique que ce travail dépend du champ incrémental et constate encore peu d’implémentations actives. C’est un motif pour mesurer, non pour diluer la sémantique.

La RFC rappelle aussi qu’Extended CONNECT correspond généralement mieux à l’architecture HTTP pour les protocoles bidirectionnels. HTTP/2 et HTTP/3 disposent de mécanismes Extended CONNECT pour WebSockets. Employer une requête-réponse ordinaire avec contenu incrémental doit rester un choix de compatibilité explicite ; un nouveau champ ne transforme pas chaque chaîne de proxies en tunnel générique.

Conserver la preuve de l’intention jusqu’au progrès observé

L’émetteur possède l’intention inscrite sur le message. Chaque intermédiaire possède son état de prise en charge, sa politique d’inspection, sa limite de capacité et ses seuils. Le responsable de l’application décide si le comportement mesuré suffit au produit et quel repli demeure sûr.

La chaîne de preuve commence par l’identité et le sens du message, le booléen effectivement analysé, puis le logiciel et la configuration de chaque saut. Elle suit la propagation du champ, le mode local, les limites en octets et en temps, les heures d’entrée et de sortie, les refus et les Proxy-Status dignes de confiance. Elle se termine avec le premier événement vu par le client, la cadence ultérieure, l’état applicatif et le coût en ressources.

Il ne faut pas confondre les étages. Un champ enregistré ne prouve pas sa prise en charge. La prise en charge ne prouve pas son emploi sur cette requête. La sortie d’un saut ne prouve pas la livraison finale. Le premier octet ne prouve pas la continuité sûre du service. La norme rend exprimable un choix auparavant caché ; seules des mesures entretenues montrent où le contenu a réellement progressé.

Sources