La présente invention se rapporte, de façon générale, à un procédé et à 5 un système destinés à améliorer l'accès à un service sur un réseau de type Internet.

Plus précisément, cette invention vise à améliorer le mécanisme de redirection décrit dans la RFC2616 (Requests for Commente) de I ¹ IETF (Internet Engineering Task Force), mécanisme qui, de façon connue, permet de rediriger 10 un utilisateur souhaitant accéder à une première page HTML vers une autre page HTML en incluant, dans la première page, un « meta » contenant l'adresse URL de cette deuxième page de la façon suivante : < meta http-equiv = "refresh " content = "0 ; url = http : // pagederedirection"/>.

Ce mécanisme de redîrection présente un inconvénient majeur, 15 notamment lorsqu'il est utilisé dans un réseau de télécommunication mobile offrant un débit limité, car le débit utile nécessaire à la consultation des pages souhaitées se trouve surchargé par le trafic dû aux redirections.

On notera en effet que ces allers-retours ont un impact significatif sur le trafic puisqu'une étude statistique réalisée sur un réseau d'entreprises montre 20 que les redirections représentent plus de 10 % des requêtes de type text/HTML.

L'invention vise à palier cet inconvénient en court-circuitant les requêtes de redirection envoyées aux équipements mobiles par les serveurs du réseau Internet, ce qui permet de réduire la latence ressentie par l'utilisateur.

A cet effet et, selon un premier aspect, l'invention concerne un serveur de 25 modification de requêtes et de réponses HTTP susceptible d'être utilisé dans un réseau de type Internet, ce serveur comportant :

- des moyens de réception d'une requête de redirection comprise dans une réponse HTTP à destination d'un poste utilisateur,

- des moyens d'obtention de l'adresse de redirection contenue dans 30 cette réponse HTTP ;

- des moyens de création d'une requête de substitution, à partir d'informations relatives au poste utilisateur ;

- des moyens d'envoi de la requête de substitution à destination de l'adresse de redirection ;

- des moyens de réception d'une réponse à cette requête de substitution; et - des moyens de transmission, au poste utilisateur, de la réponse à la requête de substitution.

Dans la suite de la description et, dans un souci de concision, le serveur de modification de requêtes et de réponses sera appelé « serveur de modification ». Conformément à l'invention, le serveur de modification reçoit la requête de redirection qui était normalement destinée au poste utilisateur, puis accède au contenu situé à l'adresse de redirection, seul ce contenu étant transmis in fine au poste utilisateur.

Ainsi, lorsque le poste utilisateur est un équipement mobile, seul le contenu utile, à savoir celui recherché par l'utilisateur est véhiculé sur le réseau de télécommunication mobile.

Dans un mode préféré de réalisation du serveur de modifications selon l'invention, celui-ci comporte en outre des moyens d'obtention des informations relatives au poste client à partir d'un serveur proxy comportant un client adapté à mettre en œuvre ledit protocole de modification de requêtes et de réponses

HTTP.

Selon ce mode de réalisation préféré, les informations relatives au poste client sont collectées, directement ou indirectement par le serveur proxy, le serveur de modification étant avantageusement dédié à la gestion du service de redirection de requêtes proprement dit.

Selon un deuxième aspect, l'invention vise un système d'interception d'une requête de redirection comprise dans une réponse HTTP à destination d'un poste utilisateur dans un réseau de type Internet, ce système comportant :

- un serveur de modification de requêtes et de réponses HTTP tel que mentionné ci-dessus ; et

- un serveur proxy comportant :

- des moyens de mise en œuvre du protocole HTTP ; et

- un client adapté à mettre en œuvre le protocole de modification précité, et à transmettre la requête de redirection au serveur de modification.

Préférentiellement, le serveur proxy comporte des moyens d'enregistrement de l'adhésion du poste utilisateur au service d'interception de requête de redirection, et le client du serveur proxy vérifie si le poste utilisateur a adhéré à ce service avant de transmettre la requête de redirection au serveur de modification.

