FR2858152A1 - Gestion automatique de champ d'en-tete dans une reponse - Google Patents

Abstract

Un système gère automatiquement des champs dans un en-tête d'une réponse (REP) incluant le contenu d'une ressource identifiée par une adresse (URI) et mémorisée dans un serveur d'origine (SO) en réponse à un message de requête (REQ) transmis par un terminal d'usager (T) à travers un réseau de télécommunications (RP). Un module d'interception (MI) intercepte la requête. Une base de données de requêtes (BREQ) mémorise au moins l'adresse (URI) incluse dans la requête interceptée. Le module d'interception intercepte la réponse du serveur d'origine. Un serveur d'analyse (SA) modifie un champ de l'en-tête de la réponse interceptée selon au moins l'une des règles de gestion prédéterminées en correspondance avec l'adresse mémorisée incluse dans la requête interceptée afin de produire une réponse modifiée (REPM) transmise au terminal à travers le module d'interception.

Description

Gestion automatique de champ d'en-tête dans une réponse

La présente invention concerne un procédé pour 5 gérer automatiquement des champs dans un en-tête d'un message, particulièrement une réponse incluant le contenu d'une ressource mémorisée dans un serveur d'origine en réponse à une requête transmise par un terminal d'usager à travers un réseau de 10 télécommunications.

Une plate-forme d'un hébergeur héberge généralement des sites web, dits également serveurs de contenu pour le compte de fournisseurs de contenu 15 afin de délivrer les contenus de ressource gérées par les fournisseurs à des terminaux d'usager.

Actuellement les hébergeurs de site web gèrent souvent manuellement les informations incluses dans les champs des en-têtes des réponses qui sont 20 transmises à travers un réseau de télécommunications et qui reposent sur le protocole de transfert HTTP (HyperText Transfer Protocol). Les informations dans les champs d'en-tête participent à l'optimisation de l'utilisation et du transfert des contenus de 25 ressource dans le réseau de télécommunications et dans les terminaux d'usager. Par exemple, des champs d'en-têtes renseignent des proxys dans le réseau pour mettre en cache des contenus de ressource.

Trois solutions sont proposées pour qu'un 30 fournisseur paramètre des informations dans les champs d'en-tête de réponse.

Une première solution est de gérer les champs des en-têtes de message HTTP par l'intermédiaire de la configuration de proxy inverse (reverse proxy) ou 35 de logiciel de serveur web. Le fournisseur de contenu transmet des directives sur le paramétrage des champs d'en-tête à l'hébergeur. Le nombre de fournisseurs de contenu client pour un hébergeur est tel que cette première solution devient rapidement coûteuse et de mise en pratique difficile.

Dans une deuxième solution, les champs des entêtes sont gérés directement par le fournisseur de contenu. Par exemple, des balises ("tag") pour un document hypertexte en tant que contenu de ressource 10 sont insérées généralement au début du document.

Certaines de ces balises définissent des champs de l'en-tête de la réponse. L'insertion dans le document hypertexte d'une ligne de code, <meta httpequiv="expires" content="Fri, 02 May 2003 14:21:46 15 GMT">, paramètre le champ de l'en-tête de réponse appelé "Expires" à une date indiquée par "content".

Le champ d'en-tête "Expires" renseigne sur la date et l'heure à partir de laquelle la réponse contenant le document hypertexte devient obsolète. Cette deuxième 20 solution contraint le fournisseur de contenu à coder souvent lui-même les documents hypertextes. De plus, cette gestion d'entête ne s'applique qu'a un certain type de document, particulièrement les documents hypertextuels. En effet, un fournisseur de contenu ne 25 peut pas gérer avec cette solution des champs d'entêtes de documents de type son, image ou vidéo.

