FR2877529A1 - Procede d'acces commun par partage a des donnees temoins volumineuses sur des sites web independants appartenant a un domaine distinct et serveur http permettant la mise en oeuvre du procede. - Google Patents

Abstract

L'invention concerne un procédé d'accès commun par partage à des données témoins volumineuses, associées à un navigateur (BW) et à un premier serveur (Ah1), par un deuxième serveur distinct (Bh2).On configure (A) sur le deuxième serveur (Bh2) n répertoires virtuels et sur requête d'accès à une application du navigateur (BW) vers le premier serveur (Ah1), on redirige (B) la requête d'accès vers un serveur intermédiaire (Ah2) appartenant au réseau du premier serveur (Ah1) mais assujetti au nom de domaine du deuxième serveur (Bh2), on sauvegarde (C) sous le contrôle du serveur intermédiaire (Ah1) les données témoins volumineuses sous forme de n premiers témoins élémentaires associés au navigateur (BW) et on redirige (D) la requête d'accès à l'application vers le deuxième serveur (Bh2), on récupère séquentiellement (E), par duplication des premiers témoins élémentaires, une même pluralité de deuxièmes témoins élémentaires, et on reconstruit (F) à partir de ces derniers, les données témoins volumineuses.

Description

PROCEDE D'ACCES COMMUN PAR PARTAGE A DES DONNEES TEMOINS

VOLUMINEUSES SUR DES SITES WEB INDEPENDANTS APPARTENANT

A UN DOMAINE DISTINCT ET SERVEUR HTTP PERMETTANT

LA MISE EN UVRE DU PROCEDE L'invention concerne un procédé d'accès commun par partage à des données volumineuses, sur des sites WEB indépendants appartenant à un même domaine.

Pour consulter ou accéder à une application ou service délivré par un site WEB (World Wide Web en anglais) un utilisateur équipé d'un terminal connecté au réseau INTERNET utilise un navigateur WEB.

Le navigateur précité utilise typiquement le protocole de communication HTTP, pour Hyper Text Transfer Protocol en anglais, pour émettre des requêtes d'accès vers un serveur HTTP, adresser et atteindre une ressource de diffusion de l'application ou service définie par une URI, pour Uniform Resource Identifier en anglais, en respectant les règles de syntaxe définies par la Recommandation RFC 2396.

Les URI précitées communément utilisées par les navigateurs pour atteindre une ressource de diffusion d'une application ou service sont en fait des URL pour Uniform Resource Locator en anglais, ou adresse WEB.

Une URL désigne, sous forme d'une chaîne de caractères, à la fois successivement le protocole à utiliser, un serveur HTTP et une ressource disponible auprès de ce serveur, ainsi que représenté en figure 1.

Le serveur HTTP est désigné dans l'URI, par le nom de machine, hostname en anglais, ainsi que par le nom de domaine du serveur informatique exécutant le 25 serveur HTTP.

La ressource est désignée dans l'URL par un chemin d'accès, path en anglais, et un nom de ressource, ainsi qu'illustré en figure 1, où : http désigne le PROTOCOLE, "monserveur" le NOM DE MACHINE, foo.com le NOM DE DOMAINE, /main/minor le CHEMIN D'ACCES à la ressource et maressource.html le NOM DE RESSOURCE à atteindre.

Un serveur HTTP diffusant une application ou un service WEB a classiquement besoin de sauvegarder et de restaurer, de manière répétitive, des données liées à l'utilisateur ou au terminal de cet utilisateur qui requiert l'accès à cette application ou service, que ces données proviennent d'informations fournies par cet utilisateur et/ou ce terminal ou qu'elles soient déduites de son utilisation de cette application ou service.

Ces données peuvent être persistantes ou durables, elles sont, dans ce cas, sauvegardées par le serveur informatique exécutant le serveur HTTP dans un système de base de données, ou sauvegardées par le navigateur WEB sous la forme d'un petit fichier appelé témoin élémentaire ou "cookie" en anglais. Les deux modes de sauvegarde précités peuvent être utilisés de manière à coexister.

Ces données peuvent au contraire être temporaires ou éphémères, le temps d'une session exécutée par l'utilisateur. Elles sont alors sauvegardées sous forme de données de session par le serveur informatique exécutant le serveur HTTP ou sauvegardées par le navigateur WEB sous forme d'un témoin, les deux modes de sauvegarde des données de session pouvant de même coexister.

Un service distribué par un deuxième serveur HTTP autre que celui, le premier, qui a sauvegardé, ou fait sauvegarder, des données liées à un utilisateur ou au terminal de cet utilisateur déterminé, mais qui désire accéder à ces données sauvegardées, dispose, à l'heure actuelle, des solutions techniques ci-après: 1) accéder directement à la base de données où ces données ont été sauvegardées; accéder indirectement à cette même base de données; 2) 3) accéder au témoin élémentaire sauvegardé par le navigateur WEB de cet utilisateur déterminé.

La solution technique 1 présente un inconvénient majeur: un lien réseau doit exister entre le service distribué par l'autre, le deuxième, serveur HTTP et la base de données. L'existence d'un tel lien n'est, en général, pas autorisée, pour des raisons de sécurité.

Lorsque l'existence d'un tel lien est autorisée par le fournisseur de service distribué par le premier serveur HTTP, qui a sauvegardé les données liées à un utilisateur ou au terminal de cet utilisateur, il reste à gérer les problèmes ci-après: a) l'accès aux données sauvegardées doit être contrôlé, afin que tous les services distribués par un serveur HTTP quelconque, distinct du deuxième serveur HTTP, n'accèdent pas à celles-ci en l'absence d'agrément donné par le premier serveur HTTP; b) il faut en outre vérifier que l'utilisateur déterminé ou le terminal de ce dernier, dont les données (le témoin élémentaire) sont stockées par ou sous le contrôle du premier serveur HTTP est également un utilisateur du deuxième serveur HTTP, éventuellement authentifié par ce dernier, et que l'on est en mesure, au moyen de tout mécanisme adapté, de faire le lien entre l'identité de cet utilisateur déterminé auprès du deuxième et du premier serveur HTTP. Cette dernière condition est nécessaire et impérative si le deuxième serveur HTTP veut être certain de récupérer les données de l'utilisateur déterminé concerné.

