Strat´egies de n´egociation

Le protocole HTTP/1.1 permet la gestion des diff´erentes versions (ou variantes) du mˆeme contenu sous une unique URI. Le processus de n´egociation du contenu de HTTP/1.1 consiste `a effectuer une s´election de la meilleure variante en fonction des caract´eristiques du client cible. La s´election est bas´ee sur la recherche de correspon-dances entre les propri´et´es des variantes disponibles et les capacit´es de l’application cliente et les pr´ef´erences de l’utilisateur d’autre part. Ce principe est le mˆeme que dans l’ancienne version du protocole ; cependant HTTP/1.1 d´efinit de nouvelles strat´egies et consid`ere la n´egociation du cˆot´e des entit´es de cache.

Comme nous avons d´ej`a vu (voir Section 2.3.2.1), le mod`ele de n´egociation du protocole HTTP/1.0 peut causer des transmissions volumineuses et inutiles concernant l’expression des pr´ef´erences et des capacit´es. HTTP/1.1 propose un mod`ele appel´e n´egociation transparente du contenu [53]. Ce mod`ele ´evite l’envoi des entˆetes de type Accept de grande taille qui sont inutiles dans le cas o`u le serveur ne dispose pas de versions multiples, ou lorsque le client est incapable de traiter les versions disponibles. En utilisant le principe de la n´egociation transparente du contenu, le serveur envoie `a l’application cliente une liste des variantes disponibles avec leurs propri´et´es (voir Figure 2.8). La description d’une variante consiste en un ensemble d’attributs et de valeurs. Chaque attribut peut apparaˆıtre une seule fois dans une description.

Exemple : Une liste de variantes concernant une ressource ’document’ peut ˆetre donn´ee comme suit :

{"document.1" 0.7 {type text/html} {language de}}, {"document.2" 1.0 {type text/html} {language fr}}, {"document.3" 0.8 {type application/pdf} {language en}}

Lorsqu’une liste est re¸cue, l’application cliente peut choisir la meilleure variante et par la suite la r´ecup´erer. Le mod`ele de communication entre l’application cliente et le serveur de contenu est repr´esent´e par la Figure2.8. La premi`ere r´eponse du serveur est donc sous forme d’une liste de versions. La seconde r´eponse est une r´eponse classique qui transporte la ressource s´electionn´ee. Cette seconde r´eponse ne comporte aucune information relative `a la n´egociation du contenu.

Dans ce mod`ele de n´egociation, qui est donc diff´erent du mod`ele HTTP/1.0, la description des capacit´es et des pr´ef´erences est uniquement utilis´ee par l’application cliente elle-mˆeme. Par cons´equent, l’envoi de plusieurs entˆetes Accept est ´evit´e. Notons que l’envoi de quelques entˆetes Accept peut aider `a l’acc´el´eration du processus de

Fig. 2.8 – Mod`ele de la n´egociation transparente du contenu

n´egociation comme nous allons voir par la suite.

Un exemple de r´eponse HTTP/1.1 peut ˆetre donn´e comme suit. Cette r´eponse correspond `a la liste des versions donn´ee plus haut :

HTTP/1.1 300 Multiple Choices Date: Wed, 09 Jul 2003 00:00:01 GMT TCN: list

Alternates: {"document.1" 0.7 {type text/html} {language de}}, {"document.2" 1.0 {type text/html} {language fr}}, {"document.3" 0.9 {type application/pdf} {language en}} Vary: negotiate, accept, accept-language

ETag: "blah;1234" Cache-control: max-age=99900 Content-Type: text/html Content-Length: 175 <h2>Choix multiples :</h2> <ul>

<li><a href=document.1>HTML - Version en Allemand</a> <li><a href=document.2>HTML - Version en Francais</a> <li><a href=document.3>PDF - Version en Anglais</a> </ul>

L’entˆete Alternates dans la r´eponse du serveur comporte la liste des variantes. L’entˆete Vary est utilis´ee pour assurer un traitement correct en cas de l’utilisation d’un cache (voir Section2.3.3.4). L’entˆete ETag permet de revalider la r´eponse par les autres caches, cette revalidation est contrˆol´ee par l’entˆete Cache-Control. La portion HTML incluse dans la r´eponse permet `a l’utilisateur de s´electionner la meilleure variante.

2.3.3.1.1 Optimisation du processus de n´egociation Comme nous avons vu, le mod`ele de n´egociation pr´ec´edent implique deux transactions, pour la r´ecup´eration de la liste des variantes et pour la r´ecup´eration de la ressource s´electionn´ee. Dans la n´egociation du protocole HTTP/1.1, d’autres sc´enarios de communication sont possibles pour optimiser le sc´enario principal pr´esent´e par la Figure 2.8. Ces optimi-sations peuvent r´eduire l’utilisation des ressources r´eseau, telle que la bande passante,

Fig. 2.9 – Premier cas d’optimisation de la n´egociation

Fig. 2.10 – Deuxi`eme cas d’optimisation de la n´egociation

minimiser le temps de r´eponse de la communication client/serveur et r´eduire la charge du serveur d’origine.

Trois cas d’optimisation ont ´et´e identifi´es. Dans le premier cas, les proxy de cache peuvent sauvegarder les variantes et les listes des variantes. Cette sauvegarde peut r´eduire la surcharge de communication comme la montre l’exemple de la Figure2.9.

Dans le deuxi`eme cas d’optimisation, l’application cliente peut envoyer un petit ensemble d’entˆetes de type Accept, suffisant pour que le serveur puisse s´electionner la meilleure variante et la renvoyer directement au client.

