IUT Montpellier - Architecture (DU)

Transcription

1 IUT Montpellier - Architecture (DU) V. Poupet Cours n o 5 : Hypertext Transfer Protocol (HTTP) 1 Le protocole HTTP Lorsqu un utilisateur (client) veut obtenir une page web, il s adresse à un serveur web. Il effectue alors une requête HTTP, qui est suivie d une réponse HTTP de la part du serveur. 1.1 Requête HTTP La requête HTTP la plus simple est de la forme : GET lapin.html HTTP/1.0 Le premier mot (en majuscule) indique la nature de la requête. Ici c est une requête GET (la plus courante) c est-à-dire que le client veut obtenir une ressource. Elle est suivie d une chaîne permettant d identifier la ressources (ici on veut le fichier lapin.html) et de la version du protocole utilisé (HTTP v.1.0) Structure d une requête HTTP Une requête HTTP est constituée d un en-tête, suivi d une ligne vide et du corps de la requête. L en-tête contient une première ligne contenant la méthode employée, la requête proprement dite et la version du protocole utilisée. Les lignes suivantes (qui ne peuvent pas être vides) contiennent différentes informations sous la forme nom_du_champ: valeur_du_champ Le contenu de la requête (après la ligne vide) dépend de la méthode utilisée. Ainsi dans le cas d une requête GET il est vide, tandis que la méthode POST utilise le corps de la requête pour transmettre les données. GET /images/lapin.jpg HTTP/1.1 Accept: image/jpeg, text/html, */* Accept-Language: fr Accept-Encoding: gzip, deflate User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; fr) AppleWebKit/ (KHTML, like Gecko) Safari/419.3 Connection: keep-alive Authorization: Basic bgfwaw46dg9ydhvl Host: localhost:7777 On reconnaît la première ligne (ici le protocole est HTTP v.1.1 et le fichier demandé se trouve dans un répertoire «images»). Les trois lignes suivantes indiquent le type de document que le client attend de la part du serveur. Ici il est indiqué que le client voudrait une image au format jpeg, ou un fichier html ou bien à défaut n importe quel type de fichier. Par ailleurs il préfère les documents en langue française (fr) et accepte que le fichier soit compressé à l aide de l un des algorithmes gzip ou deflate. Le champ User-Agent donne des informations sur le client (navigateur utilisé, système d exploitation, etc.). Pour des raisons de place sur la page, la ligne a ici été coupée mais elle ne doit pas l être dans la requête HTTP. Le champ Connection indique que la socket utilisée pour la connexion doit être maintenue ouverte après la réponse du serveur. Dans les premières versions du protocole HTTP le serveur fermait la 1

2 connexion avec le client dès qu il lui avait envoyé le fichier demandé. Il fallait alors créer une nouvelle connexion pour le fichier suivant. Aujourd hui, la plupart des pages sont constituées de nombreux fichiers (un.html et plusieurs images par exemple). Lorsque le client demande la page, il ne recevra que le.html. En essayant de l afficher il découvrira alors qu il lui faut également les autres fichiers et enverra une demande pour chacun. La demande d une nouvelle connexion pour chaque élément de la page ralentit beaucoup la communication et il a été décidé d ajouter la possibilité de maintenir la connexion ouverte entre le client et le serveur jusqu à ce que l un des deux partis décide explicitement de la fermer (le client lorsqu il a obtenu tous les fichiers nécessaires pour afficher la page ou le serveur en cas d inactivité trop longue du client). Ce comportement keep-alive est maintenant le comportement par défaut dans le protocole HTTP v.1.1. Le champ Authorization permet de s identifier auprès du serveur. Dans l exemple ci-dessus, on utilise la méthode Basic qui consiste simplement en l envoi d un identifiant et d un mot de passe. Ces deux données sont encodées en base 64 afin de s assurer que les symboles spéciaux pouvant apparaître ne poseront pas de problème. Dans l exemple, la chaîne de caractères bgfwaw46dg9ydhvl est l encodage en base 64 de la chaîne lapin:tortue. Notons que l information n est pas cryptée puisque tout le monde peut décoder cette chaîne (en utilisant un algorithme standard) et que cela représente donc un risque de sécurité (quiconque intercepte la requête HTTP peut connaître l identifiant et le mot de passe). Le champ Authorization n est en général pas nécessaire. Il n est transmis que lorsque l utilisateur doit accéder à des informations sensibles. En général on crypte alors la connexion avec le serveur HTTP en utilisant le protocole SSL afin que le mot de passe ne puisse pas être intercepté. Enfin, dans notre exemple, le champ Host indique le nom du serveur web que le client veut contacter. Ce champ, qui était optionnel en HTTP 1.0 mais est devenu obligatoire en HTTP 1.1, peut sembler inutile puisque le serveur est censé connaître son propre nom. Cependant il est particulièrement utile lorsque plusieurs noms de serveurs sont associés à la même adresse IP. On peut en effet avoir deux (ou plus) serveurs serveur1.com et serveur2.com fonctionnant sur la même machine. Lorsque le client veut obtenir un fichier sur le serveur serveur1.com, il interroge le DNS qui transforme ce nom de serveur en adresse IP. Lorsque la requête HTTP arrive à la machine correspondant à l IP demandée cette dernière ne peut pas savoir a priori à quel serveur la demande s adresse. L utilisation du champ Host dans l en-tête de la requête permet de résoudre ce problème. Remarque : Il existe encore bien d autres champs qui peuvent être ajoutés à une requête HTTP, toutefois dans le cas d une requête de type GET aucun n est obligatoire en HTTP 1.0 et seul le champ Host l est en HTTP Quelques types de requêtes Il existe huit méthodes (ou verbes) de requêtes HTTP : GET. C est la méthode la plus couramment employée. Le client demande au serveur de lui envoyer une ressource. HEAD. Semblable à GET dans sa syntaxe, mais ici le client ne demande que les en-têtes de la réponse du serveur (informations sur la ressource qui aurait été renvoyée, mais pas la ressource elle-même). Cette méthode peut être utilisée pour vérifier qu une ressource est disponibles, pour savoir si la version du serveur est plus récente que celle du client, pour connaître la taille de la ressource, etc. sans pour autant transmettre la ressource. POST. Cette méthode est proche de la méthode GET mais ici le client soumet des données (la plupart du temps entrées à l aide d un formulaire HTML) dans le corps de la requête. PUT. Permet au client d envoyer une ressource au serveur (modifier un fichier existant par exemple). Cette méthode est aujourd hui très peu utilisée car elle présente des risques de sécurité évidents. On préfère utiliser le protocole FTP pour ce genre de manipulations. DELETE. Le client demande la suppression d une ressource. Tout comme la méthode PUT elle n est plus utilisée aujourd hui pour raisons de sécurité. TRACE. Demande au serveur de renvoyer la requete qu il reçoit. Cette méthode permet au client de déterminer les modifications éventuelles appliquées à sa requête par les serveurs intermédiaires par lesquelles elle est passée. 2

3 OPTIONS. Le client demande au serveur de lui envoyer la liste des méthodes supportées. CONNECT. Demande la conversion de la connexion HTTP en un tunnel TCP/IP. Cette méthode est principalement utilisée pour établir des communications cryptées à l aide du protocole SSL (HTTPS) lorsque l on utilise un proxy non crypté. 1.2 Réponse HTTP La réponse du serveur HTTP à une requête est également constituée d un en-tête suivi d une ligne vide et du corps de la réponse. À la très simple requête GET lapin.html HTTP/1.0 pourrait correspondre la réponse (également minimaliste) : HTTP/ OK Content-Type: text/html <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" " <HTML> <HEAD> <TITLE>Lapin</TITLE> </HEAD> <BODY> Ce matin un lapin a tué un chasseur... </BODY> </HTML> On remarque tout d abord que le corps correspond exactement au corps du fichier demandé (ici un fichier html mais ce pourrait également être le contenu d une image ou tout autre type de fichier). C est ce qu avait demandé le client. L en-tête quant à lui est constitué de méta-données. La première ligne donne le protocole utilisé (ici HTTP 1.0), suivi d un code de retour (trois chiffres et une description). Cette première ligne peut ensuite être suivie de nombreux champs d informations. Remarque : Tout comme dans le cas d une requête HTTP, la première ligne vide indique au client la fin de l en-tête et le début du corps de la réponse Les codes de retour Les codes de retour sont toujours constitués de 3 chiffres. Ils sont divisés en 5 catégories : 1xx. Informations. Par exemple 100 CONTINUE signifie que le serveur a bien reçu l en-tête de la requête et qu il attend le corps (dans le cas d une requete de type POST par exemple). 2xx. Succès. 200 OK, 202 ACCEPTED, etc. 3xx. Redirection. La ressource n est pas accessible directement, et le client doit donc effectuer d autres tâches avant que la requête ne puisse être complétée. Par exemple 300 MULTIPLE CHOICES demande à l utilisateur de préciser sa demande car l URI correspond à plusieurs ressources différentes, 301 MOVED PERMANENTLY signifie que l utilisateur doit réitérer sa demande vers une autre URI, 303 SEE OTHER indique à l utilisateur de chercher la ressource à une autre URI, etc. 4xx Erreur du client. La requête est mal formulée ou ne peut être exécutée. Les exemples les plus fréquents sont 400 BAD REQUEST (la requête est mal formulée), 403 FORBIDDEN (le client n a pas accès à la ressource) ou encore 404 NOT FOUND (le fichier n existe pas). 5xx Erreur du serveur sur une requête apparemment valide : 500 INTERNAL SERVER ERROR, 501 NOT IMPLEMENTED (le serveur ne sait pas traiter ce type de requêtes), etc. 3

4 1.2.2 Exemple d en-tête La plupart du temps le serveur donne de nombreuses informations dans l en-tête de la réponse HTTP. On pourra par exemple avoir l en-tête suivant d un réponse à une requête de type GET : HTTP/ OK Date: Thu, 08 Feb :48:45 GMT Server: Apache Last-Modified: Thu, 08 Feb :20:26 GMT Content-Language: fr Content-MD5: d72f9499b1b0a9c5c611186e0f98376e Content-Length: Content-Type: text/html; charset=iso On trouve donc dans cet en-tête la date (et l heure) à laquelle la réponse à été envoyée, le type du serveur web, la date de dernière modification du fichier demandé, la langue du document, le code MD5 du fichier, la taille du fichier en octets ainsi que le type MIME du document (ici un fichier de type text, dont le sous-type est html) et le jeu de caractères dans lequel il est encodé. 2 Les serveurs web Lorsqu un utilisateur veut obtenir un document sur Internet (la plupart du temps par l intermédiaire de son navigateur) il interroge un serveur web qui est chargé de trouver l information et de la lui transmettre. Nous avons vu précédemment comment le navigateur contactait le serveur à l aide de l adresse (que ce soit un nom de domaine ou une adresse IP) et comment la connexion s établissait à l aide de sockets TCP/IP. Nous allons ici détailler les étapes effectuées par le serveur entre la réception de la requête HTTP et la transmission de la réponse. Nous prendrons ici comme exemple le serveur Apache HTTP server 1 qui est un serveur libre couramment utilisé (plus de la moitié des sites webs aujourd hui sont servis par Apache), les autres serveurs ayant un comportement très similaire. 2.1 Un exemple de requête Considérons la requête suivante : POST /dossier/fichier.html HTTP/1.1 Accept: text/html, */* Accept-Language: fr,en Accept-charset: iso , utf-8 Accept-Encoding: gzip, deflate User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; fr) Authorization: Basic bgfwaw46dg9ydhvl Connection: keep-alive Host: Cette requête, envoyée au serveur (un autre serveur web refusera la requête car le champ Host serait alors incorrect) précise que l utilisateur veut recevoir le fichier /dossier/fichier.html (la racine de l arborescence est fixée par le serveur web, ce n est en général pas la racine du système de fichiers sur lequel se trouve le serveur). Tous les autres champs ont déjà été présentés précédemment. Lorsqu il reçoit une requête HTTP, le serveur Apache exécute alors successivement les étapes suivantes