Dans une troisième solution, les champs sont insérés dynamiquement par le fournisseur de contenu dans chaque document grâce à l'utilisation de scripts 30 en langage de programmation évolué tel PHP, JSP ou C. Cette troisième solution requiert évidemment des compétences humaines spécifiques et coûteuses pour le fournisseur de contenu. De plus, comme les serveurs dans une plate-forme d'un hébergeur sont susceptibles 35 d'utiliser du matériel et des logiciels différents, un même script s'implémente difficilement sur plusieurs serveurs à moins d'être récrit.

Les solutions énoncées précédemment sont difficilement applicables à la gestion d'un très grand nombre de documents.

La présente invention vise à remédier aux inconvénients précités en gérant de manière automatique et centralisée, des champs dans les en10 têtes de message de réponses, indépendamment du choix matériel et logiciel des serveurs de contenu.

Pour atteindre cet objectif, un procédé pour gérer automatiquement des champs dans un en-tête 15 d'une réponse incluant le contenu d'une ressource identifiée par une adresse et mémorisée dans un serveur d'origine en réponse à une requête transmise par un terminal d'usager à travers un réseau de télécommunications, est caractérisé en ce qu'il 20 comprend les étapes de: intercepter la requête transmise du terminal au serveur d'origine afin de mémoriser au moins l'adresse incluse dans la requête interceptée, et intercepter la réponse transmise par le serveur 25 d'origine afin de modifier au moins un champ de l'entête de la réponse interceptée selon au moins l'une des règles de gestion prédéterminées en correspondance avec l'adresse mémorisée incluse dans la requête interceptée, et produire une réponse 30 modifiée transmise au terminal.

Ce système de gestion simplifiée centralise la gestion des champs d'entête des réponses pour les fournisseurs de contenu et l'hébergeur. Certains champs peuvent être des champs propriétaires.

L'interception des réponses assure ainsi automatiquement une gestion des en-têtes dans les réponses, typiquement selon le protocole de transfert HTTP, et donc la cohérence des champs dans l'en-tête 5 d'une réponse et la cohérence des champs des en-têtes pour les réponses modifiées, issues initialement d'un même serveur d'origine géré par un fournisseur de contenu. La cohérence des réponses est également respectée indépendamment des serveurs d'origine 10 installés sur une plate-forme commune d'hébergeur.

En général, la modification de la réponse interceptée peut reposer sur des paramètres inclus dans des en-têtes aussi bien de la requête que de la réponse. La modification peut consister en ou être 15 complétée par, une adjonction ou une suppression au moins d'un champ à l'en-tête de la réponse interceptée selon au moins l'une des règles de gestion qui peut dépendre au moins d'un champ inclus dans la réponse ou requête interceptée. Certains 20 champs peuvent être systématiquement adjoints à l'entête de la réponse interceptée. Par exemple, un champ "date" est adjoint systématiquement afin d'assurer une synchronisation de serveurs.

L'invention concerne également un système pour 25 gérer automatiquement des champs dans un en-tête d'une réponse incluant le contenu d'une ressource identifiée par une adresse et mémorisée dans un serveur d'origine en réponse à un message de requête transmis par un terminal d'usager à travers un réseau 30 de télécommunications, qui est caractérisé en ce qu'il comprend: un moyen pour intercepter la requête transmise du terminal au serveur d'origine, un moyen pour mémoriser au moins l'adresse 35 incluse dans la requête interceptée, un moyen pour intercepter la réponse transmise par le serveur d'origine, un moyen pour pré-mémoriser des règles de gestion de champ d'en-tête prédéterminées en correspondance avec des adresses de ressource, et un moyen pour modifier au moins un champ de l'en-tête de la réponse interceptée selon au moins l'une des règles de gestion prédéterminées en correspondance avec l'adresse mémorisée incluse dans 10 la requête interceptée afin de produire une réponse modifiée transmise au terminal à travers le moyen pour intercepter.