Ce type de s´election de variantes, bas´e sur un ensemble r´eduit d’entˆetes Accept, est assur´e `a l’aide de l’utilisation d’un algorithme appel´e algorithme de s´election distante des variantes (voir Figure 2.10). Ce genre d’algorithme prend en entr´ee la liste des variantes et les entˆetes Accept. Il v´erifie ensuite si les informations des entˆetes donn´ees sont suffisantes pour pouvoir effectuer la s´election `a la place de l’application cliente. Si c’est le cas, l’algorithme d´etermine la meilleure variante du contenu. Si la meilleure

variante est une variante voisine 5, elle peut ˆetre retourn´ee `a l’application cliente accompagn´ee de la liste des variantes dans une r´eponse de choix.

Dans le cas o`u l’application cliente supporte la n´egociation transparente du contenu, l’application de la s´election cˆot´e serveur ne pourra se faire que si le client autorise explicitement (dans sa requˆete de n´egociation) l’utilisation d’un algorithme de s´election distante. Les applications clientes capables d’appliquer des algorithmes avanc´es de s´election de variantes peuvent interdire une s´election distante. Elles peuvent aussi l’autoriser pour des types particuliers de ressources, ou quand l’algorithme local est limit´e [52].

L’exemple suivant donne une r´eponse du serveur qui peut correspondre au sc´enario de la Figure2.10 :

HTTP/1.1 200 OK

Date: Wed, 09 Jul 2003 00:00:01 GMT TCN: choice

Content-Type: text/html

Last-Modified: Tue, 08 Jul 2003 09:07:07 GMT Content-Length: 6623

Cache-control: max-age=99900 Content-Location: document.2

Alternates: {"document.1" 0.7 {type text/html} {language de}}, {"document.2" 1.0 {type text/html} {language fr}}, {"document.3" 0.9 {type application/pdf} {language en}} Etag: "cloooo;1234"

Vary: negotiate, accept, accept-language <title> Document 1 ...

Le dernier cas d’optimisation consiste `a combiner les deux situations pr´ec´edentes. Si un proxy de cache poss`ede la liste des variantes, il peut dans certains cas effectuer la s´election `a la place de l’application cliente. Ce sc´enario est repr´esent´e par la Figure2.11.

2.3.3.1.2 L’entˆete Negotiate L’entˆete Negotiate peut comporter des directives pour un processus de n´egociation quelconque initi´e par la requˆete. Les directives de n´egociation peuvent avoir l’une des valeurs suivante : trans, vlist, guess-small, rvsa-version, ’*’ ou negotiate-extension. Exemples :

Negotiate: 1.0, 2.5 Negotiate: *

La s´emantique des diff´erentes directives est la suivante :

– ’trans’ : l’application cliente supporte la n´egociation transparente du contenu pour la requˆete courante.

5Une variante est dite voisine d’une autre ressource si la variante poss`ede une URL HTTP telle que l’URL absolue de la variante d´elimit´ee par son dernier ’/’ soit ´egale `a l’URL absolue de la ressource d´elimit´ee par son dernier ’/’ [35]

Fig. 2.11 – Troisi`eme cas d’optimisation de la n´egociation

– ’vlist’ : l’application cliente demande que les r´eponses des ressources n´egociables pour la requˆete courante incluent une entˆete Alternates avec la liste des variantes.

– ’guess-small’ : l’application cliente autorise les serveurs d’origine `a appliquer un algorithme de calcul de la meilleure variante pour la requˆete, et `a retourner cette variante sous forme d’une r´eponse de choix.

– ’rvsa-version’ : l’application cliente autorise les serveurs (et les diff´erents proxy) `a appliquer un algorithme de s´election distante de variantes qui respecte les num´eros de versions donn´es.

– ’* ’ : l’application cliente autorise les serveurs et les proxy `a appliquer n’importe quel algorithme de s´election distante de variantes.

Dans le cas o`u une directive de n´egociation est incompr´ehensible par le serveur, la directive est ignor´ee. Si l’application cliente autorise l’utilisation de plusieurs algo-rithmes de s´election, le serveur doit utiliser des heuristiques internes pour s´electionner l’algorithme le plus efficace.

2.3.3.1.3 L’entˆete TCN L’entˆete TCN (N´egociation Transparente de Contenu) est utilis´ee par le serveur pour signaler qu’une ressource a ´et´e n´egoci´ee en appliquant la strat´egie de n´egociation transparente du contenu du protocole HTTP/1.1. Dans le cas o`u la ressource n’est pas n´egoci´ee, l’entˆete TCN n’est incluse dans aucune r´eponse. L’entˆete TCN comprend trois champs : un champ type de r´eponse, un champ de di-rectives et un champ d’extension. Le champ de directive est repr´esent´e par l’attribut server-side-override-directive qui peut prendre les valeurs ’re-choose’ (re-choisir) ou ’keep’ (garder). Si la directive est ’re-choose’, le serveur inclut une entˆete Alternate avec la liste des variantes de la ressource originale. L’application cliente doit donc uti-liser son propre algorithme pour la s´election et la r´ecup´eration de la meilleure variante de la liste. Si la directive de n´egociation est ’keep’, le client ne n´egocie pas la r´eponse, il l’utilise directement.