5 2.1.1 Child Initialization Un serveur Apache peut être constitué de plusieurs processus (comme c est souvent le cas sur un système Unix) ou d un unique processus contenant plusieurs threads (comme c est le cas sous Windows). Quelle que soit son architecture, lorsqu il reçoit une requête, celle-ci est traitée en parallèle (par un processus fils ou un nouveau thread) généré à la réception de la requête Post Read Request et Header Parser Cette étape correspond à la lecture de l en-tête de la requête. Les champs sont parcourus et le serveur décide alors s il doit ou non poursuivre le traitement. Si la requête est mal formulée elle peut être rejetée à cette étape. S il manque un champ indispensable (comme le champ Host en HTTP 1.1) la demande est également rejetée. L étape Header Parser découpe également les informations contenues dans l en-tête pour séparer tous les champs importants (l URL demandée, les types de retour attendus, etc.) qui seront ensuite transmis aux étapes suivantes Translate Name L URL de la ressource demandée est ici transformée en un nom de fichier. Dans notre exemple, si la racine du serveur HTTP se trouve dans le répertoire /home/lapin/web/server/ (dans l arborescence de la machine sur laquelle se trouve le serveur) alors le serveur traduit l URL /dossier/fichier.html en /home/lapin/web/server/dossier/fichier.html. Il est également possible de faire faire au serveur des transformations plus complexes. Il est par exemple possible de demander à ce que toutes les URL du type /script/nom soient transformées en /usr/bin/nom afin que le serveur puisse exécuter des instructions sur le système de fichier en recevant des requêtes HTTP Check Access Une fois que le serveur connaît le nom du fichier cible, il vérifie que ce fichier est accessible. Cette vérification précède toute forme d authentification de l utilisateur, c est-à-dire que le serveur vérifie simplement que le fichier existe et qu il pourrait l obtenir s il le fallait Check User ID Le serveur doit ici déterminer l identifiant de l utilisateur et vérifier que les informations fournies suffisent à confirmer cette identité. Dans notre exemple, le serveur voit que l authentification se fait selon le protocole Basic, il décode donc la chaîne de caractères bgfwaw46dg9ydhvl, obtient l identifiant et le mot de passe fournis par l utilisateur (lapin et tortue respectivement) et va demander au système si l utilisateur lapin existe et si son mot de passe est bien tortue. Si cette vérification échoue, le serveur renvoie l erreur HTTP_UNAUTHORIZED et l en-tête de la réponse contient les détails indiquant à l utilisateur quelles informations il doit fournir pour s identifier correctement Check Auth La procédure précédente se contente de vérifier l identifiant annoncé par l utilisateur (est-il bien celui qu il prétend être) mais ne détermine pas pour autant s il a accès à l information demandée. C est l étape d autorisation qui s en charge. Connaissant l identité de l utilisateur, le serveur peut maintenant vérifier que cet utilisateur a bien accès à la ressource demandée (la plupart du temps cela se fait en interrogeant le système de fichiers). Si l accès n est pas autorisé, c est encore une fois l erreur HTTP_UNAUTHORIZED qui est levée et revoyée à l utilisateur en lui demandant une nouvelle authentification (sous une autre identité). 5