La résolution des problèmes a) et b) précités nécessite la mise en oeuvre de mécanismes et d'équipements complexes.

Outre la mise en place d'un élément intermédiaire offrant à tout autre serveur HTTP un accès à des données qui sont propres au premier serveur HTTP, la solution technique 2) doit assurer également la résolution des mêmes problèmes a) et b) précités dans le cas de la solution technique 1).

La solution technique 3) présente des inconvénients inhérents au fonctionnement des témoins élémentaires, lequel sera rappelé ci-après.

Un serveur HTTP répondant à la requête d'un navigateur WEB pour accéder à une ressource de diffusion d'une application, définie par une URL: http://monserveur.foo.com/main/minor/maressource.html inclut en général dans les en-têtes de ses messages de réponse http un ou plusieurs témoins élémentaires. Un témoin élémentaire ou "cookie" en anglais est alors défini par: un nom (par exemple "mon-cookie") ; une date d'expiration; en l'absence d'une telle date, le témoin est détruit par le navigateur WEB à la fin de la session WEB en cours. La mention d'une valeur de date significative permet de sauvegarder dans le témoin élémentaire une donnée persistante; une valeur alphanumérique, sous forme de chaîne de caractères, par exemple "ma valeur" ; un nom de domaine, par exemple "foo.com". En l'absence de l'information de nom de domaine, seul le serveur HTTP ayant défini le témoin élémentaire est en mesure de lire ce dernier. En corollaire, en présence de l'information de nom de domaine précitée, tous les serveurs HTTP exécutés par un serveur informatique dont le nom de domaine est identique à cette dernière, "foo.com" par exemple, sont en mesure de lire le témoin précité, en particulier d'interpréter la valeur alphanumérique ou chaîne de caractères "ma valeur" ; un chemin, par exemple "/main" ou "/minor" ; en présence de l'information de chemin, le témoin élémentaire n'est lisible par un serveur HTTP que dans le cas où le navigateur WEB cherche à accéder à une URL ou ressource située sur ce chemin; une valeur booléenne, 0 ou 1, indiquant si le témoin élémentaire doit uniquement être transmis à travers une connexion sécurisée HTTP, le témoin élémentaire n'étant placé en en-tête que lorsque cette valeur est la valeur 1 et que la connexion est sécurisée.

Lorsque le navigateur WEB transmet une requête d'accès à une ressource ou URL, tout témoin élémentaire vérifiant les trois conditions ci-après: a) le nom de domaine du réseau HTTP hébergeant la ressource ou URL précitée correspond au nom de domaine spécifié dans le témoin élémentaire, b) le chemin d'accès à la ressource désignée dans l'URL est inclus dans le chemin spécifié dans le témoin élémentaire, c) le niveau de sécurité de la connexion correspond à la valeur booléenne spécifiée dans le témoin élémentaire, est inséré automatiquement dans les en-têtes du message de requête adressé au serveur HTTP.

Ce mode opératoire, hormis la valeur de sécurité de la connexion, est inhérent à la structure en arbre de la gestion et de la syntaxe des noms de domaines, et des adresses URL des serveurs HTTP et ressources hébergées par ce dernier.

En référence au mode opératoire précité, il apparaît que la solution technique 3) de l'art antérieur se heurte alors à deux problèmes cruciaux: un problème d'incompatibilité de nom de domaine, car pour accéder au témoin élémentaire sauvegardé, l'application ou service distribué par un premier et un deuxième serveur HTTP doit être distribué par des serveurs HTTP assujettis et gérés par le même nom de domaine, ce qui n'est pas nécessairement le cas ou réduit considérablement les possibilités réelles d'accès par partage; un problème de limitation dans la taille des données susceptibles d'accès par partage, car la taille des données stockables dans les témoins élémentaires est soumise à plusieurs limitations: limitation de la taille d'un témoin élémentaire à 4 kilo-octets, au maximum, limitation du nombre de témoins par nom de domaine à 20, au maximum, limitation de la taille des en-têtes des messages http. En particulier, les serveurs utilisés le plus couramment, les serveurs "Apache" font l'objet d'une limite pré-compilée à 8 kilo-octets, qu'il n'est en aucun cas recommandé de transgresser, pour des raisons de sécurité de la transmission.

Le problème de la limitation dans la taille précité a pour conséquence directe de limiter théoriquement la taille ou longueur des données persistantes sauvegardables sous forme de témoin élémentaire à 80 kilooctets. Cette limite théorique ne peut toutefois pas être atteinte en raison de la limitation de fait à 4 kilo-octets imposée par la technique (une donnée persistante = un témoin élémentaire) des serveurs HTTP les plus couramment utilisés.

La présente invention a pour objet de remédier aux limitations et inconvénients inhérents au mode opératoire des serveurs actuels les plus courants, par la mise en oeuvre d'un procédé permettant à deux entités diffuseurs d'applications ou services sur le WEB appartenant à des réseaux distincts, c'est-à-dire des réseaux sans interconnexion possible, et exécutés par des serveurs HTTP assujettis à un nom de domaine distinct, de partager des données témoins volumineuses, dépassant largement la limite de fait des 4-kilo-octets.

Ce but est atteint, en particulier, en procédant à un partage de données témoins volumineuses persistantes, et à une répartition des données partagées sur plusieurs témoins élémentaires, lesquels sont alors échangés entre deux serveurs HTTP distincts, assujettis en outre à un nom de domaine distinct, par l'intermédiaire d'un serveur HTTP intermédiaire, accessible en réseau par l'un des deux serveurs mais assujetti toutefois au même nom de domaine que l'autre serveur HTTP de ces deux serveurs HTTP.