Dans une première variante de réalisation, les moyens d'enregistrement de l'adhésion de l'utilisateur sont adaptés à obtenir directement les informations relatives à cet utilisateur, par exemple sous forme d'un questionnaire d'adhésion.

Dans une autre variante de réalisation, le serveur proxy obtient les informations relatives au poste utilisateur par analyse du trafic HTTP qui le traverse. Corrélativement et, selon un troisième aspect, l'invention vise un procédé d'interception d'une requête de redirection comprise dans une réponse HTTP à destination d'un poste utilisateur dans un réseau de type Internet, ce procédé, susceptible d'être mis en œuvre par un serveur de modification de requêtes et de réponses HTTP, comportant : - une étape de réception de la réponse HTTP ;

- une étape d'obtention de l'adresse de redirection contenue dans cette réponse HTTP ;

- une étape de création d'une requête de substitution, à partir d'informations relatives au poste utilisateur ; - une étape d'envoi de la requête de substitution à destination de l'adresse de redirection ;

- une étape de réception d'une réponse à cette requête de substitution ; et

- une étape de transmission, au poste utilisateur, de la réponse à la requête de substitution.

Les avantages particuliers du procédé d'interception étant identiques à ceux du serveur de modification introduit précédemment, ils ne seront pas rappelés ici.

D'autres aspects et avantages de la présente invention apparaîtront plus clairement à la lecture de la description de modes particuliers de réalisation qui va suivre, cette description étant donnée uniquement à titre d'exemple non limitatif et faite en référence aux dessins annexés sur lesquels : - la figure 1 représente de façon schématique un système d'interception de requêtes de redirection conforme à l'invention dans une variante préférée de réalisation ;

- la figure 2 représente, sous forme d'organigramme, les principales étapes d'un procédé d'interception de requêtes de redirection mis en œuvre dans le système de la figure 1 ; et

- la figure 3 représente, de façon schématique, le flux d'informations entre les différents équipements du système d'interception de la figure 1.

La figure 1 représente une variante préférée de réalisation d'un système d'interception de requêtes de redirection dans un réseau 5 de type Internet. Ce système comporte au moins un poste d'utilisateur 10 équipé d'un navigateur Internet 15, ce poste 10 étant relié au réseau Internet 5, via un serveur proxy 20, adapté à mettre en oeuvre le protocole HTTP.

Dans le mode préféré de réalisation décrit ici, le serveur proxy 20 est hébergé chez un fournisseur d'accès 25 auquel le poste utilisateur 10 doit se connecter pour accéder au réseau 5.

Ce fournisseur d'accès 25 comporte également un serveur de contrôle d'accès 30 capable d'authentifier l'utilisateur du poste 10, par exemple à partir d'un identificateur (login) et d'un mot de passe, et à fournir une adresse IP

(Internet Protocol) au poste 10 pour que celui-ci puisse naviguer sur le réseau Internet 5.

Une fois cette adresse IP délivrée, toutes les requêtes et les réponses HTTP (Hyper Text Transfer Protocol) émises et reçues par le poste utilisateur 10 pour accéder au réseau 5 transitent via le serveur proxy 20.

Dans le mode préféré de réalisation décrit ici, le serveur proxy 20 comporte des moyens pour enregistrer l'adhésion de l'utilisateur du poste utilisateur 10 à un service d'interception de requêtes de redirection.

Lors de cette adhésion, le serveur proxy 20 collecte et mémorise, en particulier, des informations relatives au poste utilisateur 10 (adresse IP, cookie de session, ...).

En variante, les informations personnelles du poste utilisateur 10 peuvent 5 être obtenues directement par les moyens de service proxy 20 adaptés à mettre en œuvre le protocole HTTP, par analyse du trafic HTTP.

Le système d'accès comporte aussi un fournisseur de service 45 relié au réseau 5, pour rendre des services à l'utilisateur du poste 10, en réponse à une requête d'accès M1 relayée par le serveur proxy 20 sous la forme d'une requête i o M2.