6 2.1.7 Type Checker À ce stade-ci, la requête est presque entièrement traitée. La ressource a été localisée et toutes les vérifications ont été faites pour s assurer qu elle pouvait être transmise au client. Il ne reste alors plus qu à déterminer quel handler (module qui manipule le fichier) va effectivement traiter la demande. En effet, s il est vrai que la tâche est quasi-instantanée dans le cas d une requête d un fichier HTTP simple (il suffit de joindre le fichier tel quel à la réponse) il est parfois nécessaire de faire appel à des programmes spécifiques dans des cas plus complexes. Ainsi, si la requête correspond à un script il faut appeler l interpréteur correspondant (PHP, Python, Perl, etc.), ou si le fichier demandé doit être modifié avant d être envoyé (certaines pages sont traduites avant d être transmises, ou bien il faut parfois insérer les champs envoyés pas l utilisateur dans la page, etc.). Afin de déterminer le handler approrié le serveur détermine le type MIME de la ressource demandée à partir de son URL (par exemple text/html, ou image/jpeg) et produit une chaîne de caractères à transmettre au handler. Ce module peut également générer une chaîne de caractères à fournir au handler en fonction des informations connues jusqu ici (par exemple la ligne de commande d appel d un script) Prerun Fixups Dernière étape avant de laisser travailler les handlers. C est ici que sont effectuées les dernières tâches éventuellement nécessaires au bon fonctionnement du handler, comme par exemple la définition des variables d environnement pour un script. La plupart des modules n effectuent aucune action à ce stade-ci car tout ce qui devait être fait a été traité lors de l une des étapes précédentes Handlers La requête a été entièrement préparée et peut maintenant être effectivement traitée par le programme approprié. C est à ce stade-là que les interpréteurs de scripts sont appelés (PHP, Perl, Java, etc.), que l on peut traduire le document demandé dans une langue spécifiée par le client, etc. La plupart des handlers renvoie directement la réponse HTTP (il est alors nécessaire de s assurer que le handler ajoute bien l en-tête de la réponse HTTP), mais ils peuvent aussi parfois se contenter de transmettre en interne le contenu de la réponse au serveur. Ce dernier devra alors produire l en-tête Logger Une fois que la requête a été entièrement traitée et que la réponse a été renvoyée au client, le serveur inscrit dans un fichier de log les détails de la transaction afin d en garder une trace (par exemple la totalité de la requête HTTP, les détails de connexion avec l ordinateur distant et l en-tête de la réponse transmise) Child Exit Le processus ou thread qui avait été initialisé pour traiter la requête HTTP peut maintenant être terminé. 3 Sessions HTTP Le protocole HTTP est un protocole sans état (state-less) c est-à-dire qu aucune information n est conservée entre deux requêtes successives. Il ne prévoit donc aucune méthode pour spécifier explicitement qu une requête est la suite d une autre. Il est pourtant parfois confortable de pouvoir s identifier auprès d un site web et de faire en sorte que par la suite le serveur reconnaisse l utilisateur et puisse adapter la réponse à cet utilisateur. Pour cela, il est nécessaire de mettre en place un susyème de sessions. Une session HTTP est une suite de requêtes HTTP (d un client vers un serveur) qui sont reconnues par le serveur comme provenant du 6

