Résumé

  • En ICAP, 204 No Content signifie que le service ne renvoie pas de message adapté et que le client peut réutiliser l’original selon un contrat de tampon précis ; ce n’est pas un certificat de sûreté.
  • La décision doit rester liée aux en-têtes et octets effectivement vus, à l’état du service identifié par ISTag, à la reconstruction de l’original et au résultat HTTP puis applicatif.

Le service a répondu 204. Dans le protocole, cette réponse économisait le renvoi d’un objet identique. Dans le rapport, elle est devenue la preuve que l’objet était « propre ».

La première proposition décrit une optimisation de flux. La seconde attribue au service une conclusion que le statut ne porte pas. Il peut ne pas vouloir modifier le message ou ne pas pouvoir le modifier. Et, lors d’une Preview, il peut n’en avoir vu qu’une partie.

Le RFC 3507 a été publié en avril 2003 comme document informatif. Il décrit ICAP, protocole autonome sur TCP, inspiré de la forme HTTP mais ni HTTP ni transporté sur HTTP. Son objet est l’adaptation de requêtes et réponses encapsulées. Son statut et la mention d’un usage déjà répandu à l’époque ne mesurent aucun déploiement actuel.

Le 204 repose sur la mémoire du client

Pendant une Preview, le client transmet tous les en-têtes encapsulés et un début du corps. Il conserve cette portion pour pouvoir reprendre l’original si le service renvoie 204. Le service n’a pas besoin de lui retourner les mêmes octets.

Hors Preview, le client peut annoncer Allow: 204. Il accepte alors la charge nécessaire pour reconstruire le message complet. Sans cette permission, le service doit renvoyer le message identique au lieu d’un simple statut, même s’il n’y apporte aucun changement.

Le code exprime donc qui possède encore les octets et qui paie le tampon. Un client qui a déjà libéré ou transmis les données ne peut pas honorer la même économie sans autre source.

Le reçu utile contient la quantité gardée, la durée, la stratégie de reprise et l’empreinte du message reconstruit. « 204 reçu » ne démontre pas que l’original a été reproduit correctement.

La Preview ne voit pas le corps entier par convention

Un service peut indiquer dans OPTIONS la taille de Preview qu’il souhaite pour une ressource. Le client envoie les sections d’en-tête et jusqu’à cette quantité de corps, termine provisoirement le flux de chunks et attend.

Le RFC recommande que les clients puissent fournir au moins 4096 octets et ne dépassent pas la quantité demandée par le service. Ce chiffre n’est pas une frontière universelle entre contenu bénin et contenu décisif.

Si le service renvoie 204 sur cette base, la preuve couvre la configuration, les en-têtes et les octets réellement observés. Une séquence située plus loin dans le corps n’a pas été jugée. La conclusion peut être conforme au protocole et insuffisante pour la politique déclarée.

Il faut donc enregistrer la longueur demandée, la longueur reçue, la position du premier octet non vu et la raison pour laquelle un verdict partiel était acceptable.

100 Continue ne termine rien

Lorsque d’autres octets restent à envoyer, le service peut répondre 100 Continue. Le client transmet alors la suite de son message ICAP à partir du premier chunk après la Preview.

Cette réponse est une invitation à compléter l’entrée de l’adaptateur. Elle n’est pas son verdict final. Elle ne signifie pas davantage que le serveur d’origine acceptera la requête HTTP, que le destinataire recevra la réponse ou que l’application exécutera l’opération.

Le même numéro rappelle HTTP, mais le point d’arrêt ICAP peut se trouver au milieu du corps encapsulé. La provenance du 100 doit donc être explicite : service ICAP, ressource, connexion et étape.

Confondre les deux couches produit une chronologie impossible, dans laquelle une permission de transmettre à un intermédiaire devient une acceptation par l’origine.

ieof prouve que la source s’est arrêtée dans la Preview

Le client ICAP peut relayer une réponse dont il ne connaît pas encore la longueur. Si la source termine pendant la Preview, l’extension de chunk ieof marque cette fin.

Le service sait alors qu’aucun reste ne peut être demandé. Il ne doit pas renvoyer 100 Continue; il répond par une version adaptée ou 204. Avant de livrer les données à son application d’adaptation, il retire l’extension de cadrage.

La capture doit conserver ce marqueur. Sans lui, le buffer applicatif ne montre pas pourquoi le service pensait avoir reçu l’objet entier. À l’inverse, l’absence de ieof ne garantit pas que des octets supplémentaires arriveront : la source peut échouer ensuite.

La fin de la Preview, la fin du corps d’origine et la fin de la décision d’adaptation sont trois événements.

REQMOD et RESPMOD changent la provenance

En mode REQMOD, le service peut renvoyer une requête HTTP modifiée, une réponse HTTP d’erreur, 204 lorsque le client le permet, ou une erreur ICAP. Une réponse HTTP produite ici ne vient pas nécessairement de l’origine.

