Brevet FR2882833A1 — publié le 20060908

PROCEDE DE TRANSFORMATION D'UNE PAGE DYNAMIQUE La présente invention concerne un procédé de transformation d'une page dynamique destinée au téléchargement de cette page dynamique. Il existe des procédés de téléchargement de données textuelles entre un client comprenant un navigateur et un serveur dans lesquels les données sont compressées par le serveur avant envoi par le serveur puis décompressées par le client. Ceci présente l'inconvénient d'augmenter la charge du serveur, notamment l'utilisation du processeur pour effectuer une compression. Le client doit également avoir la capacité de décompresser les données reçues. Les données textuelles comprennent le plus souvent des données statiques et des données dynamiques Les données statiques sont des données envoyées telles quelles aux clients et insusceptibles de variation. Les données dynamiques sont des données qui sont exécutées par le serveur avant envoi et dont le résultat peut varier. Il est intéressant d'avoir une séparation dans un ensemble de données textuelles entre les données statiques et les données dynamiques au sein du serveur. Les données statiques et dynamiques peuvent alors être traitées séparément et leurs résultats respectifs peuvent être transportés séparément. Les données statiques peuvent ainsi être conservées compressées au sein du serveur. Cela évitera une éventuelle compression avant envoi, ce qui diminuera la charge du processeur du serveur. Enfin, elles pourront être conservées dans une mémoire cache du serveur ce qui diminuera les temps de réponse à des demandes de divers clients. Les données dynamiques résultat seront exécutées par le serveur sur demande puis envoyées au client éventuellement indépendamment des données statiques. Une telle séparation entre les données statiques et les données dynamiques existe dans l'état de la technique. En effet, les sites en technologie XML/XSL sont conçus et mis en ligne avec cette séparation déjà opérée. Les données statiques sont donc séparées des données dynamiques. Les données sont au format XML et une feuille de style XSL permet de générer une page en puisant dans les données. Cette génération de page, c'est-à-dire l'exécution de la feuille de style XSL, peut s'effectuer soit au niveau du serveur soit au niveau du client si celui-ci comporte un moteur XML/XSL. Il convient de s'intéresser uniquement à la génération sur le client, configuration qui comporte le plus d'avantages en terme de flux réseau et seule proche du logiciel à protéger. Le site doit donc être conçu en XML/XSL. Ceci limite le choix d'outils de création de page qui sont moins nombreux que pour les sites en technologie de pages 1\HIRSCH6\BREVETS\Brcvets\23300\2339 I.doc - 2 mars 2005 - 1/8 dynamiques (JSP, ASP ou PHP). Le fait que la génération du HTML se fasse sur le Poste de Travail, donc loin des données, rend la conception plus complexe. En outre, le navigateur qui aura téléchargé ces données devra être compatible avec la technologie XML/XSL. Ainsi, Internet Explorer de Microsoft ne supporte le XML/XSL qu'à partir de sa version 5, avec des différences par rapport à la norme officielle du W3C. Firefox de la Fondation Mozilla se base, lui, sur la norme officielle. Opera de Opera Software ne supporte pas cette technologie en janvier 2005. Il existe des moyens d'identification des données statiques et des données dynamiques mais la présente invention permet d'effectuer une séparation entre ces données à partir de données textuelles d'un serveur déjà développé afin de les envoyer à un client. Elle peut être mise en oeuvre quel que soit le langage des données textuelles. Ceci permet une optimisation du flux de données lors d'un envoi. La présente invention permet ainsi à un navigateur quelconque de reconstruire les données séparées au niveau du serveur, et ce quel que soit les données textuelles. Elle permet également d'améliorer le téléchargement de données entre un serveur et un client. Par ailleurs, il est possible d'utiliser des technologies de script pour demander une page à un programme s'exécutant localement au navigateur. En effet, lorsqu'un site veut que le téléchargement d'une page HTML ne s'effectue pas par le navigateur, mais par un programme dédié, il ne met pas, derrière un lien ou un bouton, un changement de page qui entraînera un téléchargement par le navigateur, mais ce site est construit de la manière suivante: la page actuelle comporte un programme téléchargé, en général en technologie Java Applet ou Microsoft ActiveX, capable d'effectuer les téléchargements; un clic sur un lien entraîne l'appel d'une fonction de script, en général JavaScript; cette fonction de script appelle une méthode du programme téléchargé ; le programme téléchargé télécharge les données nécessaires et construit les nouvelles données HTML. Enfin, le script modifie la page avec les nouvelles données HTML. Néanmoins, la technologie de script utilisée dépend du navigateur, Microsoft Interner Explorer ou Mozilla Firefox par exemple. Les scripts devront donc être modifiés en fonction de chaque navigateur. La présente invention permet de demander une page à un programme s'exécutant localement au navigateur sans ces inconvénients. Le procédé de la présente invention prévoit ainsi la transformation d'une page dynamique destinée au téléchargement de cette page dynamique comprenant les étapes d'identification dans la page dynamique de segments de données statiques et du code dynamique et de création de fichiers de segments statiques contenant les üHIRSC1-16\BREVETS\Brevets\ 23300\23391. doc - 2 mars 2005 - 218 segments statiques et leur identifiant, et de remplacement dans la page dynamique des segments statiques par leur lien respectifs. Le procédé de la présente invention prévoit dans une autre réalisation le téléchargement depuis un serveur et d'exécution au sein d'un navigateur d'un serveur Web jouant le rôle d'un proxy local et interceptant les communications entre le navigateur et le serveur. Le procédé de téléchargement peut également comprendre une ou plusieurs des caractéristiques suivantes: - le serveur Web est utilisé pour recomposer des données textuelles, - le serveur Web est utilisé pour décompresser des flux gzip au client, - le serveur Web est utilisé comme moteur de fusion XML/XSL devant un navigateur qui ne la possède pas, - le serveur Web est utilisé pour rediriger des requêtes HTTPS vers un serveur moins sécurisé en fonction du contenu demandé. - le serveur Web modifie les liens contenus dans les flux le traversant pour continuer à intercepter Ies requêtes entre le client et le serveur. D'autres caractéristiques et avantages de l'invention apparaîtront à la lecture de la description détaillée qui suit et des modes de réalisation de l'invention, donnés à titre d'exemple uniquement et en référence aux dessins qui montrent: - figure 1, schéma d'un procédé de transformation d'une page dynamique selon la présente invention - figure 2, schéma d'un procédé de téléchargement et de recomposition de page selon la présente invention - figure 3, schéma d'un procédé de téléchargement et de décompression de page selon la présente invention -figure 4, schéma d'un procédé de téléchargement et de redirection de requêtes selon la présente invention - figure 5, schéma d'initialisation d'une communication optimisée selon la présente invention - figure 6, schéma de déroulement d'une requête optimisée. La figure 1 représente un schéma selon la présente invention d'un procédé de transformation d'une page dynamique destinée au téléchargement de cette page dynamique comprenant les étapes d'identification dans la page dynamique de segments de données statiques et du code dynamique; de création de fichiers de segments statiques contenant les segments statiques et leur identifiant; de remplacement dans la page dynamique des segments statiques par leur lien respectifs. \HIRSCH6\BREVETS\Brevets\23300\23391doc - 2 mars 2005 - 3/8 L'identification des données statiques des données dynamiques est effectuée par la reconnaissance de balises dans la page dynamique. Les balises appartenant au code dynamique sont exécutées sur le serveur lorsque le navigateur demande le résultat de l'exécution de la page, alors que les segments statiques sont renvoyés directement au client. Le présent mode de réalisation peut être appliqué à une optimisation des flux d'un serveur utilisant la technologie Java JSP/Servlet. Les balises correspondant à du code dynamique sont reconnues par leur forme pouvant être, par exemple, au lieu de pour les pages jsp. Pour les pages jsp, leur préfixe XML désigne un ensemble de balises déclarées et reconnues comme dynamiques par le site (par exemple: ... ). Il convient néanmoins de remarquer que certaines balises correspondant à du code dynamique utilisent leur contenu. En outre, certains segments statiques ne sont pas extractibles du fait qu'ils sont utilisés par une balise dynamique les contenant. Ces balises dynamiques doivent donc être identifiées et listées par avance, pendant une phase de configuration de la séparation. Un segment de données peut être défini comme un sous-ensemble contigu de la page dynamique; c'est un sous-ensemble de données successives. Un lien comprend un identifiant de segment et un nom de fichier de segments. Concernant la mise en oeuvre de cette invention d'optimisation des flux, l'ajout d'un filtre Serveur est utile. Celui-ci a pour fonction de reconnaître le Module Client et lui envoyer les pages sous forme optimisées. Le filtre Serveur peut également compresser les données. Enfin, il peut gérer le cache des données statiques sous foiine compressée. Par exemple, pour les sites développés en technologie servlet/JSP, l'ajout du Filtre Serveur s'effectue en modifiant le fichier de configuration du site et en ajoutant un filtre, tel que décrit dans la norme servlet 2.3 (et plus), et en dirigeant sur ce filtre la totalité des requêtes reçues par le site. La figure 5 représente la phase d'initialisation d'une communication optimisée selon la présente invention. Les étapes sont les suivantes. D'abord, le navigateur demande une page (page1.htm). Puis le Filtre Serveur reconnaît cette requête et initialise le passage en mode optimisé. Concernant cette étape, la reconnaissance d'une requête comme entraînant cette procédure peut être le nom de la page demandée, ou un ou des paramètres HTTP de la requête. Ensuite le Module Client est envoyé au navigateur. Dans cette étape, le Filtre Serveur envoie deux cadres, l'un étant invisible et contenant le Module Client, l'autre visible. Ce dernier cadre est soit vide soit contient un message d'attente. Concernant cette même étape, le Module Client est programmé dans une technologie lui permettant de s'exécuter au sein même du navigateur (Applet Java, Contrôle ActiveX, ...). L'étape suivante concerne l'initialisation du Module Client selon la procédure qui suit: le Module Client \\HIRSCH6\BREVETS\Brevets\23300\23391.doc - 2 mars 2005 - 4/8 télécharge ses propres paramètres d'initialisation en provenance du Filtre Serveur puis il démarre son Serveur Web local. L'étape suivante concerne la modification par le Module Client de l'adresse du cadre visible. La nouvelle adresse qui en résulte est une demande de page du serveur, qui pointe alors sur le serveur local du Module Client. L'interception des requêtes est ainsi mise en place. Il en résulte une requête optimisée. La figure 6 représente la phase de déroulement d'une requête optimisée selon la présente invention. Cette phase comprend les étapes suivantes. D'abord, le navigateur doit télécharger des données en mode optimisé lorsque l'adresse du cadre visible du navigateur a été modifiée, en raison de l'initialisation du Module Client ou d'un clic de l'utilisateur dans une page optimisée, ou lorsque la page qui vient d'être téléchargée de manière optimisée contient des liens vers des ressources (images, fichiers de scripts, feuilles de style par exemple). L'adresse liée à ces données ne pointe pas directement vers le serveur, mais vers le Module Client. Ensuite, le navigateur demande les données au Module Client. Puis, celui-ci demande ces données au serveur avec l'indication provenant du Module Client . Le Filtre Serveur intercepte la requête et la marque comme étant optimisée. Selon sa configuration et la nature de la requête, il peut reconnaître une demande de fichier statique et retourner une version compressée provenant de son cache, ou compresser ce fichier et le mettre dans le cache. Il peut également demander au serveur de traiter la requête puis renvoyer le résultat sous forme compressée, non cachée, ou non. Ensuite, si la requête est une demande de page qui a été préalablement optimisée, alors c'est la version optimisée de la page qui est générée car le Filtre Serveur a marqué la requête comme étant optimisée. A l'étape suivante, le Module Client reçoit les données sous forme optimisée et les traite. Le Module Client les décompresse si le navigateur ne sait pas le faire. S'il s'agit d'une demande de page optimisée, le Module Client télécharge, si nécessaire, les fichiers de segments et reconstitue la page telle qu'elle aurait été fournie par un serveur non optimisé. S'il s'agit d'une page, le Module Client modifie les liens qu'elle contient pointant sur le serveur afin qu'ils pointent sur le Module Client. En effet, l'étape précédente a permis de générer une page exactement identique à ce qu'elle aurait été sans l'optimisation du transport, c'est-à-dire avec des adresses pointant sur le serveur. Les requêtes suivantes seront donc convenablement interceptées par le Module Client. La présente invention permet également le téléchargement, de la même manière que les pages et les autres fichiers de ressource du Site Web (requête http GET), et l'exécution au sein d'un navigateur d'un serveur Web jouant le rôle de proxy local (dans le Module Client) et interceptant les communications entre le navigateur et le serveur. Ce proxy local peut être ajouté à un site existant par \\HIRSCH6\BREVETS\Brevets\23300\23391. doc - 2 mars 2005 - 5/8 l'utilisation d'un filtre serveur. Le Module Client n'utilise pas d'interface de script avec le navigateur, mais une interface http, beaucoup plus standard. Pour utiliser cette interface, il ouvre un serveur Web qui fait office de proxy local. De plus, pour s'assurer qu'il continue à recevoir les requêtes à la place du serveur initial, il modifie les liens des données textuelles avant de les retourner au navigateur pour que ces liens pointent maintenant sur son serveur Web local, comme décrit ci-dessous. La figure 2 représente cette technologie utilisée pour recomposer des données textuelles ayant par exemple été séparées par un procédé de transformation tel que décrit ci-dessus. Mais cette technologie peut également être utilisée pour ajouter la fonctionnalité de décompression de flux gzip au client tel que représenté sur la figure 3. Cette technologie peut aussi être utilisée pour ajouter la fonctionnalité de moteur de fusion XML/XSL devant un navigateur qui ne la possède pas. Elle peut en outre être utilisée pour ajouter la fonctionnalité de redirection des requêtes HTTPS vers des serveurs moins, ou pas, sécurisés en fonction du contenu demandé, ceci pour des raisons de performance serveur; cette fonctionnalité est représentée sur la figure 4. \\HIRSCH6\BREVETS\Brevets\23300\23391. doc - 2 mars 2005 - 6/8 REVENDICATION 1. Procédé de transformation d'une page dynamique destinée au téléchargement de cette page dynamique comprenant les étapes de: identification dans la page dynamique de segments de données statiques et du code dynamique - création de fichiers de segments statiques contenant les segments statiques et leur identifiant, et de - remplacement dans la page dynamique des segments statiques par leur lien respectifs. R:\Brevets\23300\23391--060206-rev unité d'invention.doc- 6 février 2006 1/l