Le procédé d'accès commun par partage à des données témoins volumineuses, par un premier et un deuxième serveur HTTP implantés sur des sites WEB et des réseaux distincts et appartenant à des domaines distincts, ces données témoins volumineuses étant associées à un navigateur WE13 équipant un terminal client utilisateur sous le contrôle de ce premier serveur HTTP, objet de la présente invention, est remarquable en ce qu'il consiste au moins à configurer sur ce deuxième serveur HTTP une pluralité de n répertoires virtuels représentatifs d'un répertoire commun. Sur requête d'accès à une application transmise de ce navigateur WEB vers le premier serveur HTTP, il consiste, en outre, à rediriger cette requête d'accès à cette application vers un serveur HTTP intermédiaire distributeur de cette application appartenant au réseau de ce premier serveur HTTP mais appartenant au domaine de ce deuxième serveur HTTP, sauvegarder, sous le contrôle de ce serveur HTTP intermédiaire, les données témoins volumineuses sous forme d'une même pluralité de n premiers témoins élémentaires, chaque premier témoin élémentaire étant associé conjointement au navigateur WEB, rediriger cette requête d'accès à cette application de ce navigateur WEB vers ce deuxième serveur HTTP, récupérer séquentiellement, par duplication de la pluralité de n témoins élémentaires, au niveau du deuxième serveur HTTP, une même pluralité de n deuxièmes témoins élémentaires, reconstruire, à partir de la même pluralité de n deuxièmes témoins élémentaires les données témoins volumineuses.

Le procédé, objet de l'invention, trouve application à la gestion des protocoles d'échange de données, de diffusion d'applications de type client-serveur sur le WEB.

Une description plus détaillée du procédé objet de la présente invention et d'un serveur HTTP permettant la mise en oeuvre de ce dernier sera donnée ci-après en liaison avec les dessins, dans lesquels, outre la figure 1 qui représente, un processus d'adressage d'une ressource ou URL d'un serveur HTTP pour un navigateur WEB, connu de l'art antérieur; la figure 2a représente, à titre illustratif, la configuration quelconque de serveurs HTTP en réseau permettant la mise en oeuvre du procédé objet de la présente invention; la figure 2b représente, à titre purement illustratif, un organigramme des étapes essentielles de mise en oeuvre du procédé objet de l'invention dans une première variante de réalisation non limitative; - la figure 2c représente, à titre purement illustratif, un organigramme des étapes essentielles de mise en oeuvre du procédé objet de l'invention dans une deuxième variante de réalisation préférentielle, non limitative; la figure 3 représente, à titre illustratif, un détail de mise en oeuvre d'une étape de redirection de requête d'accès à une application de la figure 2b ou de la figure 2c; la figure 4 représente, à titre illustratif, un détail de mise en oeuvre de l'étape de sauvegarde de données témoins volumineuses sous forme de témoins élémentaires de la figure 2b ou 2c; la figure 5 représente, à titre illustratif, un détail de mise en oeuvre de l'étape de récupération séquentielle de la figure 2b ou de la figure 2c; la figure 6 représente, à titre illustratif, un détail de mise en oeuvre spécifique de l'étape de segmentation des données témoins volumineuses en chaînes de caractères successives; - la figure 7 représente, à titre illustratif, l'architecture spécifique d'un serveur HTTP configuré conformément à l'objet de la présente invention.

Une description plus détaillée du procédé d'accès commun par partage à des données témoins volumineuses, objet de l'invention, sera maintenant donnée en liaison avec les figures 2a et 2b.

Sur la figure 2a, on a représenté, à titre illustratif, une configuration quelconque de serveurs HTTP en réseau, configurés par un diffuseur d'applications D1 et par un diffuseur d'applications D2.

Les diffuseurs d'applications D1 et D2 mettent en ligne un certain nombre de ressources correspondant à des URI respectives.

Le diffuseur d'applications D1 propose des ressources prises en charge par deux serveurs HTTP Ahl et Ah2 et le diffuseur d'applications D2 met en ligne un certain nombre de ressources prises en charge par deux serveurs HTTP Bhl et Bh2. Les serveurs HTTP Ahl et Ah2 respectivement Bhl et Bh2 prennent en charge tout ou partie des ressources mises en ligne par le diffuseur d'applications DI respectivement D2.

De manière plus spécifique, ainsi que représenté en. figure 2a, les serveurs HTTP Ah' et Ah2 appartiennent au même réseau Ar et les serveurs HTTP Bh, et Bh2 appartiennent au réseau Br.

L'appartenance des serveurs HTTP Ahl, Ah2 respectivement Bhl, Bh2 à un même réseau implique pour les serveurs Ahl et Ah2 respectivement Bhl et Bh2 une communication possible entre serveurs HTTP appartenant au même réseau.

Au contraire, un des serveurs HTTP appartenant au réseau Ar ne peut communiquer directement avec l'un des serveurs HTTP appartenant au réseau Br et réciproquement.

En outre, l'un des serveurs HTTP appartenant au réseau Ar et l'un des serveurs HTTP appartenant au réseau Br, par exemple les serveurs HTTP Ah2 et Bh2, appartiennent au même domaine Internet et sont donc assujettis au même nom de domaine, le domaine foo.com pris à titre d'exemple. Concrètement, on indique que l'un des noms de serveur du fournisseur d'application dans une transaction sur Internet est du type "serveur Ah2. foo.com" pour le serveur HTTP Ah2 alors que l'un des noms sur Internet, pour le serveur Bh2 du diffuseur d'application D2 est de la forme "serveur Bh2.foo.com".

Un navigateur noté BW sur la figure 2a permet à un client utilisateur de consulter des services WEB sur le réseau Internet. Le navigateur BW précité est configuré de telle sorte qu'il accepte de recevoir des témoins élémentaires encore désignés "cookies" en anglais.

Le procédé d'accès commun par partage à des données témoins volumineuses conforme à l'objet de la présente invention sera maintenant décrit en liaison avec la figure 2b.

En référence à la figure précitée, le procédé objet de l'invention est mis en oeuvre par un premier serveur HTTP, le serveur Ah, du diffuseur d'applications DI et par un deuxième serveur HTTP, le serveur Bh2 du diffuseur d'applications D2 tel que représenté en figure 2a.

Ainsi que mentionné précédemment, les serveurs HTTP précités sont implantés sur des sites WEB et des réseaux distincts, les réseaux Ar et Br précédemment décrits, et appartiennent à des domaines distincts, seuls les serveurs HTTP Ah2 et Bh2 étant réputés être assujettis au même nom de domaine foo.com précité.