Nous supposerons par la suite que le fournisseur de service 45 répond à la requête M2 en émettant, en direction du poste utilisateur 10, une réponse HTTP M3 comportant une requête de redirection.

De façon connue, cette réponse HTTP M3 comporte notamment l'adresse 15 IP (Internet Protocol) du poste utilisateur 10.

Le système selon l'invention comporte également, raccordé au réseau Internet 5, un serveur 50 baptisé « serveur de modification de requêtes » et adapté à mettre en oeuvre un protocole permettant la modification de requêtes et de réponses HTTP. 0 Dans le mode préféré de réalisation décrit ici, le serveur de modification de requêtes 50 comporte des moyens pour obtenir, à partir du serveur proxy 20, les informations relatives au poste utilisateur 10, ces informations ayant été obtenues par le serveur proxy 20, par exemple lors de l'adhésion de l'utilisateur de ce poste au service d'interception de requêtes de redirection. 5 Dans le mode préféré de réalisation décrit ici, ce serveur 50 est constitué par un serveur iCAP 50 (Internet Content Adaptation Protocol) adapté à mettre en oeuvre le protocole iCAP.

Conformément à l'invention, le serveur proxy 20 comporte un client 55 adapté à mettre en œuvre le même protocole que le serveur de modification de 0 requêtes 50, à savoir ici le protocole iCAP.

Dans une première variante de réalisation, le client iCAP 55 du serveur proxy 20 est configuré pour ne transmettre au serveur iCAP 50 que les réponses

HTTP M3 comportant des requêtes de redirection destinées à un utilisateur ayant adhéré au service d'interception de requêtes de redirection.

Ainsi, dans cette première variante de réalisation, lorsque le serveur proxy 20 voit passer la réponse HTTP M3 comportant la requête de redirection, il intercepte cette réponse et l'envoie, sous la forme d'une requête iCAP M4 au serveur iCAP 50, en utilisant le protocole iCAP.

Dans une deuxième variante de réalisation, le client iCAP 55 du serveur proxy 20 transmet, au serveur iCAP 50, toutes les réponses HTTP destinées au poste utilisateur 10. Dans cette deuxième variante de réalisation, le serveur iCAP 50 comporte des moyens pour transmettre directement, au poste utilisateur 10, la réponse HTTP M3 reçue du serveur proxy 20, si cette réponse M3 ne comporte pas de requête de redirection.

On supposera ci-après que le serveur iCAP 50 a reçu la réponse HTTP M3 sous la forme de la requête iCAP M4, cette réponse HTTP M3 comportant notamment la requête de redirection et l'adresse IP du poste utilisateur 10.

Conformément à l'invention, le serveur iCAP 50 est adapté à obtenir l'adresse URL de redirection à partir de cette réponse HTTP M3.

Conformément à l'invention, le serveur iCAP 50 comporte des moyens de création d'une requête HTTP de substitution M5 à partir des informations relatives au poste utilisateur 10 (adresse IP, cookies de session,...) de sorte que le contenu de cette requête HTTP de substitution M5 est identique au contenu d'une requête HTTP qui aurait été créée par le navigateur Internet 15 du poste utilisateur 10 en réponse à la réponse HTTP M3 émise par le fournisseur de service 45.

Le serveur iCAP 50 comporte des moyens pour envoyer la requête HTTP de substitution M5 à destination du serveur HTTP 35 dont l'adresse sur le réseau Internet 5 est l'adresse URL de redirection obtenue dans la réponse HTTP M3.

Dans le mode de réalisation décrit ici, cette requête HTTP de substitution M5 est relayée, sous la forme d'une requête HTTP M6, par le serveur proxy 20.

Le serveur ICAP 50 comporte des moyens de réception de la réponse HTTP M7 à la requête HTTP M5 de substitution, cette réponse étant dans le

mode préféré de réalisation décrit ici relayée par le serveur proxy 20 sous la forme d'une réponse HTTP M8.