D'autres caractéristiques et avantages de la 15 présente invention apparaîtront plus clairement à la lecture de la description suivante de plusieurs réalisations préférées de l'invention, a titre d'exemples non limitatifs, en référence aux dessins annexés correspondants dans lesquels: - la figure 1 est un bloc-diagramme schématique d'un système de gestion de champs d'en-tête mettant en oeuvre le procédé selon une réalisation préférée de l'invention; et - la figure 2 est un algorithme du procédé pour 25 gérer automatiquement des champs d'un en-tête d'un message de réponse selon la réalisation préférée.

Selon la réalisation préférée de l'invention montrée à la figure 1, le système de gestion de 30 champs d'en-tête mettant en oeuvre le procédé selon l'invention comporte plusieurs terminaux d'usager T, un module d'interception MI, au moins un serveur d'origine SO, un serveur de gestion de règles SGR associé à une base de données de règles de gestion de champs d'en-tête BDR, une base de données de requêtes BREQ, et un serveur d'analyse d'en-tête SA.

Chaque usager peut accéder au système de gestion de champs d'en-tête par plusieurs terminaux. Les terminaux T et les deux serveurs SO et SGR sont reliés à travers un réseau de télécommunications comprenant un réseau de paquets RP, tel que l'internet, et des réseaux d'accès RA respectivement pour les terminaux d'usager T. Le terminal T est 10 relié a un réseau d'accès par une liaison de télécommunications LT. La liaison de télécommunications LT peut être une ligne xDSL (Digital Subscriber Line), une ligne RNIS (Réseau Numérique à Intégration de Services) ou une liaison 15 radio reliée au réseau d'accès RA correspondant. Par exemple, lorsqu'un terminal d'usager est un ordinateur personnel équipé d'un modem ou est un terminal intelligent du type récepteur de télévision, le réseau d'accès RA est le réseau téléphonique 20 commuté. Selon un autre exemple, lorsque le terminal d'usager est du type radiotéléphone ou objet électronique portable, comme un assistant numérique personnel PDA communicant, le réseau d'accès RA est un réseau de radiotéléphonie cellulaire de type GSM 25 ou UMTS.

Le système présente classiquement une architecture du type client-serveur entre les terminaux d'usager T et les serveurs SO et SGR. Le serveur d'origine SO est relié au réseau de 30 télécommunications à travers le module d'interception MI. Le serveur SO est un serveur d'origine qui contient physiquement une ressource définie cidessous.

Dans la suite de la description, on se référera

en tant que protocole de transport requête-réponse au protocole HTTP (HyperText Transfer Protocol). Pour une connexion avec un terminal radiotéléphonique, le 5 protocole utilisé entre le serveur d'origine SO et le module d'interception MI est encore le protocole HTTP, bien que le terminal radiotéléphonique connecté au réseau RP à travers un proxy communique avec le proxy selon un protocole différent, par exemple le 10 protocole WAP (Wireless Application Protocol). Le module d'interception MI joue le rôle de proxy WAP et transforme des messages de requête transmis par le terminal radiotéléphonique ou des messages de réponse à transmettre au terminal radiotéléphonique selon un 15 autre protocole, par exemple le protocole WAP.

Le protocole HTTP est un protocole de niveau applicatif suffisamment léger et rapide pour la transmission de documents distribués et multimédias à travers un système d'information multi-usager. Dans 20 la suite de la description, un message est une unité de données protocolaire d'une communication HTTP consistant en une séquence structurée d'octets. Le protocole HTTP est basé sur un paradigme requête/réponse. Une requête REQ est un message de 25 requête HTTP et une réponse REP est un message de réponse HTTP. Une ressource est un service ou objet du réseau référencée par une adresse URI (Uniform Resource Identifier) tel qu'un nom, une localisation ou toutes autres caractéristiques. La requête REQ 30 contient l'adresse URI de la ressource demandée par le terminal d'usager T ainsi qu'une adresse IP (Internet Protocol) du terminal T. Lorsque le terminal T établit une connexion vers le serveur d'origine SO, le terminal lui envoie une 35 requête REQ comportant une ligne de début (start line), des champs d'en- tête et éventuellement un corps de message. La ligne de début peut inclure une opération désignée par une méthode, une adresse URI et un numéro de version du protocole HTTP. Les champs 5 d'en-tête peuvent inclure des modificateurs de la requête, des informations sur le terminal, et un type de format de la ressource acceptable dans le serveur comme un type MIME (Multipurpose Internet Mail Extension) désignant une ressource textuelle, 10 d'image, audio ou vidéo.