7 même client. Il est alors possible de partager des informations sur la totalité de la session (variables de session) qui peuvent être lues et modifiées à chaque requête. 3.1 Une première idée : les adresses IP Afin d identifier un utilisateur pour suivre ses requêtes successives sur un même serveur, on pourrait vouloir utiliser l adresse IP de l ordinateur client. Notons que cette adresse IP n est pas donnée dans la requête HTTP (elle ne figure pas dans les en-têtes) mais que le serveur connaît l IP de l ordinateur qui a demandé la connexion TCP/IP. Cette technique présente cependant de nombreux inconvénients : Si le client utilise un proxy entre son ordinateur et le serveur HTTP, seule l adresse du proxy sera visible par le serveur. Certains fournisseurs d accès à Internet (AOL par exemple qui est le principal FAI aux États-Unis) font passer toutes leurs connexion par un petit nombre de proxys, ce qui empêche donc les serveurs web de les distinguer par leur adresse IP. Un même ordinateur peut être partagé par différents utilisateurs. Les ordinateurs sur Internet n ont pas nécessairement une adresse IP fixe. La plupart des FAI aujourd hui distribuent dynamiquement les adresses IP et il ne sera donc pas possible pour un serveur de reconnaître un utilisateur si l ordinateur de ce dernier s est déconnecté puis reconnecté avec une autre IP. Notons que de plus en plus de FAI proposent maintenant une option «IP fixe» à leurs clients. 3.2 La solution HTTP Il est possible de suivre les requêtes successives d un même client en utilisant les méthodes GET et POST du protocole HTTP sur des pages web générées dynamiquement. En effet, nous avons vu que ces deux méthodes permettent de transmettre des variables lors d une requête HTTP : dans le cas de POST les variables et leur valeur sont transmises dans le corps de la requête tandis que dans le cas de GET elles sont transmises dan l URI (en ajoutant une chaîne de la forme?nom1=val1&nom2=val2). Lorsqu un utilisateur arrive sur une page sans fournir de variables dans sa requête le serveur le considère comme un nouvel utilisateur et lui attribue un numéro de session (différent des numéros déjà attribués à d autres utilisateurs). Une fois ce numéro déterminé (qui servira à identifier cet utilisateur), le serveur modifie tous les liens des pages qu il envoie au client pour que celui-ci envoie son numéro de session à chaque fois qu il suit un lien. Si par exemple le numéro qui a été attribué est 1032, on ajoute?id=1032 à tous les liens pour que l identifiant soit passé au serveur par la méthode GET à chaque page demandée. Si l on veut utiliser la méthode POST il suffit d ajouter un formulaire caché (qui n est pas affiché par la page) contenant un champ pré-rempli indiquant le numéro de session (ce formulaire sera donc transmis à chaque requête de la part du client). Il est ensuite facile pour le client d identifier toutes les requêtes faites par le même client puisqu elles contiennent toutes le même identifiant. Le serveur peut également modifier les valeurs (et le nombre) des variables que le client enverra, mais un seul identifiant pourrait suffire puisque toutes les variables nécessaires pourraient être enregistrées sur le serveur (toutefois le site pourrait vouloir ne pas encombrer la mémoire du serveur et donc transmettre les variables aux utilisateurs) Différences entre POST et GET Lorsque l on utilise la méthode GET les variables sont échangées de manière visible dans l URI. Ceci peut être intéressant pour permettre à l utilisateur de modifier facilement les valeurs des variables transmises ou de les échanger avec quelqu un d autre en copiant simplement l URI. C est ce qui permet également aux navigateurs de créér des marque-pages dynamiques : on peut marquer la page d un moteur de recherche en indiquant où doit être insérée la chaîne de caractères à rechercher, ce qui permet d effectuer une recherche directement sans avoir à passer par la page principale du moteur de recherche. 7