Conformément à l'invention, le serveur iCAP 50 comporte des moyens de transmission adaptés à transmettre cette réponse HTTP M8 au poste utilisateur 10, (en l'espèce, la page HTML située à l'adresse Internet /pagederedirection/) sous la forme d'une réponse HTTP M9, relayée par le serveur proxy 20 sous la forme d'une réponse HTTP M10.

Nous allons maintenant décrire, en référence aux figures 2 et 3, le flux d'informations entre les différents équipements du système d'interception de la figure 1 et plus précisément les principales étapes du procédé d'interception mis en œuvre par le serveur iCAP 50.

Nous supposerons tout d'abord que l'utilisateur du poste utilisateur 10 a adhéré au service d'interception de requêtes de redirection et que ses informations personnelles (adresse IP, cookie de session,...) ont été obtenues par le serveur iCAP 50, au cours d'une étape préliminaire d'obtention E5, à partir du serveur proxy 20.

Nous supposerons aussi que l'utilisateur du poste 10 a souhaité accéder à un service fourni par le fournisseur de service 45 et qu'une requête d'accès M1 au fournisseur de service 45 a été relayée par le serveur proxy 20, puis transmise sous la forme d'une requête M2 au fournisseur de service 45.

Nous supposerons enfin que le fournisseur du service 45 a répondu à la requête M2, par une réponse HTTP M3, en direction du poste utilisateur 10, et comportant une requête de redirection et que cette réponse HTTP M3 a été interceptée par le serveur proxy 20 et transmise sous la forme d'une requête iCAP M4 au serveur iCAP 50.

Au cours d'une première étape E 10, le serveur iCAP 50 reçoit la réponse HTTP M3 sous la forme de la requête iCAP M4.

Cette étape E10 de réception est suivie par un test E20 au cours duquel le serveur iCAP 50 recherche si la réponse HTTP M3 contient une requête de redirection.

Si tel n'est pas le cas, le résultat du test E20 est négatif et ce test est suivi par une étape E70 au cours de laquelle le serveur iCAP 50 transmet la réponse HTTP M3 au poste utilisateur 10.

En revanche, lorsque la réponse HTTP M3 comporte une adresse de redirection URL, le résultat du test E20 est positif.

Ce test est alors suivi par une étape E30 au cours de laquelle le serveur iCAP 50 obtient l'adresse de redirection URL dans la réponse HTTP M3. Cette étape E30 d'obtention est alors suivie par une étape E40 au cours de laquelle le serveur iCAP 50 crée une requête de substitution M5 à partir des informations personnelles (adresse IP, cookie de session,...) obtenues préalablement par le serveur iCAP 50, au cours de l'étape préliminaire E5.

Comme décrit précédemment, cette requête HTTP de substitution M5 est similaire à une requête HTTP qui aurait été créée par le navigateur Internet 15 du poste utilisateur 10 en réponse à la réponse HTTP M3 émise par le fournisseur de service 45.

Cette étape E40 est suivie par une étape E50 d'envoi de la requête de substitution M5 à destination de l'adresse de redirection URL. Dans le mode de réalisation décrit ici, cette requête HTTP de substitution

M5 est relayée sous la forme d'une requête HTTP M6 par le serveur proxy 20.

L'étape E50 d'envoi de la requête de substitution M5 est suivie par une étape E60 de réception d'une réponse M7 à la requête de substitution M5.

Dans le mode de réalisation décrit ici, cette réponse HTTP M7 est relayée par le serveur proxy 20 sous la forme d'une réponse HTTP M8. Il s'agit en fait de la page HTML située à l'adresse URL relayée par le serveur proxy 20.

L'étape E60 de réception de la réponse HTTP M8 est suivie par l'étape E70 de transmission de cette réponse au poste utilisateur 10, sous la forme d'une réponse HTTP M9 relayée par le serveur proxy 20 sous la forme d'une réponse HTTP M 10.