Comme montré à la figure 2, le procédé selon l'invention débute par une connexion du terminal T au serveur SO à une étape El comprenant la transmission d'une requête REQ à une étape E2. La connexion est 15 fermée par le serveur d'origine après délivrance d'une réponse REP. Le terminal T et le serveur d'origine SO sont préparés à ce que la connexion soit prématurément coupée suite par exemple à une action de l'usager du terminal, la réponse REP spécifiant 20 alors le type d'erreur rencontrée. Dans tous les cas, la fermeture d'une connexion qu'elle qu'en soit la raison est assimilable à la conclusion de la requête.

Le serveur d'origine SO répond par une ligne d'état comprise dans la réponse REP et incluant la 25 version de protocole, un code de statut (status code) exprimant le succès ou l'échec du serveur dans le traitement de la requête reçue, suivie de champs d'en-tête relatifs au type MIME de la ressource d'information visée dans le serveur et à des méta30 informations. Les champs d'en-tête peuvent être suivis d'un corps de réponse.

Les requêtes REQ et les réponses REP contiennent généralement une entité dans laquelle est incluse des éléments de requête ou de réponse. Une 35 entité représente une méta-information composée d'un en-tête et bien souvent d'un contenu sous la forme d'un corps. Un en-tête HTTP comporte des champs d'entête HTTP classés en quatre groupes: les champs d'en-tête général, de requête, de réponse et 5 d'entité. Chaque champ d'en-tête consiste en un nom suivi immédiatement d'un deux-points (":"), un espace et une valeur. L'ordre dans lequel les champs d'entête sont reçus n'a pas d'importance. Lorsque plusieurs champs de même nom sont définis avec des 10 valeurs différentes, celles-ci apparaissent comme une liste séparée par des virgules.

Les champs d'en-tête général ont une utilité dans tous les messages, c'est-à-dire aussi bien dans des requêtes que dans des réponses, en conservant la 15 même signification. Les informations définies dans ces champs concernent le message lui-même, et non l'entité qu'il transporte. Le champ d'en-tête général "Date" donne la date et l'heure à laquelle le message a été généré. Le champ "Date" est utile pour un 20 système de gestion de cache tel qu'un proxy.

Les champs d'en-tête de requête contiennent des informations complémentaires sur la requête REQ et le terminal T destinées au serveur SO. Dans la version HTTP 1.0 sont définis les champs d'en-tête de 25 requête suivants: "Authorization", "From", "Ifmodified-since", "Referer", "User-agent". Par exemple, le champ d'en-tête "Referer" dans une requête transmise par le terminal indique au serveur d'origine SO l'adresse URI de la ressource dans 30 laquelle l'adresse URI demandée par le terminal a été trouvée. Le serveur d'origine génère et entretient ainsi des listes d'adresses URI destinées à établir notamment des statistiques sur les médias ayant diffusés des adresses URI du site internet constitué 35 par le serveur SO.

Les champs d'en-tête de réponse contiennent des informations complémentaires sur le serveur d'origine SO et des actions à mener ultérieurement pour accéder à la ressource demandée. Par exemple, le champ 5 "Server" renseigne sur le logiciel utilisé par le serveur d'origine pour traiter la requête.

Les champs d'en-tête d'entité transportent certaines méta-informations sur le corps de message, ou si celui-ci n'existe pas, la ressource visée par 10 la requête en tant que message. Les champs d'en-tête d'entité suivant sont définis dans le protocole HTTP : "Allow", "Content-Accept", "Content-Encoding", "Content-Length", "Content-Type", "Expires", "LastModified", etc. Un mécanisme d'extension de l'en-tête 15 d'entité permet la définition d'autres champs. Par exemple, le champ "Content-Accept" dans une requête spécifie le codage de la ressource que le terminal souhaite exploiter, et le champ "Content-Encoding" renseigne sur le codage de la ressource mémorisée 20 dans le serveur d'origine SO, et ainsi sur le traitement tel que compression que peut effectuer le serveur d'origine.