A priori, des données témoins volumineuses sont associées au navigateur WEB BW équipant le terminal client précédemment mentionné sous le contrôle du premier serveur HTTP le serveur Ahl précédemment décrit.

Pour cette raison, les données volumineuses sont notées VCBWAhi. Les données témoins volumineuses précitées sont réputées avoir été mises en oeuvre lors d'une transaction antérieure entre le navigateur WEB BW et le serveur HTTP Ahl lors de l'accès à des ressources mises en ligne par le diffuseur d'application D1.

Par données témoins volumineuses on indique que ces données témoins présentent une taille ou longueur en nombre d'octets très supérieure à celle d'un témoin élémentaire ou "cookie", cette taille de témoin élémentaire étant par définition, à l'heure actuelle, limitée à 4ko.

Le procédé objet de l'invention consiste ainsi que représenté en figure 2b, en une étape A, à configurer sur le deuxième serveur HTTP, le serveur Bh2 de la figure 2a, une pluralité de n répertoires virtuels représentatifs d'un répertoire commun. La notion de répertoire virtuel doit être comprise comme celle relative à des répertoires numériques non directement accessibles par un client utilisateur, mais dédiés au stockage d'informations spécifiques tels que des témoins élémentaires, ainsi qu'il sera décrit ultérieurement dans la description. Le répertoire commun est noté D2 et les répertoires virtuels [D2 Ainsi que représenté en outre en figure 2b, sur requête d'accès à une étape Al à une application transmise du navigateur WEB BW vers le premier serveur HTTP Ahl, la requête étant notée Re[Ax], le procédé objet de l'invention consiste en une étape B à rediriger cette requête d'accès à l'application Ax vers un serveur HTTP intermédiaire en particulier le serveur Ah2 du diffuseur D1 de l'application demandée, serveur distributeur de cette application et appartenant au réseau Ar du premier serveur HTTP Ah1, ce serveur intermédiaire appartenant toutefois au domaine foo.com du deuxième serveur HTTP Bh2 du deuxième fournisseur d'applications D2.

Sur la figure 2b à l'étape B de celle-ci, l'étape de redirection est notée par la relation [Ah1,DN1] Re[AxAh2,DN2I.

Dans la relation précédente, DN1 désigne le nom de domaine du premier serveur HTTP Ahl et DN2 désigne le nom de domaine du serveur HTTP Ah2 appartenant au même réseau Ar.

1=n J=1.

L'étape B précitée est suivie d'une étape C consistant à sauvegarder, sous le contrôle du serveur HTTP intermédiaire Ah2, les données témoins volumineuses précitées VCBWAhi sous forme d'une même pluralité de n premiers témoins élémentaires. Chaque premier témoin élémentaire est bien entendu associé conjointement au navigateur WEB WB.

A l'étape C de la figure 2b, l'opération de sauvegarde est notée [VCBWAhI] Sauvegarde-4c L l Dans la relation précédente, [C1jB\Ah2 i désigne la pluralité de n premiers témoins élémentaires, chaque témoin élémentaire étant noté CljBwAh2.

Lors de cette étape de sauvegarde, les premiers témoins élémentaires précités de la pluralité de n premiers témoins élémentaires sont sauvegardés au niveau du serveur HTTP Ah2 jouant le rôle de serveur HTTP intermédiaire.

L'étape de sauvegarde C est alors suivie d'une étape D consistant à rediriger la requête d'accès à l'application demandée Ax par le navigateur WEB BW vers le deuxième serveur HTTP Bh2 par l'intermédiaire du navigateur précité.

L'opération de redirection à l'étape D de la figure 2b est notée [Ah2, DN21 Re[Ax_>[Bh2, DN2].

Dans la relation précédente, DN2 désigne le nom de domaine commun foo.com dans l'exemple précédemment indiqué au serveur HTTP Ah2 et au deuxième serveur HTTP Bh2 des diffuseurs d'accès DI et D2.

Suite à l'étape de redirection D précitée, le procédé objet de l'invention consiste en une étape E à récupérer séquentiellement, par duplication des n premiers témoins élémentaires au niveau du deuxième serveur HTTF', c'est-à-dire le serveur Bh2 précité, une même pluralité de n deuxième témoins élémentaires.

A l'étape E de la figure 2b, l'opération de récupération séquentielle est representée par la relation [CI;Bwahz]'=; -[C2kBWBh2]k=I.

Dans la relation précédente, la pluralité de n deuxième témoin élémentaire k=n est notée C2kBWBh2 k=I.

- 12 - On comprend bien entendu que l'étape de redirection à l'étape D puis de récupération séquentielle à l'étape E par le deuxième serveur HTTP Bh2 est effectuée par l'intermédiaire du navigateur BW et, bien entendu, du terminal client incorporant ce dernier par transmission de messages successifs entre le serveur HTTP intermédiaire Ah2, le navigateur WEB WB et le terminal client hébergeant ce dernier et le deuxième serveur HTTP Bh2 précité, ainsi qu'il sera décrit ultérieurement dans la description.

L'étape E est alors suivie d'une étape F consistant à reconstruire, à partir de la même pluralité des n deuxièmes témoins élémentaires, les données témoins volumineuses notées VCBWBh2 lesquelles sont bien entendu identiques aux données témoins volumineuses VCBWph1, mais maintenant gérées par le deuxième serveur HTTP vis-à-vis du navigateur WEB BW.

D'une manière générale, on indique que l'étape Ao de création de répertoires virtuels est une étape indépendante. On conçoit en particulier que les répertoires virtuels précités peuvent être configurés sur tout serveur HTTP connecté à un réseau d'entreprise par exemple, réseau d'entreprises Br et/ou Ar de chacun des diffuseurs d'accès D2 et DI précédemment mentionnés. Les répertoires virtuels précités peuvent correspondre à une zone mémoire dédiée à accès protégé ainsi qu'il sera décrit ultérieurement dans la description.

Une variante de mise en oeuvre préférentielle du procédé objet de la présente invention sera maintenant décrite en liaison avec la figure 2c.

Dans la variante précitée, on indique que l'étape Ao consistant à créer des répertoires virtuels est consécutive à l'étape D constituant à rediriger la requête d'accès à l'application demandée par le navigateur WEB BW vers le deuxième serveur HTTP.

Ainsi, sur la figure 2c, l'étape A comporte uniquement la réception de la requête d'accès Re[Ax] par le premier serveur HTTP Ahi. Les étapes B et C de la figure 2c sont identiques aux étapes correspondantes de la figure 2b.

L'étape D de la figure 2c de redirection est alors constituée par une sous étape Do constituant l'opération de redirection proprement dite, qui correspond à - 13 - l'étape D de la figure 2b, la sous étape Do étant alors suivie d'une sous étape D, consistant en la création proprement dite des répertoires virtuels précités c'est-à-dire en l'exécution de l'étape Ao de la figure 2b.

On comprend toutefois que la création des répertoires virtuels à l'étape Dl de la figure 2c est alors dédiée à la requête d'accès Re[Ax].

En particulier, on comprend que dans le mode de mise en oeuvre de la figure 2c, le nombre de répertoires virtuels créés, c'est-à-dire finalement le nombre n, peut être dédié et directement lié à la taille des données témoins volumineuses VCBWAhI gérées par le premier serveur HTTP et le navigateur VW auteur de la requête d'accès Re[Ax].

Bien entendu, le nombre n peut être assujetti à une limite correspondant au nombre maximum de témoins élémentaires ou "cookie" n=20 associé à chaque nom de domaine et de ressources correspondante.

Le mode de mise en oeuvre du procédé objet de la présente invention tel que représenté en figure 2c présente alors une plus grande souplesse d'implémentation pour la raison précitée et d'évolution dans le cas où le nombre maximum de témoins élémentaires est susceptible d'évolution.

L'étape D représentée à la figure 2c est bien entendu suivie des étapes E et F identiques à celles représentées en figure 2b, étape de récupération séquentielle et de reconstruction.

Une description plus détaillée d'une mise en oeuvre non limitative des étapes B et D de redirection des figures 2b ou 2c sera maintenant donnée en liaison avec la figure 3.

En liaison avec la figure précitée, on indique que l'étape de redirection de la requête d'accès Re[Ax] consiste, suite à la réception de la requête d'accès par le premier serveur HTTP, le cas échéant, par le serveur HTTP intermédiaire, à transmettre en une étape B, ou D', vers le navigateur WEB et le terminal client utilisateur correspondant, un message de requête d'authentification et sur réponse du navigateur WEB et du terminal client utilisateur et authentification réussie de ce dernier, transmettre au navigateur WEB BW un message de redirection en une étape - 14 - B2 ou D2 du premier serveur HTTP Ah, respectivement du serveur HTTP intermédiaire Ah2, vers le serveur HTTP intermédiaire Ah2 respectivement le deuxième serveur HTTP Bh2.

Sur la figure 3, l'opération de transmission du message d'authentification est notée [Ahy, DNp] maut(AUT) > BW CAUT = vraie?+ (CAUT) Dans la relation précédente, maut(AUT) désigne le message de requête d'authentification transmettant une valeur d'authentification AUT, par exemple, vers le terminal ou navigateur WEB BW et la transmission d'une valeur chiffrée d'authentification notée CAUT vers le premier serveur HTTP, respectivement le serveur intermédiaire permettant la vérification à la valeur vraie de cette valeur chiffrée.

Dans cette relation, Ahy désigne soit le premier serveur HTTP soit le serveur HTTP intermédiaire Ah2.

L'opération de transmission du message de redirection proprement dit à l'étape B2 ou D2 de la figure 3 est notée par la relation [Ahy, DNp] mred(Re[Ax], Ah2, DNq) > BW correspondante.

Dans la relation précédente, DNp désigne le nom de domaine attribué au serveur HTTP premier serveur Ahl respectivement du nom de domaine duserveur intermédiaire Ah2, mred(Re[Ax],Ahz,DNq) désigne le message de redirection de la requête d'accès, Ahz désignant le serveur HTTP vers lequel est redirigée la requête d'accès, c'est-à-dire soit le serveur intermédiaire Ah2, soit au contraire, le deuxième serveur HTTP Bh2, DNq désigne le nom de domaine attribué au serveur HTTP vers lequel la requête d'accès a été redirigée.

Le processus de redirection représenté à la figure 3 n'est pas limitatif et d'autres processus plus élaborés ou simplifiés peuvent, le cas échéant, être mis en oeuvre.

Une description plus détaillée des étapes permettant la mise en oeuvre de l'étape C de sauvegarde représentée en figure 2b ou 2c sera maintenant donnée en liaison avec la figure 4.

Au départ, de la mise en oeuvre de la procédure de sauvegarde précitée, on dispose des données témoins volumineuses VCBWAh,.

Pour la mise en oeuvre de l'étape C précitée, le processus correspondant pour assurer l'étape de sauvegarde peut consister en une étape Cl de segmentation consistant à convertir les données témoins volumineuses précitées en une même pluralité de n chaînes de caractères élémentaires. Cette opération conduite sous l'autorité du serveur HTTP intermédiaire, c'est-à-dire le serveur Ah2 de la figure 2a, est représenté par la relation segmentation i=n VCBWAhl Si =, Dans la relation précédente, $Si désigne chaque chaîne de caractère élémentaire considéré et [$S;} désigne la pluralité de ri chaînes de caractères élémentaires précitées.

L'étape C, est alors suivie d'une étape C2 d'association exécutée sous le contrôle du serveur HTTP intermédiaire, cette étape consistant à associer la pluralité de n premiers témoins élémentaires au navigateur WEB. A chaque premier témoins élémentaires de rang j est allouée une chaîne de caractères de rang j correspondant, le nom de domaine commun au serveur HTTP intermédiaire et au deuxième serveur HTTP, c'est à dire le nom de domaine DN2 correspondant à l'exemple donné foo.com et un chemin d'accès spécifique au serveur HTTP intermédiaire, ce chemin d'accès étant désigné PAh2 sur la figure 4.

La relation d'association correspondante est notée [$S'ijii ASAnz >.}C1,}i = [CijBwAh2($Sj),DN2, PAh2Jj, Dans la relation précédente, {Clj}; désigne l'ensemble des premiers témoins élémentaires selon une expression réduite, CljBWAh2($Sj) désigne chacun des témoins élémentaires auquel est affectée une chaîne de caractère $Si obtenue à l'étape CI précédente, DN2 désigne le nom de domaine du serveur HTTP intermédiaire, et - PA112 désigne le chemin d'accès spécifique au serveur HTTP intermédiaire précité.

L'étape C2 d'association précitée est alors suivie d'une étape C3 d'association exécutée sous le contrôle du serveur HTTP intermédiaire Ah2, cette opération consistant à associer une même pluralité de n pseudodeuxième témoins élémentaires et allouer une chaîne de caractères vides, le nom de domaine commun au serveur HTTP intermédiaire et au deuxième serveur HTTP, c'est-à-dire le nom de domaine DN2 correspondant au nom de domaine foo.com et un chemin d'accès spécifique au deuxième serveur HTTP le chemin PB}i2.

L'opération d'association à l'étape C3 de la figure 4 d'une même pluralité de n pseudo-témoins élémentaires est représentée par la relation [$nkn]k-1 ASAh2 >{PC2k}1 =[PC2kBWAh2($"k"),D]'.i2,PBh2]k k=n =1 Dans la relation précédente {PC2k}i désigne en notation réduite, l'ensemble de la pluralité de n pseudo-témoins élémentaires, [$"k"]k=; désigne la chaîne de caractères vide affectée à chacun des pseudo-deuxièmes témoins élémentaires, noté chacun PC2kBwAh2($"k") . Une description plus détaillée de l'étape E de récupération séquentielle et de l'étape F de reconstruction exécutée suite à l'étape D de redirection de la requête d'accès du navigateur WEB BW vers le deuxième serveur HTTP Bh2 sera maintenant donnée en liaison avec la figure 5.

L'étape de récupération séquentielle E peut comprendre avantageusement une étape El de duplication de la chaîne de caractères élémentaire d'un premier témoin élémentaire C1 dans la chaîne de caractères vide d'un pseudo-deuxième témoin élémentaire PC2k pour engendre un deuxième témoin élémentaire C2k correspondant.

L'opération correspondante de duplication est donnée à l'étape E1 de la figure 5 selon la relation n C11 1 ->{C2k}l = [C2kBWBh2($Sk), DN2, P13h2] kk=n = {PC2k}l Dans la relation précédente, les entités désignées correspondent à la désignation des premiers témoins élémentaires et des pseudo-deuxièmes témoins élémentaires sous forme réduite pour engendrer les deuxièmes témoins élémentaires dans lesquels {C2k}l désigne les deuxièmes témoins élémentaires sous forme réduite chaque deuxième témoin élémentaire étant noté C2k; C2kBwB2($Sk) désigne chaque deuxième témoin élémentaire auquel a été affecté la chaîne de caractères $Sk; DN2 désigne le nom de domaine du deuxième serveur HTTP 131,2; PBh2 désigne le chemin d'accès spécifique à ce deuxième serveur.

L'étape E1 précitée est alors suivie d'une étape E2 d'insertion/transmission du deuxième témoin élémentaire C2k dans l'entête HTTP du message de requête d'accès à l'application redirigée vers le deuxième serveur HTTP, le serveur Bh2.

L'opération E2 est suivie d'une opération E3 de stockage par le deuxième serveur HTTP du deuxième témoin élémentaire C2k et de la chaîne de caractères contenue dans ce dernier $Sk.

Les étapes E1, E2, E3 sont répétées tant que la valeur de l'indice k repérant chaque deuxième témoin élémentaire n'atteint pas la valeur maximale K ceci afin de récupérer la totalité des deuxièmes témoins élémentaires par duplication à partir des premiers.

Pour k=K lorsque tous les deuxièmes témoins élémentaires ont été récupérés et stockés, chacun affecté de sa chaîne de caractères $Sk, l'étape F est alors exécutée pour reconstruire les données témoins volumineuses. Cette étape peut comprendre la concaténation de l'ensemble des chaînes de caractères contenues dans chacun des deuxièmes témoins élémentaires stockés par le deuxième serveur HTTP.

L'opération de reconstruction est ainsi représentée symboliquement par la relation k=n VCBWBh2 E $Sk k=l On comprend bien entendu que l'opération de sommation sur les chaînes de caractères élémentaires $Sk représente symboliquement l'opération de concaténation.

Un mode de mise en oeuvre spécifique non limitatif explicité à titre d'exemple du processus utilisé pour exécuter la segmentation des données témoins volumineuses de l'étape C, de la figure 4 sera explicitée en liaison avec la figure 6.

Le mode de réalisation correspondant permet d'introduire une sécurité dans le traitement de segmentation mais d'autres étapes de traitement peuvent être prévues de manière non limitative.

Ainsi, à titre d'exemple, on considère sur la figure 6 que l'on dispose des données témoins volumineuses VCBWAh,, du nombre n de répertoires virtuels, et, bien sûr, de premiers témoins élémentaires de pseudodeuxièmes témoins élémentaires et de deuxièmes témoins élémentaires susceptibles d'être créées.

Ainsi, à partir des données précités, le processus de segmentation peut consister en une étape C à transformer les données témoins volumineuses précitées en une chaîne de caractères de départ notée $So.

La taille de chaque chaîne de caractères élémentaire, c'est-à-dire sensiblement 4ko pour chaque témoin élémentaire, est donné par la valeur LSi précitée. L'étape C est alors suivie d'une étape Cu consistant à comparer, par comparaison d'infériorité par exemple, la taille de la chaîne de caractères de départ $So à une valeur de seuil. Cette valeur de seuil est notée T=n*LSi, produit du nombre n de chaînes de caractères élémentaires et de répertoires virtuels et de la taille maximum LSi de la chaîne de caractères allouée à chaque premier témoin élémentaire, soit dans l'exemple donné LSi=4ko.

Sur réponse positive au test de comparaison réalisé à l'étape C12, la chaîne de caractères de départ $So n'excède pas la valeur de seuil et l'on procède à une étape C13 à la division de la chaîne de caractères de départ en n chaînes de caractères élémentaires, notées pour cette raison [$Stn.

Au contraire, sur réponse négative au test C12, la chaîne de caractères excède la valeur de seuil précitée. Dans ce cas-là, on appelle une étape C14 de suspension du processus d'accès commun et l'on renvoie le navigateur WEB et le terminal client utilisateur vers une page d'accueil du serveur HTTP intermédiaire Ah2.

Différentes indications d'ordre général seront maintenant données relativement à la mise en oeuvre du procédé objet de la présente invention.

Pour ce qui concerne la constitution des premiers témoins élémentaires, c'est-à-dire des premiers "cookies" respectivement des deuxièmes témoins élémentaires, deuxième cookies, le cas échéant des deuxièmes pseudotémoins élémentaires, deuxième pseudo-cookies, on indique que la durée d'expiration affectée à chacun d'eux importe peu. A titre d'exemple non limitatif, cette durée d'expiration peut être prise égale au temps courant plus une durée arbitraire d'une heure, par exemple.

Lors de la mise en oeuvre de l'étape de récupération séquentielle E des figures 2b ou 2c, et en particulier de l'étape de duplication E1 et d'insertion transmission E2 de la figure 5, la redirection du message (le requête d'application transmis par le navigateur WEB BW vers une URL servie par le deuxième serveur HTTP sur le chemin PBh2, permet à ce dernier de récupérer le deuxième témoin élémentaire C2kWB112($Sk) au niveau du serveur Bh2. Ce dernier récupère alors la valeur du deuxième témoin élémentaire correspondant et stocke la valeur de sa chaîne de caractères $Sk. On comprend, bien entendu, que chaque deuxième témoin élémentaire auquel est associé le même nom de domaine DN2, pris dans l'exemple égal à foo.com, peut alors être lu par le deuxième serveur HTTP, ainsi que décrit précédemment dans la description.

- 20 - Une description plus détaillée d'un serveur HTTP permettant la mise en oeuvre du procédé objet de la présente invention sera maintenant donnée en liaison avec la figure 7.

D'une manière générale, pour la mise en oeuvre du procédé objet de la présente invention, on indique que tout serveur HTTP est avantageusement configuré de manière à jouer le rôle non seulement d'un premier serveur HTTP, le serveur Ahl, précédemment décrit dans la description, mais également celui d'un serveur HTTP intermédiaire, le serveur Ah2, et/ou celui du deuxième serveur HTTP le serveur Bh2 précité.

On comprend bien sûr, dans ces conditions, que les fonctions mises en oeuvre par chaque serveur pour réaliser et jouer le rôle des trois serveurs précités sont alors sensiblement indépendantes.

Dans ces conditions, ainsi que représenté en figure 7, un serveur HTTP conforme à l'objet de la présente invention désigné AB1 comporte, de manière classique, des organes d'entrée sortie I/O, une unité de traitement CPU, une mémoire de travail RAM et des mémoires de programmes distinctes, désignées de manière générale par PROG. Enfin, une unité de mémoire de masse peut être prévue, telle qu'une unité à disque dur HDD, par exemple.

Ainsi que représenté sur la figure 7, un serveur HTTP conforme à l'objet de la présente invention, comporte avantageusement un module M1 de configuration d'une pluralité de n répertoires virtuels.

A titre d'exemple non limitatif, les répertoires virtuels précités sont notés DZ[DZ;1. Les répertoires virtuels précités définissent le répertoire commun DZ, l'ensemble pouvant être à accès protégé en écriture et/ou en lecture. Les paramètres de définition des répertoires virtuels précités sont donnés par n égal par exemple à LSo/LS; 0 où LS0 désigne la longueur de la chaîne de caractères de départ par exemple, LS; 0 désigne la longueur de chaque chaîne de caractères élémentaire, tel que décrit précédemment. Cette longueur peut être prise égale à 4ko. Arbitrairement, la valeur de n peut être fixée à n=20. -21 -

En outre, ainsi que représenté en figure 7, un serveur HTTP conforme à l'objet de la présente invention comporte un module M2 de sauvegarde de données témoins volumineuses sous forme d'une pluralité de n témoins élémentaires ainsi que décrit en liaison avec la figure 4 pour la mise en oeuvre de l'étape C des figures 2b et 2c.

Enfin, un serveur HTTP objet de l'invention comprend également un module M31 de récupération séquentielle par duplication d'une pluralité de n témoins élémentaires, ainsi que décrit à la figure 5, et un module M32 de reconstruction, à partir des n témoins élémentaires récupérés, de données témoins volumineuses ainsi que décrit également à la figure 5. Enfin, dans le cadre de la mise en oeuvre du procédé objet de l'invention par un serveur HTTP correspondant, le nombre n de répertoires virtuels et de témoins élémentaires peut être pris égal au rapport de la taille d'une chaîne de caractères LS0, la chaîne de caractères de départ représentative des données témoins volumineuses, et de la taille de la chaîne de caractères élémentaires contenue dans chaque témoin élémentaire.

Les exemples de mise en oeuvre du procédé et du serveur HTTP objet de la présente invention ne sont pas limitatifs, en particulier pour ce qui concerne l'exécution du processus de segmentation décrit en figure 6. La conversion des données témoins volumineuses en chaîne de caractère de départ peut être réalisée grâce à des techniques connues de compression lesquelles, pour cette raison, ne seront pas décrites en détail. D'une manière générale, on considère qu'une telle transformation ou conversion consiste à considérer dans ces conditions que l'opération C13 de segmentation proprement dite est alors appliquée sur la chaîne de caractères compressée $S'o en lieu et place de la chaîne de caractères de départ.

Lorsqu'une opération de codage telle que décrite précédemment et de compression sont utilisées pour assurer la subdivision de la chaîne de caractères de départ, le cas échéant, la chaîne de caractères compressée ainsi que décrit en liaison avec la figure 6, les opérations inverses correspondantes sont appliquées lors de l'opération de reconstruction F, c'est-à-dire opération de décompression puis de - 22 - codage inverse pour reconstituer les données témoins volumineuses VCBWAI identiques aux données témoins volumineuses VCBWAhI de départ. -23 -

Claims (10)

REVENDICATIONS

1. Procédé d'accès commun par partage à des données témoins volumineuses, par un premier et un deuxième serveur HTTP implantés sur des sites WEB et des réseaux distincts et appartenant à des domaines distincts, lesdites données témoins volumineuses étant associées à un navigateur WEB équipant un terminal client utilisateur sous le contrôle dudit premier serveur HTTP, caractérisé en ce qu'il consiste au moins à : a) configurer sur ledit deuxième serveur HTTP une pluralité de n répertoires virtuels représentatifs d'un répertoire commun; et, sur requête d'accès à une application transmise dudit navigateur WEB vers ledit premier serveur HTTP; b) rediriger ladite requête d'accès à ladite application vers un serveur HTTP intermédiaire distributeur de ladite application appartenant au réseau dudit premier serveur HTTP mais appartenant au domaine dudit deuxième serveur HTTP; c) sauvegarder, sous le contrôle dudit serveur HTTP intermédiaire, lesdites données témoins volumineuses sous forme d'une même pluralité de n premiers témoins élémentaires, un premier témoin élémentaire parmi ladite pluralité de n premiers témoins élémentaires étant associé conjointement audit navigateur WEB; d) rediriger ladite requête d'accès à cette application dudit navigateur WEB vers ledit deuxième serveur HTTP; e) récupérer séquentiellement, par duplication de la pluralité de n premiers témoins élémentaires, au niveau dudit deuxième serveur HTTP, une même pluralité de n deuxièmes témoins élémentaires; f) reconstruire, à partir de ladite même pluralité de n deuxièmes témoins élémentaires lesdites données témoins volumineuses.