8 On pourra cependant préférer cacher ces variables à l aide de la méthode POST pour différentes raisons. Ça allège les URI affichées par les navigateurs qui sont donc plus faciles à mémoriser et plus agréables pour l utilisateur, c est un moyen de faire passer des variables discrètement sans que l utilisateur s en rende compte (il pourrait le voir mais il est rare que l on inspecte le code source de la page ou les requêtes HTTP transmises par le navigateur), et enfin ça permet de passer une plus grande quantité d informations (certains serveurs refusent les URI trop longues, et il est en général déconseillé de dépasser 255 caractères). Enfin, remarquons que ces deux méthodes ne se comporteront pas de la même manière vis-à-vis des marque-pages. Dans le cas d un passage de variables dans l URI (GET) si l utilisateur créé un marque page, copie entièrement l adresse, ou l envoie à ses contacts, les variables seront copiées également et donc ces mêmes variables (avec leurs valeurs) seront utilisées à chaque fois. Si l on cache les variables (POST) elles ne seront pas mémorisées ou transmises Inconvénients Cette méthode permet donc d implémenter un mécanismes de sessions (et de séquetialité des requêtes d un client à un serveur) mais elle présente encore certains inconvénients : Les sessions ne sont pas conservées si l utilisateur quitte le site et revient en entrant la même adresse que la première fois qu il est venu (donc sans transmettre de variable). À l inverse, comme nous l avons vu, si l utilisateur revient sur la page après avoir copié l adresse les variables reprendront toutes la valeur qu elles avaient au moment où l adresse a été copiée (ou marquée dans un navigateur). Si l on utilise un proxy qui garde en mémoire les pages web les plus demandées, celui-ci va transmettre à tous les utilisateurs la même page qui ne sera donc pas recréée dynamiquement pour chacun. Toutes ces pages contiendront donc les mêmes variables et ne permettront pas de distinguer les utilisateurs. 3.3 Cookies HTTP Les cookies HTTP ont été introduits par le navigateur Netscape afin de pouvoir implémenter correctement un système de sessions. L objectif était de permettre de gérer un panier de courses virtuel sur un site d achats en ligne (l utilisateur parcourt le site et peut à tout moment ajouter ou supprimer des objets de son panier virtuel afin de payer la totalité de la commande en une seule fois). En pratique, les cookies sont des chaînes de caractères que le serveur envoie au client dans l en-tête d une réponse HTTP. Ces cookies sont stockés sur l ordinateur du client (en général dans un unique fichier de cookies). Par la suite, à chaque fois que le client enverra une requête à ce serveur, il lui transmettra le cookie dans l en-tête de la requête HTTP. Le serveur a la possibilité de modifier ou supprimer le cookie, et peut ajouter des cookies supplémentaires Syntaxe côté serveur Pour placer un cookie chez le client, le serveur utilise le champ Set-Cookie dans l en-tête de la réponse HTTP. La syntaxe est la suivante : Set-Cookie: NOM=VALEUR; expires=date; path=chemin; domain=nom_de_domaine; secure où les mots en minuscule désignent des mots-clés (imposés par le format des cookies) et les mots en majuscule sont à remplacer par les valeurs choisies par le serveur. Un cookie a donc plusieurs attributs : NOM=VALEUR. C est le seul champ qui doit obligatoirement être renseigné. Il définit le nom du cookie et sa valeur. Le nom et la valeur du cookie ne peuvent pas contenir de point virgule, de virgule ou d espace. De plus le caractère = ne peut pas apparaître dans le nom puisque le premier = rencontré indique la séparation entre le nom et la valeur du cookie (mais la valeur peut contenir des caractères =). expires=date. Ce champ indique la limite de validité du cookie. La date est représentée sous la forme 8