Des nouveaux champs d'en-tête général ou de requête ou de réponse ne sont introduits que dans le 25 cadre d'un changement de version du protocole. Tout champ non reconnu sera considéré comme un champ d'entête d'entité.

En revenant à la figure 2, la requête REQ du 30 terminal contenant un entête est interceptée par le module d'interception MI à une étape E3 et transmise au serveur d'analyse SA et au serveur d'origine SO à une étape E4. La requête REQ, contenant l'adresse URI de la ressource contrairement à la réponse REP, est 35 mémorisée via le serveur d'analyse SA dans la base de données de requêtes BREQ à une étape E51 afin d'utiliser par la suite la correspondance entre la réponse REP du serveur d'origine et l'adresse URI.

La réponse REP provenant du serveur d'origine SO à l'étape E52 et contenant un en-tête est interceptée par le module d'interception MI situé à proximité du serveur SO, à une étape E6.

Comme déjà précisé, le module d'interception MI 10 joue le rôle d'un proxy qui reçoit une requête destinée à une ressource d'adresse URI et recompose tout ou partie de la requête en une requête transformée transmise au serveur SO. En retour, la réponse REP transite par le proxy. Le proxy associe 15 l'adresse de ressource URI extraite de la requête interceptée précédente REQ avec la réponse interceptée REP qu'il mémorise afin de la fournir à nouveau à un terminal si le proxy reçoit une requête similaire.

Ensuite le module d'interception MI ne transmet pas la réponse REP au terminal T mais l'intercepte pour la transmettre au serveur d'analyse d'en-tête SA à une étape E7.

Le serveur d'analyse SA applique automatiquement des règles de gestion correspondant à l'adresse URI de la ressource demandée, à la réponse interceptée REP, en établissant la correspondance entre l'adresse URI et la réponse REP par l'intermédiaire des couples 30 dans la base BREQ requête/URI et des couples réponse/requête dans le module MI à l'étape ES. Le serveur d'analyse SA analyse les champs contenus dans l'en-tête de la réponse interceptée REP afin de modifier au moins un champ de l'en-tête selon des 12 2858152 règles de gestion prédéterminées de champ d'en-tête RGC qui sont pré-mémorisées dans la base BDR.

Le serveur de gestion de règles SGR relié au terminal T par le réseau de télécommunications est un 5 serveur web classique disposant d'une application distribuant une interface web de saisie de règles de gestion dans un terminal. Au cours d'une phase d'initialisation, les règles de gestions de champ d'en-tête sont renseignées dans la base de données 10 BDR à travers l'interface web et le serveur SGR, par exemple par des fournisseurs gérant plusieurs serveurs d'origine respectifs SO ou par l'hébergeur gérant une plate-forme supportant les serveurs d'origine, les fournisseurs et l'hébergeur ayant été 15 préalablement identifiés dans le serveur SGR. Les règles de gestion RGC dépendent des adresses URI des ressources demandées par le terminal T dans un serveur d'origine SO distribuant le contenu d'un fournisseur de contenu et éventuellement de l'adresse 20 IP d'un terminal d'usager et/ou d'un type de terminal d'usager T. Pour un même fournisseur, les règles de gestion RGC varient en fonction de l'adresse des ressources URI. Par exemple les règles peuvent être différentes pour deux ressources localisées dans un 25 même serveur d'origine dont les adresses URI respectives sont: "http://monsite.com/image/maressource.php" "http://monsite.com/application/index.php" De la même manière, des règles de gestion dépendent 30 d'une partie commune à plusieurs adresses URI mémorisées. Une partie d'adresse URI commune "http://monsite. com/application/" regroupe toutes les ressources dont les adresses URI contiennent cette partie commune, par exemple "http://monsite.com/application/index.php" ou 13 2858152 "http://monsite.com/application/monfichier.php". Par exemple, un fournisseur de contenu pour le site web "http://monsite.com" choisit de mettre le champ d'entête "Pragma", ou "Cache-Control" selon une autre 5 version du protocole HTTP, qui spécifie un comportement optionnel d'un agent, à "no-cache" pour l'ensemble des ressources désignées par la partie d'adresse URI commune commençant par "http://monsite.com/jeux/" pour indiquer que les 10 ressources ayant des adresses URI avec cette partie commune ne seront pas conservées dans des proxys intermédiaires; les proxys intermédiaires ou autres agents de gestion de cache doivent alors transmettre la requête REQ avec le champ "no-cache" jusqu'au 15 serveur d'origine SO même lorsque l'agent dispose déjà d'une copie de la ressource demandée afin de délivrer au terminal d'usager la dernière version de la ressource disponible sur le serveur d'origine SO.