2. Procédé selon la revendication 1, caractérisé en ce que l'étape a) est une étape indépendante préalable. 25

3. Procédé selon la revendication 1, caractérisé en ce que l'étape a) est consécutive à l'étape d) consistant à rediriger ladite requête d'accès à cette application dudit navigateur WEB vers ledit deuxième serveur HTTP.

4. Procédé selon l'une des revendications 1 à 3, caractérisé en ce que l'étape b) de redirection de ladite requête d'accès consiste, suite à la réception de ladite requête d'accès par ledit premier serveur HTTP, à : b1) transmettre vers ledit navigateur WEB et ledit terminal client utilisateur un message de requête d'authentification, et, sur réponse dudit navigateur WEB et dudit terminal client utilisateur et authentification réussie de ce dernier; b2) transmettre dudit premier serveur HTTP vers ledit navigateur WEB et ledit terminal client utilisateur un message de redirection de ladite requête d'accès comportant au moins l'adresse dudit serveur HTTP intermédiaire.

5. Procédé selon l'une des revendications 1 à 4, caractérisé en ce que ladite étape c) consistant à sauvegarder, sous le contrôle dudit serveur HTTP intermédiaire lesdites données témoins volumineuses comprend au moins les étapes consistant à : cl) convertir lesdites données témoins volumineuses en une même pluralité de n chaînes de caractères élémentaires; c2) associer, sous le contrôle dudit serveur HTTP intermédiaire ladite pluralité de n premiers témoins élémentaires audit navigateur WEB, à un premier témoin élémentaire de rang j étant allouée une chaîne de caractères de rang j correspondant, le nom de domaine commun audit serveur HTTP intermédiaire et audit deuxième serveur HTTP, et un chemin d'accès spécifique audit serveur HTTP intermédiaire; c3) associer, sous le contrôle dudit serveur HTTP intermédiaire, une même pluralité de n pseudo deuxièmes témoins élémentaires audit navigateur WEB, à un desdits pseudo deuxièmes témoins élémentaires de rang k étant allouée une chaîne de caractère vide, le nom de domaine commun audit serveur HTTP intermédiaire et audit deuxième serveur HTTP et un chemin d'accès spécifique audit deuxième serveur HTTP.

