Echange de protocoles

Dans plusieurs implémentations de Web Content Integrator, les flux d'entrée de contenu sont produits par une application qui les génère dynamiquement en réponse aux demandes de l'application client. ans ces situations, il est utile pour le consommateur de pouvoir indiquer à l'application de producteur les versions d'un flux qu'il a déjà vues de sorte que le producteur puisse prendre des décisions appropriées sur le contenu à inclure dans le prochain flux.

L'échange de protocoles consiste à échanger deux attributs de flux : un attribut Last Modified et un attribut arbitraire Entity Tag. Les valeurs de ces deux attributs sont gérées exclusivement par le fournisseur. Le consommateur reçoit les valeurs en provenance du producteur, les stocke puis les renvoie en l'état avec la demande suivante. Ces attributs peuvent être communiqués de deux manières :

En tant que zones d'en-tête HTTP :
- Les requêtes du consommateur contiennent alors :
```
If-Modified-Since : {last-modified_value}
If-None-Match: {etag_value}
```
- Les réponses du fournisseur contiennent :
```
ETag: {etag_value}
Last-Modified: {last-modified_value}
```
En tant qu'éléments contenus dans le flux et les paramètres de la chaîne de requête :
- Les requêtes du consommateur ont la forme suivante :
```
http://cmsserver.example.org/ProducerApp?etag={etag_value}&lastMod={last-modified_value}
```
- Les flux renvoyés par le fournisseur contiennent les éléments de niveau canal (channel) suivants :
```
<lastBuildDate>{last-modified_value}</lastBuildDate>
<ibmfs:etag>{etag_value}</ibmfs:etag>
```

Fonctionnement de l'échange de protocoles

Le consommateur adresse sa première requête au fournisseur. Cette requête ne contient aucune zone d'en-tête particulière.
Le fournisseur reçoit la requête et, comme elle ne contient aucun en-tête spécial, il y répond par un flux qui contient des objets représentant toutes les transactions intervenues jusqu'ici. Avant d'envoyer cette réponse, le fournisseur insère l'heure courante dans l'en-tête Last-Modified et affecte à l'en-tête ETag une valeur qui lui permet d'identifier cette instance du flux.
```
Last-Modified: Thu, 7 Sep 2006 12:00:00 GMT
ETag: ABC0011
```
Le consommateur reçoit la réponse, traite le flux et stocke les valeurs des en-têtes Last-Modified et ETag uniquement si le flux a été correctement traité.
Quand le consommateur redevient actif, il demande à nouveau le flux de transaction au fournisseur. Cette fois, il affecte à l'en-tête If-Modified-Since la valeur de l'en-tête Last-Modified qu'il a reçu avec la dernière requête et affecte à la zone If-None-Match la valeur de l'en-tête ETag également reçu avec la dernière requête.
```
If-Modified-Since: Thu, 7 Sep 2006 12:00:00 GMT
If-None-Match: ABC0011
```
Le fournisseur réceptionne la requête et contrôle les valeurs des zones d'en-tête. Il applique ensuite sa propre logique interne pour générer un nouveau flux ne contenant que les modifications intervenues depuis le dernier flux envoyé à ce consommateur. Il renvoie alors un flux avec les valeurs d'en-tête suivantes :
```
Last-Modified: Thu, 7 Sep 2006 13:00:00 GMT
ETag: ABC0032
```
Le consommateur reçoit la réponse, traite le flux et met à jour les valeurs qu'il avait stockées pour les en-têtes Last-Modified et ETag.

Idéalement, si aucune modification n'est intervenue depuis que le consommateur a demandé le flux pour la dernière fois, le fournisseur doit lui répondre par un simple code de réponse HTTP 304 - Not Modified (pas de modification). Ceci signale au consommateur que rien n'a changé et qu'il n'y a donc pas lieu d'analyser le flux ni d'exécuter d'autres traitements. Toutefois, si le fournisseur est dans l'impossibilité d'implémenter cette fonctionnalité, cela n'affectera pas les autres traitements.

Le consommateur enverra une requête contenant le libellé Etag du dernier flux de transaction correctement reçu. Dans ce cas, l'application du fournisseur devra renvoyer toutes les entrées ayant pu se perdre à l'occasion d'un incident de communication entre les serveurs.