Les règles de gestion RGC portent sur une vérification et une modification éventuelle de champs de l'en-tête contenus dans la réponse interceptée REP. Le serveur d'analyse SA applique par exemple des règles pour vérifier la syntaxe de champs d'en-tête 25 prédéterminés, pour vérifier l'intégrité entre des valeurs contenues dans deux champs d'en- tête, etc. Par exemple, une règle consiste à vérifier que la valeur du champ "Last-Modified" qui indique la date de la dernière modification de la ressource adressée, 30 est une date dans un format de date autorisé (Allowed), comme selon le format suivant: "Tue, 15 Nov 1994 12:45:26 GMT") . Des règles de modification de champ d'en-tête sont, par exemple, une modification de la valeur du champ "Last-Modified" 35 afin que la valeur de celui-ci soit toujours égale à la date de la veille, ou une modification du champ d'en-tête "Pragma" à la valeur "no-cache" Dans une autre variante, le serveur d'analyse SA analyse les champs de l'en-tête de la réponse 5 interceptée REP afin d'ajouter un champ dans l'entête en fonction de règles de gestion de champ d'entête lorsque ce que celui-ci n'est pas présent dans l'en-tête. Par exemple, une règle consiste à ajouter le champ "Last-Modified" avec une valeur 10 prédéterminée dans l'en-tête de toute réponse contenant un champ de type MIME prédéterminé.

Selon encore une autre variante, le serveur d'analyse supprime au moins un champ de l'en-tête dans la réponse interceptée REP en fonction d'au 15 moins une règle de gestion de champ d'en-tête prédéterminée.

Une règle de gestion de champ d'en-tête modifie ainsi un champ, ou ajoute un champ à l'en-tête de la réponse interceptée REP en fonction au moins d'un 20 champ inclus dans l'en-tête de la réponse interceptée et/ou d'adresses URI et/ou de parties d'adresse URI.

Par exemple, la date du champ "Expire" est égale à la date indiquée par le champ "Last-Modified" plus quatre jours, évidemment lorsque le champ "Last25 Modified" est déjà inclus dans la réponse REP par le serveur d'origine SO. Une règle de gestion de champ d'en-tête peut être également appliquée systématiquement.

Cependant, une règle peut modifier également un 30 champ de l'en-tête dans la réponse interceptée REP ou ajouter un champ dans l'en-tête de la réponse à modifier en fonction au moins d'un champ déjà inclus dans l'entête de la requête REQ transmise par le terminal T via le module MI et/ou de l'adresse IP du 35 terminal T. Dans une autre variante, le contenu de la ressource transmis est un document HTML (HyperText Markup Language) introduit dans le corps de la réponse REP par le serveur SO. Une règle définit 5 alors un champ de l'en-tête de la réponse interceptée notamment en fonction d'au moins une balise HTML, ou d'attribut dans celle-ci, incluse dans le document HTML.