9 Wed, 06-Feb :14:35 GMT où GMT est le seul fuseau horaire accepté. Souvent les navigateurs enregistrent cette date dans le fichier de cookies en la mesurant en secondes depuis l epoch (1er janvier 1970) sous la forme d un entier écrit en base 10 (par exemple pour la date indiquée précédemment). Lorsque le navigateur parcourt la liste des cookies disponibles, il supprime tous ceux qui sont périmés. C est également ce mécanisme qui est utilisé par le serveur pour demander la suppression d un cookie chez le client : il modifie la date d expiration à une date quelconque dans le passé. Il n est pas indispensable de fournir une date d expiration. Si aucune n est fournie le cookie n est valable que pour la session courante et est donc détruit lors de la fermeture du navigateur. domain=nom_de_domaine. Indique le domaine de validité du cookie. Le navigateur ne transmettra le cookie que lorsque la requête HTTP est transmise à un sous-domaine de celui indiqué. Ainsi, si par exemple le navigateur reçoit un cookie de domaine domaine.com, il le transmettra à chaque fois qu il contactera le serveur domaine.com, mais également s il contacte mon.domaine.com ou moi.mon.domaine.com. Le serveur qui envoie le cookie doit nécessairement appartenir au domaine spécifié sans quoi le navigateur refuse le cookie. Par ailleurs il existe des contraintes sur le domaine d un cookie qui imposent une certaine spécificité, ainsi il n est pas possible de fixer un cookie dont le domaine est com ou co.uk qui sont trop génériques. Si le domaine n est pas précisé, c est le domaine du serveur qui est considéré par défaut. path=chemin. Cet attribut précise l ensemble des URI qui sont concernées par le cookie. En effet le cookie ne sera transmis que si l URI demandée commence par le contenu du champ path. Par exemple, si le chemin est /un/chemin, le cookie sera envoyé lorsque l on demande le fichier /un/chemin/index.html, mais également si l on demande /un/cheminot. Si le chemin n est pas spécifié lorsque le cookie est envoyé il est considéré comme se rapportant au chemin «/» qui inclut toutes les pages du domaine. secure. Cet attribut (qui n a pas de valeur) indique simplement que le cookie ne doit être renvoyé par le navigateur que si la connexion utilisée est cryptée. Si cet argument n est pas donné à la création du cookie, le cookie est envoyé quelle que soit la sécurité de la connexion. Cet attribut est utilisé lorsque le cookie représente une information sensible (une identification sur un site bancaire par exemple) Syntaxe côté client Lorsque le client envoie une requête, le navigateur parcourt la liste des cookies et détermine ceux qui correspondent à la requête émise (la date d expiration n est pas passée, le domaine et le chemin correspondent, et la sécurité de la connexion est adaptée). Il transmet ensuite les noms et valeurs de chacun de ces cookies en une seule ligne de l en-tête de la requête HTTP sous la forme : Cookie: NOM1=VALEUR1; NOM2=VALEUR2; Remarques Il est possible d envoyer plusieurs cookies dans une unique réponse HTTP en utilisant plusieurs champs Set-Cookie dans l en-tête. Lorsqu un cookie portant le même nom et correspondant aux mêmes domaine et chemin qu un cookie existant est envoyé, il remplace le précédent. Si par contre les chemins sont différents les deux cookies sont conservés. Le client peut choisir de détruire un cookie à tout moment (même si la date limite n est pas atteinte). Inversement, il peut choisir de continuer à utiliser un cookie périmé. Lorsque le client envoie les cookies au serveur, les cookies correspondant aux chemins les plus spécifiques doivent être envoyés en premier. Ceci est particulièrement important dans le cas où deux cookies de même nom mais de chemin différent co-existent. Ainsi si le client a deux cookies nom=val1 de chemin / et nom=val2 de chemin /blop/, le cookie nom=val2 doit apparaître en premier dans la liste envoyée. Le nombre et la taille des cookies sont limités. Cette limite varie en fonction du navigateur. De manière générale, on considère les limites suivantes : le navigateur ne conserve pas plus de 300 cookies au total ; 9

10 la chaîne formée du nom et de la valeur d un cookie ne doit pas dépasser 4096 caractères ; seuls 20 cookies par domaine sont acceptés. Les serveurs doivent considérer que les navigateurs clients ne dépasseront pas ces limites. Lorsqu un cookie est reçu alors que la limite est atteinte le navigateur est censé supprimer le cookie dont la dernière utilisation est la plus ancienne. Par ailleurs si le navigateur reçoit un cookie dont la taille dépasse 4096 caractères, il doit le tronquer en conservant le nom. Les serveurs proxy qui utilisent un cache pour stocker les réponses HTTP ne doivent pas enregistrer les champs Set-Cookie. 10