- 25 -

6. Procédé selon les revendications 1, 4 et 5, caractérisé en ce que, suite à l'exécution de l'étape d) de redirection de ladite requête d'accès dudit navigateur WEB vers ledit deuxième serveur HTTP, ladite étape e) consistant à récupérer séquentiellement au niveau dudit deuxième serveur HTTP ladite même pluralité de n deuxièmes témoins élémentaires comprend: el) la duplication de la chaîne de caractères élémentaire d'un premier témoin élémentaire de rang j dans la chaîne de caractères vide d'un pseudo deuxième témoin élémentaire de rang k pour engendrer un deuxième témoin élémentaire de rang k correspondant; e2) l'insertion dudit deuxième témoin élémentaire de rang k dans l'en-tête HTTP du message de requête d'accès à ladite application redirigé vers ledit deuxième serveur HTTP; e3) le stockage, par ledit deuxième serveur HTTP, dudit deuxième témoin élémentaire de rang k et de la chaîne de caractères contenue dans ce dernier; e4) la répétition des étapes el), e2), e3) pour tous les deuxièmes témoins élémentaires.

7. Serveur HTTP pour la mise en oeuvre du procédé selon l'une des revendications 1 à 6 précédentes, caractérisé en ce qu'il comporte au moins des moyens de configuration d'une pluralité de n répertoires virtuels.

8. Serveur HTTP pour la mise en oeuvre du procédé selon l'une des revendications 1 à 6 précédentes, caractérisé en ce qu'il comporte des moyens de sauvegarde de données témoins volumineuses sous forme d'une pluralité de n témoins élémentaires, un témoin élémentaire étant associé conjointement à un navigateur WEB d'un terminal client utilisateur.

9. Serveur HTTP pour la mise en oeuvre du procédé selon l'une des revendications 1 à 6 précédentes, caractérisé en ce qu'il comporte: des moyens de récupération séquentielle, par duplication, d'une pluralité de n témoins élémentaires, et des moyens de reconstruction, à partir desdits n témoins élémentaires, de données témoins volumineuses.

- 26 -

10. Serveur HTTP selon l'une des revendications 7 à 9, caractérisé en ce que pour un témoin élémentaire comportant une chaîne de caractères élémentaire, le nombre n de répertoires virtuels et de témoins élémentaires est égal au rapport de la taille d'une chaîne de caractères représentative de données témoins volumineuses et de la taille de la chaîne de caractères élémentaire contenue dans ledit témoin élémentaire.