Selon d'autres variantes, le document hypertexte 10 HTML est remplacé par un document hypermédia constituant le contenu de la ressource identifiée par l'adresse URI dans la requête REQ; une règle de gestion définit un champ de l'en-tête dans la réponse modifiée REPM en fonction d'une balise incluse dans 15 le document hypermédia inclus dans la réponse REP.

D'une manière générale à l'étape E8, le serveur d'analyse SA applique automatiquement à un ou plusieurs champs de l'en-tête de chaque réponse interceptée REP identifiée par une adresse URI, 20 respectivement des règles de gestion en correspondance avec l'adresse URI, mémorisées dans la base de données BDR, afin de produire une réponse modifiée REPM contenant un ou plusieurs champs de l'en-tête modifiés et/ou ajoutés, et/ou supprimés. A 25 une étape E9, la réponse REPM est transmise par le serveur SA au module d'interception MI qui le renvoie vers le terminal d'usager T à travers le réseau de télécommunications à l'étape E10.

Dans une variante, le serveur d'origine SO et le serveur d'analyse SA sont réunis en un unique serveur. Le module d'interception MI peut être inclus dans le serveur d'origine SO.

1 6 2858152 Dans une autre réalisation, le module d'interception MI est en fait un proxy et le serveur d'analyse SA est similaire au moins partiellement à un serveur ICAP (Internet Content Adaptation 5 Protocol). Le serveur ICAP transforme et adapte un message, en l'occurrence une réponse REP selon des transformations et adaptations prédéterminées pour produire une réponse REPM. Par exemple, les transformations et adaptations sont une traduction du 10 contenu de réponses, une insertion de publicité, un filtrage, une compression, etc. Ainsi au moins, une règle de gestion de champ d'en-tête selon le procédé de l'invention peut être implémentée comme un serveur ICAP.

Claims (11)

REVENDICATIONS

1 - Procédé pour gérer automatiquement des champs dans un en-tête d'une réponse (REP) incluant 5 le contenu d'une ressource identifiée par une adresse (URI) et mémorisée dans un serveur d'origine (SO) en réponse à une requête (REQ) transmise par un terminal d'usager (T) à travers un réseau de télécommunications (RP), caractérisé en ce qu'il 10 comprend les étapes de: intercepter (E3) la requête (REQ) transmise du terminal (T) au serveur d'origine (SO) afin de mémoriser (E51) au moins l'adresse (URI) incluse dans la requête interceptée (REQ), et intercepter (E6) la réponse (REP) transmise par le serveur d'origine (SO) afin de modifier (E8) au moins un champ de l'en-tête de la réponse interceptée selon au moins l'une des règles de gestion prédéterminées (RGC) en correspondance avec l'adresse 20 mémorisée (URI) incluse dans la requête interceptée, et produire une réponse modifiée (REPM) transmise (E9, E10) au terminal (T).

2 - Procédé conforme à la revendication 1, selon 25 lequel au moins un champ est ajouté à l'en-tête de la réponse interceptée (REP) selon au moins l'une des règles de gestion (RGC) afin de produire la réponse modifiée (REPM) transmise au terminal (T).

3 - Procédé conforme à la revendication 1 ou 2, selon lequel au moins un champ de l'en-tête de la réponse interceptée (REP) est supprimé selon au moins l'une des règles de gestion (RGC) afin de produire la réponse modifiée (REPM) transmise au terminal (T).

18 2858152 4 - Procédé conforme à l'une quelconque des revendications 1 à 3, selon lequel au moins l'une des règles de gestion (RGC) dépend de l'adresse de ressource mémorisée (URI) incluse dans la requête interceptée (REQ).

- Procédé conforme à l'une quelconque des revendications 1 à 4, selon lequel au moins l'une des règles de gestion (RGC) dépend d'une partie commune à 10 plusieurs adresses de ressource mémorisées (URI).

