FR 2924295 A1 20090529 FR 0759289 A 20071126 PROCEDE DE TRAITEMENT DE REQUETES HTTP PAR UN SERVEUR WEB HEBERGE DANS UN DISPOSITIF ELECTRONIQUE PORTABLE. La présente invention concerne un dispositif électronique portable, tel qu'une carte à puce, utilisé dans des terminaux fixes ou mobiles pour donner accès à des services ou des données de manière sécurisée, par un processus d'authentification de l'utilisateur/abonné du terminal. L'invention concerne plus particulièrement un dispositif électronique portable d'authentification hébergeant un serveur web, destiné à être utilisé dans un terminal internet, c'est à dire un terminal qui a les moyens nécessaires pour se connecter à internet, et un procédé de traitement par ce serveur web de requêtes http (Hyper Text Transfer Protocol) émises par le terminal, typiquement par un navigateur, pour transférer des ressources du dispositif électronique portable vers le terminal. Le format de ces requêtes http et de leurs réponses, qui régissent les échanges entre un serveur et un navigateur est décrit dans le document de référence RFC2616, intitulé Hypertext Transfer Protocol -HTTP/1.1, disponible auprès de l'IETF (Internet Engineering Task Force) notamment sur son site http://www.ietf.org. Par ressource, on entend généralement une entité informatique accessible indépendamment. Dans le contexte de l'invention, il s'agit notamment d'une page web, c'est à dire d'un document destiné à être consulté avec un navigateur, qui est constituée typiquement d'un document html (Hyper Text Mark-up Language), xml, xhtml..., c'est à dire du texte, et d'éventuelles ressources liées à ce document : des images (JPEG, PNG, GIF...), des scripts (JavaScript), des sons (MP3, Wav ...), des animations et qui peuvent être automatiquement exécutés ou affichés par le navigateur s'il a les interfaces correspondantes. Par serveur web embarqué sur une entité électronique portable, telle qu'une carte à puce, on entend un logiciel serveur http, c'est à dire un protocole défini par la référence RFC2616, qui permet d'accéder à un site web, c'est à dire un ensemble de pages ou autres ressources (sons, images, ...) embarquées sur la carte. Une session peut ainsi être ouverte entre un client, généralement le navigateur du terminal hôte et le serveur web embarqué, permettant un transport de données http de la carte vers le terminal hôte. En pratique la carte à puce est accessible localement par son terminal. Mais si elle possède une adresse publique (adresse IP routable sur Internet), elle peut être également accessible par un client distant. De manière générale, le dispositif électronique portable contient des informations de sécurité qui permettent d'authentifier l'utilisateur et lui donner accès à des services correspondants, ou de donner accès à des données sécurisées qu'il contient. Il peut contenir en outre des applications diverses. Par exemple, en téléphonie, la carte SIM contient des applications telles que des jeux, une messagerie électronique, des services multimédia... Dans le contexte de l'invention, le dispositif héberge en outre un site web en mémoire non volatile reprogrammable. Les terminaux internet sont devenus d'usage courant, qu'ils soient fixes ou mobiles. Ce sont des ordinateurs de bureau, fixes ou portables, des téléviseurs "multimédia" ou encore des terminaux mobiles type organisateur, 15 téléphone mobile, miniportable, console de jeux ou autres. Ils intègrent les ressources nécessaires à la navigation internet, et notamment un navigateur ("browser"), une pile TCP/IP... Dans ce contexte, un utilisateur peut utiliser différents terminaux internet dont il n'est pas toujours le propriétaire, c'est à dire que c'est la carte 20 qui va l'authentifier comme utilisateur ou abonné : le dispositif électronique portable connecté au terminal utilisé permet d'authentifier cet utilisateur mobile pour autoriser l'accès et/ou l'usage d'un ou plusieurs services par ce terminal. Dans le domaine de la téléphonie mobile par exemple, le dispositif 25 électronique portable est typiquement une carte à puce(s) dite carte USIM (Universal Subscriber Identity Module) ou plus simplement SIM, achetée par l'abonné. L'abonné place cette carte dans le téléphone mobile dans un logement prévu à cet effet. La carte peut alors assurer la gestion sécurisée de l'abonnement téléphonique sur ce téléphone, notamment par une 30 procédure d'authentification par un code (code PIN) propre à l'abonné. Il y a d'autres types d'applications, par exemple, le dossier médical personnalisé, qui utilise une carte à puce propre à un assuré social, contenant des données confidentielles propres à cet assuré : l'accès à tout ou partie des données confidentielles est permis par la carte de manière 35 sécurisée par un terminal d'un médecin, d'un pharmacien, d'un organisme de santé qui ont également leur carte propre qui les authentifie et détermine l'étendue de leurs droits d'accès aux données du dossier médical personnalisé. On assiste à une implémentation généralisée d'applications Web sur les terminaux y compris les terminaux mobiles, même bon marché, avec les ressources matérielles/logicielles propres à la navigation Web (navigateur, piles TCP/IP, ...), liée au développement du web et à l'évolution des technologies matérielles et logicielles, en sorte que l'interface utilisateur la plus largement répandue sur ces terminaux est un navigateur web. Les opérateurs de téléphonie l'ont bien compris, eux qui notamment utilisent cette interface utilisateur pour leur offre de services aux abonnés, par un site web correspondant. Il est apparu intéressant d'implémenter ce site web sur les dispositifs d'authentification eux même, permettant d'une part d'utiliser de manière sécurisée les données propres à l'abonné, et d'autre part de libérer le(s) réseau(x) de communication internet pour des accès à d'autres sites distants. C'est ainsi que l'on trouve sur le marché des cartes à puce(s) hébergeant un site web dans leur espace mémoire non volatile reprogrammable (EEPROM), avec un serveur web embarqué associé. Le site web contient en pratique une ou plusieurs pages web, avec du texte, des images, des sons, des scripts.... Il est consultable par le navigateur internet standard implémenté dans les terminaux internet, par sélection dans un menu déroulant par exemple. L'offre de services apparaît alors sur l'écran de ces terminaux internet, sous forme d'une page web, c'est à dire du texte seul ou avec des liens vers d'autres pages ou avec d'autres ressources : sons, images, scripts.... L'accès à ce site web utilise les ressources matérielles/logicielles prévues en standard sur le terminal internet : écran, clavier, souris, navigateur. En pratique le serveur embarqué, connu sous l'acronyme SCWS (pour Smart Card Web Server) n'a pas nécessairement une adresse IP, mais seulement une adresse locale pour le terminal connecté au dispositif électronique portable. L'architecture d'un système applicatif correspondant, c'est à dire le 35 terminal internet et son dispositif électronique portable d'authentification au serveur web, est largement répandue et connue. Cependant les fournisseurs de services rencontrent un problème pour généraliser ou développer ces sites Web implémentés en local sur les dispositifs électroniques portables. En effet la mémoire non volatile reprogrammable, généralement une mémoire EEPROM, a une capacité limitée, de l'ordre de 16 à 64 Kilobits. Même en ajoutant de la mémoire flash, on ne résout pas ce problème. Cette mémoire sert déjà à mémoriser des données nécessaires, correspondant à des normalisations (par exemple, norme GSM pour la téléphonie mobile) : données d'authentification, données d'applications ou de services (applets), répertoires, .... L'espace libre pour d'autres données, telles les données d'un site web, est ainsi limité. La capacité de ces mémoires ne peut être augmentée, avec l'évolution de la technologie de ces mémoires, que dans certaines limites imposées par la constitution même de ces cartes : pour ces cartes qui implémentent des applications sécuritaires, c'est à dire avec authentification, on ne peut pas utiliser des puces trop grandes, qui seraient trop fragiles. Une idée, à la base de la solution technique proposée dans l'invention pour résoudre ce problème, est la mémorisation du site web sous forme compressée. Cette idée n'est pas conforme à ce qui se fait habituellement sur les cartes à puce dans l'état de l'art. En effet la compression de données n'est généralement pas utilisée dans les cartes à puce(s), pour des raisons tenant à l'incompatibilité des processus de compression avec la nature des données mémorisées et avec la structure de données des mémoires non volatiles des cartes à puce. En effet, la nature cryptée d'une partie au moins des données mémorisées dans cet espace, implique que le taux de compression appliqué à ces données sera pratiquement nul, rendant par conséquent sans intérêt cette compression, pour ces données au moins. La structure figée des données en mémoire, c'est à dire sans gestion dynamique de la mémoire (table d'allocation dynamique), opposée à des fichiers applicatifs dont le contenu peut être modifié, rend également la compression inefficace. En effet, dans une structure figée, à chaque fichier ou répertoire doit correspondre une zone mémoire définie une fois pour toute (adresse de début-adresse de fin). Or le taux de compression d'un fichier peut être variable, selon qu'il est modifiable ou non. Dans le contexte des cartes à puce, au moins certains fichiers applicatifs étant généralement modifiables, et la structure des données ne permettant pas de gérer une taille variable de fichier, il faudra allouer à chaque fichier une zone de taille figée, correspondant nécessairement au pire cas (pas de compression). Le taux de compression obtenu sera donc variable, et souvent inefficace à réduire le volume mémoire. Or la compression des données (ou leur décompression nécessaire avant utilisation) est réalisée aux moyens d'algorithmes longs et compliqués, qui mobilisent de la puissance de calcul et de la mémoire temporaire, pendant un temps de calcul non négligeable. Les coûts induits ne se justifient pas au regard des gains variables obtenus (taux ou efficacité de compression). Pour ces différentes raisons au moins, l'utilisation de la compression pour augmenter l'espace mémoire non volatile disponible a été 15 écartée dans les cartes à puce. Dans ce contexte, on a cherché dans l'invention à exploiter une caractéristique des pages web sauvegardées sur le site web : elles sont non susceptibles d'être modifiées : par suite le contenu de chaque page est fixe, invariable. Par conséquent, un algorithme de compression donné appliqué à 20 l'ensemble des données d'une page web du site fournit un ensemble de données de taille connue, invariable, pour lequel on peut réserver une zone mémoire non volatile correspondante dans une structure de données à gestion non dynamique. Cependant, dans le contexte d'une application qui utilise des 25 ressources d'un terminal hôte et d'un dispositif électronique portable d'authentification, un autre aspect est à prendre en compte, à savoir de quelles ressources matérielles/logicielles dispose le terminal hôte auquel un dispositif électronique portable sera attribué. En effet, le marché dans ce domaine a été construit sur la base d'une séparation de la production des 30 terminaux et des dispositifs électroniques portables, pour séparer l'offre commerciale des services/abonnement et des terminaux. Reprenons l'exemple de la téléphonie. Le terminal, c'est le téléphone mobile, qui peut être fourni par une grande variété de fabricants. L'offre des services de téléphonie est fournie par des opérateurs variés. 35 Lorsqu'un utilisateur choisit un opérateur, son abonnement va être géré par le dispositif électronique portable que lui fournit l'opérateur, c'est à dire la carte USim personnalisée par l'opérateur. En mettant cette carte dans le téléphone qu'il a choisi, puis en s'authentifiant, l'abonné peut alors accéder aux services souscrits. Aussi, il ne suffit pas qu'un opérateur mémorise chaque page de son site web sous forme compressée dans les dispositifs électroniques portables qu'il fournit aux clients potentiels, encore faut-il que n'importe quel téléphone choisi par le client puisse accepter cette particularité. Or tous les téléphones mobiles n'ont pas les ressources leur permettant d'accepter tous les formats de codage des algorithmes de compression utilisés, qui peuvent être variés, et de décompresser des données compressées reçues dans des réponses http. Ce problème de connaissance des ressources du terminal hôte est d'ailleurs une des limitations des méthodes de transmission des réponses http de certains serveurs web, comme celle décrite dans la demande TW586066B qui prévoit qu'un serveur web applique une compression au contenu d'une page web qui lui a été demandée, au moment de la transmission de la réponse http vers le navigateur qui en a fait la requête. Ces méthodes de transmission permettent de réduire le temps d'occupation du ou des canaux de communication correspondants entre le serveur et le navigateur client, et donc de libérer le plus rapidement possible le serveur pour lui permettre de traiter d'autres requêtes, mais nécessitent que le navigateur client soit capable d'exploiter les données transmises en réponse, donc de les décompresser, ce qui n'est pas toujours le cas. L'invention a ainsi pour objet de résoudre un problème d'espace mémoire non volatile sur des dispositifs électroniques portables pour mémoriser une page web au moins, sans dépendre des ressources de traitement d'un navigateur d'un terminal hôte, en sorte que la solution technique apportée puissent être universellement appliquée à tout terminal hôte. Selon l'invention, le serveur du dispositif électronique portable est configuré pour qu'en réponse à une requête http, il applique une décompression préalable de la page Web requise, mémorisée sur le dispositif électronique portable, de manière à la transmettre dans le corps de la réponse, sous forme décompressée. L'invention propose ainsi une utilisation inhabituelle dans le domaine concerné, d'algorithmes de compression de pages web appliqués à la mémorisation des données correspondantes en espace mémoire reprogrammable d'un dispositif électronique portable d'authentification hébergeant un serveur web, combinée à une décompression préalable de ces données par le serveur avant émission de la réponse à une requête http, en sorte que ces dispositifs électroniques portables permettent d'élargir le champ des possibilités de réalisation de sites web locaux, indépendamment des configurations des navigateurs des terminaux hôtes dans lesquelles ces dispositifs sont susceptibles d'être utilisés. L'invention concerne donc un procédé de traitement par un serveur web embarqué dans un dispositif électronique portable d'authentification, d'une requête http transmise par un terminal hôte du dispositif, d'accès à une page web mémorisée dans le dispositif électronique, caractérisé en ce qu'il est appliqué à une page mémorisée sous une forme compressée, et en ce qu'il comprend une étape de chargement de données compressées de ladite page, une étape de décompression desdites données chargées, produisant des données décompressées, une étape de formation d'un corps d'une réponse http correspondante avec lesdites données décompressées, et une étape d'émission de ladite réponse. Le procédé de traitement comprend avantageusement, une étape de compression de ladite page dans un format de codage compatible d'au moins un format de codage implémenté dans ledit serveur, produisant des données compressées de la page et au moins une donnée supplémentaire indicative du format de codage appliqué, et l'étape de décompression des données chargées est précédée d'une étape de lecture de ladite donnée supplémentaire, pour appliquer un algorithme de décompression correspondant. Dans un mode de réalisation de l'invention, l'étape de décompression est activée pour former la réponse de toute requête http d'accès à une page web mémorisée sous forme compressée dans ledit dispositif. Dans un autre mode de réalisation de l'invention, le serveur implémentant un format de codage identique ou compatible du format de codage de la page, pour l'émission de données compressées, l'étape de décompression n'est activée que si ladite requête contient une information de codage de contenu en entête excluant l'émission dans le corps de réponse desdites données compressées dans ledit format de codage du serveur. L'invention concerne aussi un dispositif électronique portable implémentant un serveur web et un procédé de personnalisation d'un tel dispositif. D'autres avantages et caractéristiques de l'invention sont détaillés dans la description suivante en référence aux dessins illustrés d'un mode de ~o réalisation de l'invention, donné à titre d'exemple non limitatif. Dans ces dessins : -la figure 1 illustre une architecture d'un terminal hôte ayant un lien de communication avec un dispositif électronique portable à laquelle peut être appliqué un procédé de traitement de requêtes http selon l'invention; 15 -la figure 2 illustre un procédé de traitement de requêtes http selon l'invention; -la figure 3 représente les structures d'une requête http émise par un terminal hôte et de la réponse http fournie par le dispositif électronique portable selon l'invention; et 20 -la figure 4 illustre un système de personnalisation d'un dispositif électronique portable permettant la mise en oeuvre d'un procédé suivant l'invention. La figure 1 illustre une architecture d'un système électronique auquel on peut avantageusement appliquer l'invention. Le système 25 comprend un terminal internet 100, et un dispositif électronique portable 130 d'authentification, comprenant un serveur web embarqué 139, et hébergeant une page web 135. En pratique, plusieurs pages peuvent être hébergées dans le dispositif. Le procédé de traitement selon l'invention de requêtes http pour 30 accéder à ces pages s'applique de la même façon pour chaque page. Le terminal internet 100 comprend de manière classique un microprocesseur (CPU) 140, un. écran 110 et un clavier 120 (ou d'autres boutons, roues de sélection...), et une mémoire non volatile 150. Le navigateur internet ou browser 150 est de manière classique implémenté en 35 mémoire non volatile. Le terminal a par ailleurs un lien de communication 137, typiquement une interface série, filaire, ou non, avec le dispositif électronique portable d'authentification 130. Dans l'exemple plus particulièrement illustré, le terminal 100 est 5 un téléphone mobile dont on a symboliquement représenté une antenne d'émission/réception correspondante 101. Le dispositif électronique portable 130, comprend de manière classique un microprocesseur (CPU) 131, une mémoire programme (ROM) 133 contenant typiquement le système d'exploitation, les différents 10 programmes d'authentification, signature, chiffrement et les clefs associées, le serveur web embarqué SCWS 139, et un programme de décompression DEC, une mémoire RAM de travail 132, et une mémoire non volatile reprogrammable 134, typiquement une mémoire EEPROM ou flash, qui contient des données de personnalisation sécurisée, comme une clef 15 d'authentification 136, des données de programmes applicatifs, et au moins une page web 135. Le lien de communication 137 avec le terminal hôte utilise un connecteur 138 connecté au microprocesseur 131. Le dispositif électronique portable est par exemple une carte SIM ou USIM, avec une interface de communication notamment conforme à la 20 norme ISO 7816. Les mécanismes qui lient le terminal hôte et le dispositif portable et notamment les mécanismes d'authentification sont bien connus, et ne concernent pas en soi l'invention. Il n'y a donc pas lieu de les décrire de manière plus détaillée. On rappellera juste que le dispositif électronique 25 portable d'authentification 130 fournit au terminal 100 les droits d'accès aux services souscrits par un abonné, par une procédure d'authentification qui utilise de manière classique un code d'authentification que doit taper l'utilisateur abonné, typiquement sur le clavier 120 du terminal, sur invite affichée sur l'écran 110. 30 Selon l'invention, la page web 135 est mémorisée dans la mémoire non volatile 134, sous une forme compressée. Cette compression est réalisée par un dispositif externe qui dans une phase de personnalisation du dispositif 130, programme dans la mémoire 134, les données compressées de la page 135. En pratique, la compression appliquée à la page web répond à un format de codage de contenu du type avec compression, compatible avec un format de codage avec compression reconnu par le protocole http. Le protocole http définit en effet les formats de codage de contenu (ou plus simplement formats de codage) reconnus (chapitre 3.5 de RFC2616), utilisables par les serveurs et navigateurs, pour l'échange de données. A l'heure actuelle, les formats de codage avec compression supportés par le protocole http sont les formats Gzip (RFC1952), "compress", le format "deflate" (RFC 1951), ou le format "deflate" englobé dans le format "Zlib" (RFC1950). Le format "deflate" seul, produit des données compressées. Les autres formats sont des conteneurs basés sur un algorithme de compression (deflate ou compress), qui encapsulent des données compressées par d'autres informations supplémentaires, qui peuvent être notamment un nom de fichier, des codes permettant la détection d'erreur (CRC) ou autres. Par exemple Gzip est basé par défaut sur l'algorithme "deflate" (RFC 1951), (mais pourrait être utilisé avec d'autres algorithmes) ; Zlib est exclusivement associé à l'algorithme deflate ; "compress" est basé sur un algorithme Lempel Ziv Welch adaptatif. De manière générale, les données de la page web compressée et mémorisée sur la carte sont obtenues par application d'un format de codage correspondant ou compatible avec l'un de ces formats. Ainsi la page web compressée 135 comprend les données compressées elles-même, notées DATA-C, qui résultent de l'algorithme de compression utilisé (deflate, compress...), et des données Dl et D2, qui encapsulent les données compressées, et qui résultent du format de codage appliqué. En pratique, on prévoit de ne mémoriser sur la carte que les données utiles, c'est à dire essentiellement les données compressées DATA- C et au moins un indicateur de-la compression appliquée, typiquement en entête Dl. D'autres informations, telles que la taille de la page décompressée, et un code de détection d'erreur peuvent être aussi mémorisées (dans Dl et/ou D2 ; cf. figure 1). Dans un exemple pratique, une page web sera compressée en utilisant le format ZIP bien connu, associé à l'algorithme de compression "deflate", et des données produites par ce format, on ne conservera que les données utiles comme indiqué ci-dessus, qui seront les données mémorisées sur la carte, formant la page web compressée 135. Dans cet exemple, cette page web compressée est notamment compatible du format Gzip, qui est un format couramment employé dans les serveurs embarqués dans les dispositifs portables d'authentification. Le serveur embarqué dans la carte est prévu pour mettre en oeuvre un format de codage compatible de celui utilisé pour compresser les pages web, en sorte qu'il sait aller chercher les données compressées DATA-C en mémoire, et les décompresser. Pour cela, il appelle un algorithme de décompression DEC correspondant, implémenté en mémoire ROM 133. Comme illustré symboliquement sur la figure 2, un procédé de traitement selon l'invention par le serveur embarqué 139 d'une requête 200 émise par le navigateur 150, comprend une étape de chargement 10.1 de 15 données compressées DATA-C de la page web 135, une étape de décompression 10.2 de ces données chargées, pour produire des données décompressées DATA-D, et une étape d'émission 10.4 de la réponse 300 avec les données décompressées. De manière plus détaillée, des données de la page web sont 20 chargées en mémoire de travail 132 et décompressées à la volée, au fur et à mesure de leur chargement. On a vu qu'en pratique les données compressées DATA-C mémorisées sont accompagnées (encapsulées) d'autres informations D1, D2 correspondant au format de codage appliqué à la page web, dont une 25 information qui identifie l'algorithme de compression appliqué. Cette information permet au serveur embarqué d'appeler l'algorithme de décompression correspondant en mémoire ROM. Le procédé qui vient d'être décrit permet à un fournisseur de services de réaliser un site web plus riche avec une ou des pages web 30 comprenant non seulement du texte html mais aussi d'autres ressources (images, script,...) dans l'espace libre de la mémoire 134, chaque page pouvant être compressée avant d'être mémorisée, sans que cela nuise à l'accès du site web par un navigateur d'un terminal quelconque, les données de chaque page pouvant être décompressées temporairement avant 35 émission de la réponse. Un perfectionnement de l'invention va maintenant être décrit, en relation avec les figures 2 et 3. Ce perfectionnement de l'invention permet en outre d'optimiser le temps de transmission de la réponse via l'interface de communication 137 entre le dispositif 130 et le terminal 100, ce qui est intéressant notamment lorsque cette interface est lente, ce qui est le cas avec certaines cartes à puce notamment. Dans ce perfectionnement, le procédé de traitement de l'invention utilise les possibilités de négociation de codage de contenu prévues dans le protocole http (RFC2616), pour élaborer une réponse http appropriée au 10 navigateur client qui a émis la requête, avec des données dans leur forme compressée ou des données décompressées, selon que le navigateur client est capable ou non de traiter les données compressées DATA-C, ou non. Avant de décrire le procédé de manière plus détaillée, quelques rappels succincts concernant les formats de codage de contenu, et les 15 formats des requêtes et réponses http, sont effectués ci-après. On a rappelé précédemment les formats de codage avec compression définis à l'heure actuelle dans le protocole http (RFC2616). Ces formats de codage prévoient des données supplémentaires en plus des données compressées. Ces données supplémentaires contiennent 20 notamment un champ dédié généralement dans un entête, dont la valeur identifie l'algorithme de compression utilisé le cas échéant. Un autre format de codage défini dans ce protocole est un format par défaut, sans transformation, c'est à dire sans compression : c'est le format "identity" (pour identité) supportés par tous (serveur/navigateur http). 25 A chacun des différents formats de codage de contenu admis dans le protocole http, correspond une valeur de code ou "jeton" attribuée par une autorité compétente (IANA Internet Assigned Numbers Authority). Ce sont ces valeurs, disponibles au public, qui permettent l'interopérabilité client-serveur comme spécifié dans le protocole http au moyen d'un attribut 30 de codage de contenu prévu dans les entêtes de requêtes et réponses, qui permet aux navigateurs de spécifier s'il y a lieu les formats qu'ils acceptent ou qu'ils n'acceptent pas, et aux serveurs de préciser le format qu'ils utilisent pour la réponse. De manière plus détaillée, une requête http 200 a typiquement le 35 format normalisé suivant : -une ligne de commande 201 contenant la commande (GET, HEAD, ...), l'URL (identifiant de la ressource demandée), et la version de protocole; -un entête de requête 202 -une ligne vide 203 (indiquant la fin de l'entête) -un corps de requête. Notamment, comme spécifié dans la référence RFC2616, l'entête 202 comprend notamment un attribut AE appelé "ACCEPT-ENCODING". Dans cet attribut, le navigateur client 150 qui fait la requête peut indiquer le format ou les différents formats de codage qu'il supporte, en utilisant la valeur ou les valeurs de code correspondante(s). S'il accepte plusieurs formats, l'ordre de préférence se déduit soit en fonction de leur position dans la liste, soit en indiquant un ordre de préférence, en assortissant chaque valeur de code d'un degré, noté q, qui prend une valeur réelle comprise entre 0 et 1, 0 signifiant littéralement, je ne veux pas, et 1 signifiant littéralement je préfère. Notamment, si le navigateur supporte un format de codage donné, par exemple Gzip, il est capable de décoder ce format quelles que soient les options retenues. Notamment, le format Gzip pouvant évoluer vers d'autres algorithmes de compression que l'algorithme deflate (RFC1950), le navigateur sera à même de décoder les données en appelant le mécanisme de décompression approprié, indiqué dans les données transmises. Avec les valeurs de codage de contenu, indiquées dans l'attribut AE en entête d'une requête, le navigateur peut signifier s'il a ou non les moyens de traiter un format de codage avec compression donné. Le navigateur peut aussi forcer un serveur à lui transmettre des données sous forme décompressée, c'est à dire au format identité, en indiquant dans cet attribut la valeur de code correspondante assortie d'un degré de préférence q égal à 1, ou plus classiquement avec un attribut AE présent mais vide, comme prévu dans le document RFC2616. On ajoutera que lorsque l'attribut AE n'est pas présent dans l'entête, cela signifie par défaut que le navigateur accepte tous les formats de codage de contenu. Dans l'invention, la présence et le contenu de l'attribut AE, 35 lorsqu'il est complété par le navigateur, sont utilisés par le serveur pour savoir si le navigateur qui émet la requête a les ressources nécessaires pour supporter le format de codage de contenu avec compression utilisé dans la carte. Une réponse http 300 à une telle requête à un format similaire : -une ligne de statut 301 contenant la version, un code de réponse, et un texte de réponse; -un entête de réponse 302; - une ligne vide 303 (signifiant la fin de l'entête); - un corps de réponse 304. Notamment, comme spécifié dans la référence RFC2616, l'entête 302 comprend notamment un attribut CE appelé "CONTENT-ENCODING" qui permet au serveur qui fournit la réponse (le serveur SCWS) de spécifier le format de codage de contenu appliqué aux données qu'il fournit dans le corps de réponse 304, au moyen de la valeur de code (ou jeton) 15 correspondante, ce qui va permettre le cas échéant au navigateur de connaître le mécanisme de décodage qu'il doit mettre en oeuvre. Le décodage en question, devra éventuellement décompresser les données. Ainsi, l'invention met avantageusement en oeuvre une décompression par le serveur embarqué des données mémorisées sur le 20 dispositif électronique portable, d'une façon qui est conditionnelle, au moyen de l'attribut AE de codage de contenu des requêtes http. Notamment, si la requête 200 contient un attribut AE de codage de contenu listant le ou les formats de codage acceptés, n'est pas compatible avec le format de codage des données 135 mémorisées sur la 25 carte (ce qui sera par exemple le cas si le navigateur n'accepte que le format "compress" et que le format de codage des données mémorisées DATA-C est "deflate"), ou exclut tout format avec compression (ce qui est par exemple le cas lorsque le navigateur envoie une liste vide pour le Accept-Encoding), le serveur embarqué décompresse temporairement les données 30 mémorisées DATA-C de la page web 135, à la volée, au fur et à mesure de leur chargement, pour les transmettre de manière décompressée dans le corps 304 de la réponse. Si au contraire, la requête 200 contient un attribut AE de codage de contenu listant les formats de codage acceptés, contient le format de 35 codage des données mémorisées 135, ou si cet attribut n'est pas présent, le serveur embarqué SWCS charge et transmet les données de la page web telles que mémorisées, dans le corps 304 de la réponse en précisant le format de codage correspondant dans l'attribut CE de codage de contenu dans l'entête 301 : le navigateur 150 qui reçoit la réponse sait alors quel mécanisme de décodage il doit appliquer aux données transmises dans le corps de la réponse, pour les exploiter sans pertes d'information, et notamment quel mécanisme de décompression appliquer aux données compressées. Ainsi, un procédé de traitement par le serveur embarqué SWCS d'une requête 200 émise par le navigateur 150, va principalement comprendre une étape de chargement 10.0 du format de codage de la page web 135 par lequel les données compressées DATA-C ont été obtenues, une étape de chargement 10.1 des données compressées DATA-C de la page web mémorisé 135, une étape d'analyse 10.2 de l'attribut AE de codage de contenu dans l'entête 202 de la requête, pour déterminer si le navigateur client qui a fait la requête 200, accepte le format de codage de la page web 135. Si oui, une réponse 300 est formée avec les données chargées (compressées) DATA-C dans le corps 304 de la réponse. Sinon, une étape de décompression 10.2 des données compressées DATA-C est activée pour fournir des données décompressées, et une réponse 300 est formée avec les données décompressées DATA-D dans le corps 304 de la réponse. L'invention sera mieux comprise au moyen de deux exemples de mise en oeuvre. Dans un premier exemple, on aura par exemple la séquence d'étapes suivante, dans le cas où le navigateur ne supporte pas de format de codage avec compression : L'utilisateur du terminal 100 lance le navigateur 150 à l'aide du clavier 120 et de l'écran 110, et le navigateur 150 affiche une interface 30 correspondante sur l'écran 110. A l'aide du clavier 120 et de l'écran 110, l'utilisateur peut alors demander au navigateur 150 d'envoyer une requête http à la carte. Le navigateur 150 forme cette requête 200 en incluant : -dans l'entête 202, l'attribut AE avec une liste vide, signifiant que 35 le navigateur n'est pas apte à la décompression, -dans le corps 204 de la requête, l'adresse de la page web demandée, et envoie cette requête à la carte 130 via le microprocesseur 140 du terminal, qui reconnaît qu'il s'agit d'une requête http pour le serveur local, et la transmet à la carte 130 via l'interface série 137. Le microprocesseur 131 de la carte 130 reçoit la requête 200, et reconnaît qu'il s'agit d'une requête http. Il lance l'exécution du serveur web 139, et stocke la requête 200 en mémoire de travail RAM 132. Le serveur 139 analyse le contenu de la requête 200 mémorisée en mémoire de travail 132, et notamment de l'entête 210. Il lit dans cet entête, que l'attribut AE est présent mais vide. Le serveur embarqué sait alors que le navigateur qui a fait la requête ne supporte pas la compression. Par la suite, il charge les données compressées DATA-C de la page web (ou d'une partie de la page web) demandée, et les décompresse à la volée, en activant l'algorithme de 15 décompression (mémorisé en mémoire ROM), correspondant au format de codage de la page web compressée 135. Les données compressées DATA-C sont décompressées à la volée, au fur et à mesure de leur chargement en mémoire de travail 132. Le serveur forme une réponse http 300 avec les données 20 décompressées DATA-D obtenues placées dans le corps de réponse 304, et envoie cette réponse vers le navigateur 150 par l'interface 137. Le microprocesseur du terminal 100 reçoit la réponse 300, reconnaît qu'il s'agit d'une réponse http, et la transmet au navigateur 150. Le navigateur 150 analyse le contenu de la réponse 300, récupère 25 le corps de la réponse 304 qui contient la page web décompressée (ou une partie de cette page), et l'affiche sur l'écran 110. On notera ici que la mise en oeuvre du procédé de l'invention suppose que le format de codage avec compression utilisé par le serveur embarqué est le même que celui utilisé pour compresser la page web 135 30 hébergée dans le dispositif électronique portable, ou qu'il est compatible. On entend par compatibilité des formats de codage, des formats basés sur le même algorithme de compression. Notamment les formats de codage Gzip basé sur l'algorithme de compression "deflate" et le format de codage "deflate" sont compatibles. Le format de codage Gzip se différencie 35 principalement en ce qu'il comporte dans les données supplémentaires ajoutées, encapsulant les données compressées DATA-C proprement dites, des données additionnelles telles qu'un nom de fichier ou des informations pour la détection d'erreur de transmission. Ainsi, dans l'exemple précité, si la page web 135 est au format "deflate", et que le serveur embarqué met en oeuvre le format Gzip, le serveur embarqué" est capable d'extraire de la page web mémorisée, les données compressées DATA-C correspondant à la page web demandée, de leur appliquer l'algorithme de décompression correspondant pour obtenir les données décompressées, à transmettre dans le corps de la réponse. ~o Dans un deuxième exemple, l'attribut AE dans l'entête 202 contient une liste d'un ou de plusieurs formats de codage acceptés, dont l'un au moins est basé sur l'algorithme de compression qui a fourni les données de la page web 135 mémorisée en mémoire non volatile 133. Un tel exemple peut correspondre à la situation pratique suivante : 15 -la page web 135 est compressée au format de codage "deflate"; - le serveur 139 implémente le format de codage Gzip, compatible du format de codage "deflate". - le navigateur indique dans l'attribut AE qu'il accepte le format de codage Gzip. 20 Dans ce cas, le serveur embarqué 139 détecte que l'émetteur de la requête accepte les données compressées au format de codage Gzip. Il forme une réponse http 300 pour le navigateur 150 par l'interface 137. Dans cette réponse : - le corps de réponse 304 contient des données compressées 25 DATA-C, correspondant à la page web (ou une partie de la page) demandée, telles que chargées depuis la mémoire non volatile 134, et des données supplémentaires Dl', D2' correspondant au format de codage du serveur (figure 3); - l'attribut CE dans l'entête 302 de la réponse, est rempli avec la 30 valeur de code correspondant au format de codage utilisé par le serveur. Le microprocesseur 140 du terminal reçoit cette réponse 300, détecte qu'il s'agit d'une réponse http, et la transmet au navigateur 150 qui va l'analyser. Le navigateur 150 détecte en analysant l'attribut dans l'entête 302 35 de la réponse, le format de codage du corps 304 de la réponse. Il fait une demande correspondante au microprocesseur 140. Notamment le microprocesseur applique l'algorithme de décompression correspondant aux données compressées DATA-C transmises, et retourne les données décompressées au navigateur 150, qui va commander leur affichage en 110. Le procédé de traitement qui vient d'être décrit avec une décompression sous condition des données de la page web, avant leur émission par le serveur embarqué vers le navigateur, permet avantageusement d'optimiser l'occupation du lien de communication entre le terminal et le dispositif électronique portable chaque fois que c'est possible, ~o c'est à dire chaque fois que le navigateur du terminal est apte à accepter des données dans le format de codage (avec compression) implémenté par le serveur, et qui est égal ou compatible à celui utilisé pour compresser la page web hébergée par le dispositif électronique portable. En particulier, si la page web 135 est au format "deflate", et que le 15 serveur embarqué met en oeuvre le format Gzip, le serveur embarqué extrait les données compressées DATA-C de la page web mémorisée, et forme le corps de la réponse au format Gzip avec les données compressées DATA-C chargées, et des données supplémentaires propres Dl', D2' au format Gzip encapsulant ces données compressées (figure 3). Dans une variante, qui 20 pourrait correspondre à la situation pratique suivante : -la page web 135 est compressée au format de codage "deflate"; -le serveur 139 implémente le format de codage Gzip, compatible du format de codage "deflate". -le navigateur indique dans l'attribut AE qu'il accepte le format de codage 25 "deflate". Alors le serveur prépare une réponse correspondante avec uniquement la partie "deflate" du gzip, c'est à dire seulement les données DATA-C sans les données Dl et D2 propres au format deflate (figure 1). En d'autres termes, le serveur peut le cas échéant envoyer les données DATA- 30 C (format "deflate"), sans encapsulation. La mise en oeuvre de ce procédé par le serveur 139 peut nécessiter le codage en mémoire programme 133 du dispositif électronique portable 130, de différents algorithmes de décompression DEC susceptibles d'être appelés par le serveur 139 selon le format de codage de la page 135, 35 et d'un programme de traitement des requêtes http correspondant, compte tenu des possibilités prévues notamment dans le format Gzip d'utiliser différents algorithmes de compression. Dans ce cas, le serveur saura aller chercher dans les données supplémentaires (Dl, D2), l'identification de l'algorithme de compression utilisé et appeler l'algorithme de décompression correspondant. Le dispositif électronique portable 130 comprend par ailleurs des moyens pour recevoir et programmer en mémoire non volatile les données compressées correspondant à la compression de la page ou des pages d'un site web élaboré par le fournisseur des services. Cette compression de chaque page du site web et la mémorisation de la page compressée résultante en mémoire non volatile du dispositif électronique portable sont des étapes réalisées dans une des phases de personnalisation du dispositif électronique. La phase de personnalisation du dispositif électronique portable comprendra pour chaque page web, une étape de compression des données de la page selon un format de codage déterminé, pour fournir un flot de données compressées correspondantes dans ce format de codage, et une étape de programmation de ce flot de données dans la mémoire non volatile du dispositif électronique programmable. Comme ce dispositif portable sert à une authentification de l'utilisateur d'un terminal, pour un ou des services d'un fournisseur, cette phase comprend une première étape d'authentification qui vérifie les droits du fournisseur à procéder à cette personnalisation. De préférence, et comme illustré de manière schématique sur la figure 4, la phase de personnalisation est une phase de personnalisation électrique dudit dispositif portable qui utilise un équipement de personnalisation 400, typiquement un ordinateur auquel le dispositif portable 130 est connecté par une interface 420, typiquement une liaison série suivant la norme ISO 7816 des cartes à puce, et avantageusement, une liaison USB. Elle comprend une phase d'authentification 20.1 de cet équipement 400 par le dispositif électronique portable, avant une étape 20.3 de programmation des données du site web sous forme compressée en mémoire non volatile reprogrammable 135, avec l'envoi d'une ou plusieurs instructions de mémorisation 11, 12 des données compressées, chaque instruction contenant une partie au moins de ces données. En pratique, l'équipement de personnalisation 400 comprend un microprocesseur 410, avec en mémoire non volatile (disque dur) : -un module cryptographique 430 et une clé d'authentification 440; -le site web 450 comprenant une ou plusieurs pages 450a, 450b 5 par exemple; -un programme de compression 460. Une phase de personnalisation électrique sera alors typiquement réalisée suivant la séquence suivante : Dans une étape 20.1, le microprocesseur 410 s'authentifie auprès 10 de 130 en utilisant la clef 440 et le module cryptographique 430 (étape 20.1). Le dispositif électronique portable 130 authentifie l'équipement 400 à l'aide de la clef 136 et de ses moyens cryptographiques (non représentés). La programmation du site web comprend alors les phases 15 suivantes, pour chaque page : -Dans une étape 20.2, le microprocesseur 410 compresse les données d'une page du site web, par exemple la page 450a, en utilisant le programme de compression 460, fournissant un flot de données compressées 500. 20 -Puis dans une étape de programmation électrique, le microprocesseur 410 envoie une ou plusieurs instructions 11, 12 de programmation au dispositif électronique portable 130 avec le flot de données compressées 500, en mémoire non volatile 134, typiquement une mémoire non volatile. 25 Le format de codage utilisé pour compresser les pages du site web est compatible au ou à un format de codage implémenté par le serveur embarqué SCWS. Dans un exemple pratique, le serveur SCWS implémente le format de codage Gzip, et le dispositif de personnalisation qui assure la 30 compression des pages utilise le format Zip, avec une compression de type "deflate". L'invention qui vient d'être décrite s'applique notamment aux cartes à puce, notamment aux cartes SIM ou (U)SIM, et facilite le développement de sites web hébergés en local sur ces cartes. 35 REVENDICATIONS 1. Procédé de traitement par un serveur web (139) embarqué dans un dispositif électronique portable d'authentification (130), d'une requête http (200) transmise par un terminal hôte (100) du dispositif, d'accès à une page web (135) mémorisée dans le dispositif électronique, caractérisé en ce qu'il est appliqué à une page (135) mémorisée sous une forme compressée, et en ce qu'il comprend une étape de chargement (10.1) de données compressées (DATA-C) de ladite page, une étape de décompression (10.2) desdites données chargées, produisant des données décompressées (DATA-D), une étape de formation d'un corps (304) d'une réponse http correspondante (300) ~o avec lesdites données décompressées, et une étape d'émission de ladite réponse. 2. Procédé de traitement selon la revendication 1, caractérisé en ce qu'il comprend une étape de compression de ladite page dans un format de codage compatible d'au moins un format de codage implémenté dans ledit 15 serveur SCWS, produisant des données compressées de la page (DATA-C) et au moins une donnée supplémentaire indicative dudit format de codage appliqué, et en ce que l'étape de décompression des données chargées (DATA-C) est précédée d'une étape de lecture (10.0) de ladite donnée supplémentaire, pour appliquer un algorithme de décompression 20 correspondant. 3. Procédé de traitement selon la revendication 1 ou 2, caractérisé en ce que ladite étape de décompression est activée pour former la réponse de toute requête http d'accès à une page web mémorisée sous forme compressée dans ledit dispositif. 25 4. Procédé de traitement selon la revendication 1 ou 2, caractérisé en ce que le serveur implémente un format de codage identique ou compatible du format de codage de la page, pour l'émission de données compressées, et en ce que l'étape de décompression n'est activée que si ladite requête contient une information de codage de contenu en entête excluant l'émission 30 dans le corps de réponse de données compressées dans ledit format de codage du serveur. 5. Procédé de traitement selon l'une quelconque des revendications précédentes, caractérisé en ce que les données sont chargées et/oudécompressées à la volée, en mémoire de travail dudit dispositif électronique. 6. Procédé de traitement selon l'une quelconque des revendications précédentes, caractérisé en ce qu'il est appliqué à une page web contenant des données de type texte, et/ou image, et/ou son, et/ou scripts. 7. Procédé de traitement selon l'une quelconque des revendications précédentes, de requêtes http (300) émises par un navigateur (150) implémenté dans ledit terminal hôte (100). 8. Procédé de traitement selon la revendication 7 en combinaison avec la revendication 4, caractérisé en ce qu'une étape d'émission d'une requête par ledit navigateur (150) comprend le remplissage de ladite information de codage de contenu (AE) de l'entête (202), en fonction des formats de codage qu'il peut traiter. 9. Procédé de traitement selon l'une quelconque des revendications 15 précédentes, caractérisé en ce qu'il comprend une étape de réception et de mémorisation d'une page web au moins dans ledit dispositif électronique portable, ladite étape de réception et mémorisation étant préalable à l'étape de réception d'une requête. 10. Procédé de traitement selon la revendication 9, caractérisé en ce que 20 ladite étape de réception et mémorisation est une étape activée par une étape de programmation d'un processus de personnalisation du dispositif électronique portable (130) par programmation de données dans une mémoire non volatile (134) dudit dispositif, ledit processus comprenant une étape de compression d'une page web (450a), pour fournir des données 25 compressées correspondantes (500), et l'étape de programmation desdites données compressées en mémoire non volatile (134). 11. Dispositif électronique portable (130) à serveur embarqué (139) apte à donner accès à au moins une page web mémorisée dans ledit dispositif, caractérisé en ce que ladite page web (135) est mémorisée sous une forme 30 compressée, et en ce que ledit serveur (139) est configuré pour charger, sur réception d'une requête http (300) d'accès à ladite page, des données compressées (DATA-C) de ladite page (135), décompresser (DEC) lesdites données chargées, (DATA-D) et former une réponse (300) à la requête http, avec lesdites données décompressées (DATA-D). 35 12. Dispositif selon la revendication 11, caractérisé en ce que la ou les pages web mémorisées comprennent du texte et/ou des images, et/ou du son. 13. Dispositif électronique portable selon la revendication 11 ou 12, caractérisé en ce qu'il comprend une mémoire non volatile (134), contenant la ou les pages web compressées. 14. Dispositif selon la revendication 13, caractérisé en ce que ladite mémoire non volatile (134) est du type électriquement programmable. 15. Dispositif électronique portable selon l'une quelconque des revendications 11 à 14, caractérisé en ce que ledit serveur implémente un format de codage égal ou compatible du format de codage de la page, pour transmettre des données compressées dans une réponse, et en ce qu'il comprend des moyens pour analyser dans chaque requête http qu'il reçoit, une information de codage de contenu (AE) dans un entête (202) de la requête, pour déterminer si l'émetteur de la requête accepte de recevoir lesdites données compressées (DATA-C) dans le format de codage du serveur, et des moyens de formation d'un corps (304) de réponse (300) à ladite requête, à partir des données telles que chargées de la mémoire, sous forme compressée (DATA-C), ou après décompression, en fonction du résultat de ladite analyse. 16. Dispositif électronique portable selon l'une quelconque des revendications 11 à 15, connecté à un terminal hôte (100) comprenant un navigateur (150), caractérisé en ce que des requêtes reçues sont des requêtes dudit navigateur. 17. Dispositif électronique portable selon l'une quelconque des revendications 11 à 16, caractérisé en ce qu'il comprend des moyens pour recevoir et programmer au moins une page web sous forme compressée (135) en mémoire non volatile (134), d'un dispositif de personnalisation, ledit dispositif de personnalisation comprenant des moyens de chargement d'au moins une page web (450a), des moyens de compression, aptes à fournir des données compressées (500) de ladite page web (450a), et des moyens de programmation desdites données compressées (500) en mémoire non volatile (134) dudit dispositif électronique portable. 18. Procédé de personnalisation d'un dispositif électronique portable (130) par programmation de données dans une mémoire non volatile (134) dudit dispositif, caractérisé en ce qu'il comprend une étape de chargement d'au moins une page web (450a), une étape de compression de données d'une page web (450a) pour fournir dès données compressées correspondantes (500), et une étape de programmation desdites données compressées en mémoire non volatile. 19. Procédé de personnalisation selon la revendication 18, pour une mémoire non volatile (134) électriquement programmable, caractérisé en ce qu'il est mis en oeuvre dans un procédé de personnalisation électrique dudit dispositif comprenant une étape d'authentification du dispositif préalable à ladite étape de compression, et l'étape de programmation comprenant une étape d'envoi (20.3) au dit dispositif d'une ou plusieurs instructions (11, 12) de mémorisation desdites données compressées (500) en mémoire non volatile reprogrammable, chaque instruction contenant une partie au moins desdites données.10