En mode RESPMOD, le service reçoit une réponse côté origine et peut en produire une autre pour le consommateur. L’objet résultant porte une histoire de transformation. Il ne suffit pas de conserver l’URL et le statut final.

Chaque étape doit garder les empreintes avant/après, la méthode, la règle, le service et le prochain destinataire. Une nouvelle adaptation en chaîne crée une autre branche de provenance.

Le résultat visible par l’utilisateur reste ultérieur. Un client peut refuser, tronquer ou ne jamais afficher la représentation adaptée.

ISTag est une époque de service, pas une attestation

Chaque réponse ICAP doit inclure un ISTag. Le service peut faire évoluer ce jeton lorsque son logiciel, sa configuration ou sa base change et que des résultats cachés doivent être invalidés.

Sa portée diffère d’un ETag HTTP : elle concerne l’état d’un service URI à travers plusieurs objets produits. Cette portée rend le déploiement du tag aussi important que sa syntaxe.

Le jeton ne prouve pas quelles règles il résume, ni que tous les nœuds d’un cluster ont basculé. Il n’est pas une signature cryptographique et ne valide pas rétroactivement les décisions précédentes.

Pour être exploitable, il doit être relié à un manifeste de configuration, un ensemble de nœuds, une heure d’activation et une opération d’invalidation vérifiée. Sinon, il s’agit d’un nom sans contenu gouverné.

Trois horloges peuvent diverger

OPTIONS peut annoncer les méthodes, Preview, Allow, politiques de transfert, durée de validité, capacité et ISTag. Cette réponse possède sa propre fraîcheur.

Le résultat adapté mis en cache possède une autre expiration. En RESPMOD, il ne doit pas rester frais plus longtemps que l’objet d’origine, bien qu’il puisse expirer plus tôt. Le ISTag forme une troisième horloge liée à l’état du service.

Un client peut donc posséder une OPTIONS expirée, un résultat encore frais selon HTTP et un tag désormais ancien. Le cache n’est défendable que si la décision nomme les trois coordonnées.

Servir une ancienne entrée après apparition du nouveau tag montre que le signal de contrôle n’a pas atteint le plan de données.

Les offsets rendent le conteneur lisible

Le champ Encapsulated indique les offsets des en-têtes et corps de requête ou de réponse, du corps OPTIONS ou d’un corps nul. Il permet de séparer les sections dans le message composé.

Ces positions ne certifient pas la sémantique HTTP. Le cadrage par chunks, le terminus de Preview, ieof, le statut ICAP et le statut HTTP encapsulé restent des preuves différentes.

Il faut préserver le message composé, pas seulement une réécriture de l’objet HTTP. Une normalisation ultérieure peut effacer exactement la limite qui expliquait ce que le service avait vu.

L’autorité d’adaptation vient d’une politique extérieure

Le RFC 3238 a soulevé des questions de consentement, notification, vie privée, résolution d’URI, validité des références et fonctionnement non bloquant. L’architecture OPES ultérieure décrit règles, dispatchers, domaines de confiance et traçage.

Ces textes donnent un contexte à la délégation. Ils ne transforment pas 204 en preuve que toutes les parties ont consenti ou que la transformation respecte l’intégrité de bout en bout.

Le dispatcher doit pouvoir montrer quelle règle a appelé quel service, au nom de quelle autorité et avec quelle trace. Le statut de transport de l’adaptation ne remplace pas ce mandat.

La chaîne qui empêche « sans modification » de devenir « sans risque »

Conservez le message HTTP d’origine, son rôle et son point d’observation. Identifiez URI et méthode ICAP, pairs, OPTIONS, expiration et état ISTag. Validez les offsets.

Enregistrez Preview demandée et reçue, ieof, lecture d’origine et tampon. Conservez le statut, la suite après 100 et les octets réellement observés.

Pour une transformation, gardez avant/après et la trace. Pour un cache, gardez clé, dates et comparaison de tag. Pour 204, prouvez la reconstruction exacte.

Suivez enfin le prochain échange HTTP, la provenance de l’origine, la livraison, l’autorisation et le résultat applicatif authentifié.

Limite de preuve

Cet article ne vise aucun produit, proxy, scanner, déploiement ou incident actuel. Il ne dit pas que Preview ou 204 sont de mauvaises idées. Il refuse seulement de leur prêter un jugement plus large que leur entrée.

Il ne répète pas l’article historique consacré à HTTP 100 Continue, dont l’objet est l’autorisation d’envoyer le corps au niveau HTTP. Ici, la question est la délégation d’adaptation, la reconstruction du message et l’époque d’un service.

Les principes de spécification initiale minimale et de code en fonctionnement de Heng Lu sont des angles éditoriaux déclarés. Ils favorisent des invariants communs minces et des mesures du chemin exécuté, pas une règle de déploiement.

La conclusion tient dans le vocabulaire : 204 signifie « aucune adaptation renvoyée ». Si l’organisation veut dire « aucun risque détecté dans tout le contenu », elle doit produire une autre preuve.

Sources