Résumé

  • Expect: 100-continue annonce que le client souhaite attendre avant d’envoyer le contenu, afin qu’un rejet fondé sur la méthode, la cible ou les en-têtes puisse arriver tôt.
  • La réponse 100 invite seulement à poursuivre la transmission. Le serveur d’origine doit encore rendre un statut final, et un intermédiaire peut parfois produire lui-même l’invitation.
  • Le client peut cesser d’attendre et envoyer le corps. Cette échappatoire empêche qu’un intermédiaire ancien ou silencieux transforme l’optimisation en interblocage.

Décider avant de transporter

Dans un message HTTP, la ligne de requête et les en-têtes précèdent le contenu éventuel. Cet ordre rend certaines décisions précoces: une méthode interdite, une cible invalide ou des identifiants insuffisants peuvent être reconnus sans recevoir un fichier entier.

Tout envoyer immédiatement gaspille de la capacité si la conclusion est déjà 401 ou 405. Attendre sans convention commune crée l’échec inverse: le client attend une permission, le serveur attend le corps. Le statut 100 s’insère précisément dans cet intervalle.

Le RFC 2068, première spécification HTTP/1.1 sur la voie des normes en 1997, définissait déjà cette réponse informative et un comportement complexe selon la version du pair. Une chaîne HTTP/1.0 pouvait ne jamais transmettre le signal provisoire, d’où des règles de temporisation et de reprise.

Rendre l’attente explicite

Le RFC 2616 ajouta le champ Expect et la valeur 100-continue. Le serveur pouvait désormais distinguer un client qui retenait son contenu d’un autre qui envoyait en continu les en-têtes puis le corps.

Un client qui entend attendre doit déclarer l’attente; il ne doit pas le faire lorsqu’aucun contenu ne suit. Si le serveur a déjà reçu tout ou partie du corps, il peut omettre une réponse 100 devenue inutile.

Devant une requête HTTP/1.1 complète dans ses en-têtes, avec contenu annoncé et attente déclarée, l’origine a deux voies immédiates. Si les en-têtes suffisent à déterminer un statut final, elle l’envoie. Sinon, elle envoie 100 et ne doit pas attendre le corps avant de le faire. La règle retire au serveur la capacité de maintenir silencieusement les deux parties en suspens.

Continuer n’est pas réussir

Une réponse 1xx est informative et ne termine pas l’échange. Après 100, le serveur doit encore recevoir et traiter le contenu puis envoyer un statut final, sauf fermeture prématurée de la connexion.

Le mot « continue » est volontairement étroit. Il ne certifie ni authentification, ni validité du contenu, ni stockage durable, ni exécution de la méthode. Il dit seulement que les informations déjà vues ne justifient pas encore d’interrompre l’envoi.

Le mécanisme n’est donc pas une validation préparatoire ni un protocole de commit en deux phases. Le corps peut échouer à l’analyse, le stockage peut manquer et l’autorisation peut dépendre de données qui ne sont pas encore arrivées.

L’intermédiaire peut encourager sans accepter

Un proxy recevant l’attente peut produire un statut final qu’il connaît, ou transmettre la ligne et les en-têtes à l’origine. S’il sait que le prochain saut est ancien, il peut parfois générer lui-même 100 afin de faire progresser le client.

La provenance devient alors essentielle. Un 100 émis par le proxy prouve que ce saut accepte de transporter le contenu, non que l’origine l’a vu ou accepté. Un journal qui enregistre seulement « 100 reçu » transforme une permission locale en faux témoignage sur le service final.

Le statut 417 indique que l’attente ne peut être satisfaite dans la chaîne. Le client est invité à réessayer sans cette option. Supprimer l’optimisation ne rend toutefois pas sans danger la répétition d’une méthode à effets: il faut encore savoir ce qui a atteint l’origine.

Le silence ne peut imposer une attente infinie

Les RFC 7231 et RFC 9110 maintiennent une asymétrie décisive. Le client n’est tenu par aucun délai fixe et peut envoyer le contenu sans avoir reçu 100. Il ne doit pas attendre indéfiniment.

Un intermédiaire ancien peut avaler les réponses informatives. L’origine peut déjà lire des octets. Sans échappatoire locale, une optimisation de bande passante deviendrait un droit de veto par silence. Le client échange donc parfois quelques octets inutiles contre la garantie de progression.

Les normes ne fixent pas de seuil universel de taille ou de latence. Le bénéfice dépend du volume, de la probabilité de rejet et du trajet. Le contrat porte sur la coordination, pas sur une mesure mondiale de performance.

Un verdict précoce laisse un problème de cadrage

Le statut final peut arriver pendant que le client émet encore. Le serveur doit alors fermer la connexion ou continuer à lire et jeter le contenu restant de façon à préserver le cadrage des messages suivants.

Cette décision est distincte du verdict applicatif. Sur une connexion réutilisée, des octets résiduels mal interprétés peuvent devenir le début apparent d’une autre requête. Il faut donc observer séparément invitation, résultat final et disposition de la connexion.

Sources et limites

Le corpus fermé réunit RFC 2068, RFC 2616, RFC 7231 et RFC 9110. Il établit l’évolution et la sémantique, pas l’adoption actuelle, les délais par défaut, les économies d’octets ou la conformité des intermédiaires.