6 - Procédé conforme à l'une quelconque des revendications 1 à 5, selon lequel une règle de gestion (RGC) modifie un champ de l'en-tête dans la 15 réponse (REP) ou ajoute un champ dans l'en-tête de la réponse en fonction au moins d'un champ inclus dans l'en-tête de la réponse interceptée (REP) afin de produire la réponse modifiée (REPM) au terminal (T).

7 - Procédé conforme à l'une quelconque des revendications 1 à 6, selon lequel une règle de gestion (RGC) modifie un champ de l'en-tête dans la réponse interceptée (REP) ou ajoute un champ dans l'en-tête de la réponse interceptée (REP) en fonction 25 au moins d'un champ inclus dans l'entête de la requête interceptée (REQ) afin de produire la réponse modifiée (REPM) au terminal (T).

8 - Procédé conforme à l'une quelconque des 30 revendications 1 à 7, selon lequel une règle de gestion (RGC) modifie un champ de l'en-tête dans la réponse interceptée (REP) ou ajoute un champ dans l'en-tête de la réponse interceptée (REP) en fonction d'une adresse du terminal (T) afin de produire la 35 réponse modifiée (REPM) au terminal (T).

9 - Procédé conforme à l'une quelconque des revendications 1 à 8, selon lequel le contenu de ressource identifié par l'adresse (URI) dans la 5 requête (REQ) est un document hypermédia, et une règle de gestion (RGC) définit un champ de l'en-tête dans la réponse modifiée (REPM) en fonction d'une balise incluse dans le document hypermédia inclus dans la réponse (REP).

- Système pour gérer automatiquement des champs dans un en-tête d'une réponse (REP) incluant le contenu d'une ressource identifiée par une adresse (URI) et mémorisée dans un serveur d'origine (SO) en 15 réponse à un message de requête (REQ) transmis par un terminal d'usager (T) à travers un réseau de télécommunications (RP), caractérisé en ce qu'il comprend: un moyen (MI) pour intercepter la requête (REQ) 20 transmise du terminal (T) au serveur d'origine (SO), un moyen (BREQ) pour mémoriser au moins l'adresse (URI) incluse dans la requête interceptée (REQ), un moyen (MI) pour intercepter la réponse (REP) 25 transmise par le serveur d'origine (SO), un moyen (BDR, SGR) pour pré-mémoriser des règles de gestion de champ d'en-tête prédéterminées (RGC) en correspondance avec des adresses de ressource (URI), et un moyen (SA) pour modifier au moins un champ de l'en-tête de la réponse interceptée selon au moins l'une des règles de gestion prédéterminées en correspondance avec l'adresse mémorisée (URI) incluse dans la requête interceptée afin de produire une réponse modifiée (REPM) transmise au terminal (T) à travers le moyen pour intercepter (MI).

11 - Système conforme à la revendication 8, dans 5 lequel le moyen pour modifier (SA) ajoute au moins un champ à l'en-tête de la réponse interceptée (REP) selon au moins l'une des règles de gestion (RGC) afin de produire la réponse modifiée (REPM) transmise au terminal (T).

12 - Système conforme à la revendication 10 ou 11, dans lequel le moyen pour modifier (SA) supprime au moins un champ de l'en-tête de la réponse interceptée (REP) selon au moins l'une des règles de 15 gestion (RGC) afin de produire la réponse modifiée (REPM) transmise au terminal (T).

13 - Système conforme à l'une quelconque des revendications 10 à 12, dans lequel les moyens pour 20 intercepter (MI) sont un proxy.

14 - Système conforme à l'une quelconque des revendications 10 à 13, dans lequel le moyen pour modifier (SA) est similaire au moins partiellement à 25 un serveur à protocole d'adaptation de contenu internet (ICAP).

- Système conforme à l'une quelconque des revendications 10 à 14, dans lequel le moyen pour 30 pré-mémoriser comprend une base de données (BDR) liée au moyen pour modifier (SA), et un serveur de gestion de règles (SGR) pour mémoriser préalablement des règles de gestion (RGC) dans la base de données (BDR).