This page has been robot translated, sorry for typos if any. Original content here.

Protocole HTTP

Pour la source, découvrez par vous-même ce que le protocole est commun. Un protocole est un certain ensemble de règles, ainsi que des signes clés, destinés à la communication entre périphériques. Il est nécessaire que les ordinateurs ou leurs éléments puissent clairement reconnaître le copain d'un ami.

Ordinateurs parlant le protocole sur le réseau.

En fait, tout ensemble de commandes est autorisé à être appelé protocole, mais en pratique, le concept de protocole s'applique uniquement aux protocoles dits de réseau, c'est-à-dire aux langues parlées par les ordinateurs du réseau. Chaque protocole a un objectif spécifique et est pris en charge par un logiciel spécialisé.

URL, IP et adresses DNS, domaines

Donc, l'URL (Uniform Resource Locator) est la route complète du document . L'URL est une adresse permettant de rechercher de manière unique un document (fichier) sur Internet. La ligne que vous tapez dans la fenêtre "adresse" de votre navigateur contient également l'adresse URL du document.

L'URL peut avoir un aspect très sophistiqué, comprenant également diverses parties. Tout d'abord, considérons l'URL la plus simple:

Cette URL contient trois éléments constitutifs: le nom de l'hôte où se trouve le document, le nom du protocole utilisé pour transmettre ce document et le nom réel de l'acte lui-même (nom de fichier et extension). La base (et la seule partie requise pour le protocole http) de l'adresse est le nom d'hôte. Il détermine la machine sur laquelle l'acte est situé (sur le réseau, les ordinateurs individuels sont appelés hôtes ). Chaque ordinateur du réseau est un hôte et porte également un nom unique (sur ce réseau). Dans l'exemple ci-dessus, rambler.ru est le nom de l'ordinateur sur lequel nous voulons trouver le document.

Les noms d’hôte peuvent être spécifiés de manière dupliquée: en utilisant DNS également en utilisant une adresse IP. Une adresse IP est composée de quatre chiffres séparés par un point. Chaque quantité peut exister dans une plage allant de 0 à 255. Par exemple, 192.168.2.1 .

Cependant, en pratique, l’utilisation d’adresses IP n’est pas pratique, car les numéros sont difficiles à retenir. Par conséquent, un système de nom de domaine (Domain Name System) a été introduit, dans lequel chaque adresse IP est mise en relation avec un ou un nom composé de lettres ou de chiffres. Par exemple, dans l'exemple ci-dessus, le nom DNS était rambler.ru , il correspond également à l'adresse IP 217.73.192.109 .

Il est à noter que différents noms DNS correspondent toujours à différentes adresses IP, mais que les mêmes adresses IP peuvent correspondre à différents noms DNS. Par exemple, différents noms DNS tels que www.rambler.ru et rambler.ru ont aussi la même adresse IP blah. Les URL sont autorisées à utiliser les noms DNS et les adresses IP. Ainsi, les deux adresses URL http://rambler.ru/index.html et http://217.73.192.109/index.html sont équivalentes. Quelques manières de définir l'adresse IP sont décrites ici http://www.xakep.ru/post/11980/default.htm .

Notez également qu'en principe, l'hôte ne doit pas posséder de nom de domaine. C'est-à-dire que certains hôtes sont autorisés à contacter uniquement par adresse IP.

Vous avez probablement déjà fait attention au fait que tout nom DNS est constitué de mots séparés, séparés par des points. Chaque nom signifie séparément le domaine auquel appartient l'hôte. L'ensemble du système DNS est hiérarchique. Tous les domaines du 1er niveau (com, org, ru, etc.) appartiennent au domaine racine du 0e niveau (ce qui n’est généralement pas écrit dans le DNS de la manière qu’il a signifiée par défaut). Les domaines d'un autre niveau (par exemple, rambler, mail ou kiev) entrent également dans les domaines du niveau principal, etc. Les domaines dans DNS sont écrits de droite à gauche, dans l’ordre d’augmentation du niveau.

Nous notons deux caractéristiques importantes: 1. Le domaine est une unité purement administrative et ne représente pas un hôte. 2. L'adresse IP ne dépend en aucun cas du domaine dans lequel se trouve l'hôte.

Ainsi, le système de domaine a été introduit simplement pour classer les sites en fonction de caractéristiques géographiques ou de cibles, et n’a également aucune relation avec la structure physique d’Internet.

Dans l'exemple d'URL de l'exemple, nous avons explicitement défini le nom de l'acte qui nous intéresse, index.html , mais sur chaque site, un document est ouvert par défaut. En tant que poste, le nom index.html ou default.html est également situé dans le dossier racine du site. Si nous entrons l'URL du site sans spécifier le nom du fichier dont nous avons besoin, le serveur nous ouvrira automatiquement le certificat par défaut. Ainsi, l'adresse http://crackchat.h1.ru est équivalente à l'adresse http://crackchat.h1.ru/index.html . Tout comme bla bla puisqu'un fichier est ouvert par défaut, il y a aussi un dossier par défaut. Sur la plupart des serveurs, le dossier par défaut des documents HTTP appartient au nom WWW .

Après le DNS dans l'adresse URL suit le nom de l'acte auquel nous nous référons. Cela implique que ce fichier se trouve dans le dossier racine. Si bla bla, ce n'est pas le cas, alors nous pouvons indiquer la route remplie vers l'acte, en listant les sous-dossiers à travers la barre oblique:

Dans cet exemple, nous nous référons au fichier du dossier cgi-bin / perl / . Ce chemin est relatif au dossier racine. Ainsi, par exemple, si le chemin du dossier racine est f: / www , dans notre exemple, nous nous référons au fichier f: /www/cgi-bin/perl/search.pl . En même temps, il est important de prendre en compte les points suivants: étant donné que la plupart des serveurs Web sont construits sur des systèmes de type UNIX, lors de la spécification de la route vers le fichier, il convient de prendre en compte la différence entre les lettres minuscules et majuscules. Donc, si nous avions accédé au fichier à l’URL http://rambler.ru/CGI-BIN/perl/Search.pl , le serveur n’aurait pas trouvé un tel fichier. La différence entre les lettres impressionnantes et les minuscules ne résulte que dans la route vers le fichier, mais le DNS est insensible à la casse (l'adresse RAMBLER.RU est également équivalente à l'adresse rambler.ru ).

Comme indiqué précédemment, le DNS correspond à une adresse IP strictement définie, mais cela ne signifie pas que le nom DNS est équivalent à l'hôte auquel nous avons accès. Souvent, l'hôte lui-même possède en lui-même des domaines de niveaux plus sans fond. Par exemple, le site h1.ru est un hôte dans un domaine d'un autre niveau, mais il contient lui-même des domaines de troisième niveau, par exemple crackchat.h1.ru ou crosswords.h1.ru . Par conséquent, ces paires de sites appartiennent au même hôte et ont naturellement la même adresse IP! Physiquement, dans ce cas, les domaines de troisième niveau ressemblent aux dossiers du disque hôte h1.ru et leur accès peut s'effectuer de la manière suivante: h1.ru/crackchat/ ou h1.ru/crosswords/ . Les moyens d'accès (via le domaine du 3ème niveau ou via le chemin du disque) sont déterminés par les paramètres du serveur.

De même, le dossier racine est considéré comme un domaine. Par conséquent, la plupart des URL peuvent être spécifiées sous forme de paires de formats: comme avec le domaine www (par exemple, www.crackchat.h1.ru ), également sans ce dernier ( crackchat.h1.ru ) - dans ce cas, le serveur est toujours actif . vous dirige automatiquement vers le dossier www, puisqu'il s'agit du dossier par défaut.

Protocoles, ports, protocole CGI

Comme nous l'avons déjà observé, l'adresse URL est constituée de trois éléments principaux: le nom DNS, le chemin du fichier et le nom du protocole. Si les deux premiers éléments vous permettent de localiser le document, le protocole détermine le mode d' accès au document. En d’autres termes, à quel moment le client essaie d’obtenir le document, il est obligé de dire au serveur comment il (le serveur) est obligé de lui transmettre cet acte (le client). Il existe de nombreux protocoles de transfert de données différents sur le réseau, parmi lesquels les plus courants sont http (HyperText Transfer Protocol), ftp (File Transfer Protocol), mailto (préfixe de la famille de protocoles de messagerie) et file (protocole d'accès de fichiers). ou des dossiers). Le type de protocole détermine le programme capable de traiter des données au format de ce protocole. Internet Explorer peut donc fonctionner avec les protocoles http , fichier et ftp , mais ne peut pas fonctionner avec le protocole mailto . Par conséquent, si vous tapez dans votre navigateur, dans la barre d’adresses mailto: microsoft.com , un programme de messagerie spécial pouvant fonctionner avec ce protocole sera lancé (par exemple, Outlook Express ou The Bat!). Le nom du protocole indiqué par l'URL la plus importante dans l'URL doit également se terminer par un signe deux-points. Le registre n'a pas d'importance.

Parmi les protocoles il y a des protocoles assez bizarres tels que res ou à propos de protocole (pour votre intérêt, vous pouvez taper dans la barre d'adresse de votre navigateur sur: <a href="mailto:bill@microsoft.com"> envoyer bonjour à Bill </a> et voir ce qui va devenir :) . Ldap est un autre protocole intéressant (essayez par exemple ldap: //microsoft.com ).

Tous les protocoles ne peuvent pas agir en tant que protocole pour une URL. Ainsi, les protocoles about ou javascript n'ont rien à voir avec le routage de document rempli, également parce que les "adresses" associées à ces protocoles ne sont pas des URL.

Le préfixe de protocole indique au client dans quelle "langue" la communication avec le serveur sera établie. Et le client sait à l'avance quel programme doit mener cette communication, ce qui est impossible à dire sur le serveur. Pour que le serveur commence à «parler» avec nous dans le langage de protocole requis, il (le serveur) est obligé de lancer le programme approprié qui comprendra ce protocole. Pour résoudre ce problème, utilisez les ports . Donc, si le nom DNS ou l'adresse IP définit la machine à laquelle nous nous référons, le port détermine le programme auquel nous avons accès sur cet hôte. Les ports sont indiqués par un entier compris entre 0 et 65535.

Chaque protocole se voit attribuer un port par défaut sur lequel le programme serveur attend les demandes du client. Par exemple, si le serveur prend en charge le protocole http , le programme serveur correspondant (par exemple, Apache) attendra les demandes du client pour le port 80 (ce port est le port par défaut du protocole http ). Si cet hôte est également pris en charge par le protocole ftp , un autre programme serveur attendra les demandes sur le port 21 (ce port est réservé au protocole ftp ).

Le port auquel nous accédons est déterminé automatiquement, en fonction du protocole sélectionné dans l'URL. Mais le port est autorisé à spécifier aussi explicitement. Le numéro de port est indiqué par deux points après un nom DNS ou une adresse IP:

Dans l'exemple ci-dessus, nous nous référons à un certain programme "bloqué" sur le port 8080 , nous lui demandons également de nous fournir le fichier index.html à l'aide du protocole http . S'il n'existe aucun programme de ce type sur le serveur (le programme ne suivra pas les demandes du port 8080 ), le navigateur nous enverra un message concernant l'adresse URL erronée.

Puisque le port 80 est accepté par défaut pour les serveurs http , l'adresse http://rambler.ru:80 est équivalente à l'adresse http://rambler.ru . Bien qu'en principe, les hôtes ne soient pas obligés de prendre en charge http sur le port 80 . Le serveur peut exister configuré par exemple sur le port 3128 , également à ce moment-là, pour communiquer avec cet hôte sur http, vous devez toujours spécifier explicitement le numéro de port: http : //rambler.ru.7312

Lors de l'accès au serveur, il est parfois nécessaire d'indiquer en plus de l'adresse de l'acte, outre l'ID utilisateur, lequel accède au serveur (ou auquel nous accédons sur le serveur), mais le mot de passe d'accès est similaire. L'URL vous permet de transmettre cette information. Pour cela, le nom DNS est précédé d'un préfixe avec le nom d'utilisateur:

En règle générale, le protocole http ne nécessite pas d'identification de l'utilisateur, mais il est obligatoire pour les protocoles tels que ftp ou mailto . En plus du nom d'utilisateur, il est également permis de spécifier un mot de passe d'accès. Le mot de passe n'est plus dans le nom du côlon. Par exemple: ftp: // masha: kasha@yahoo.com . Cette URL demande le protocole ftp pour le répertoire racine de l'hôte yahoo.com pour l'utilisateur masha avec le mot de passe kasha . Mais l'adresse mailto: //masha@mail.ru est utilisée pour accéder à la boîte aux lettres de l'utilisateur masha sur l'hôte mail.ru.

Le nom de l'utilisateur peut être construit de la même manière sur le principe du domaine et se composer de divers éléments séparés par un point. Par exemple, mailto: //bill.geits@microsoft.com .

Comme déjà indiqué, l’URL est l’itinéraire complet du document. Par la loi, on entend tout fichier pouvant exister sous forme de texte (par exemple html, doc ou pdf), aussi une image (jpg ou gif), aussi un programme. Dans le même temps, le protocole http implique que si l'URL demande du texte ou une image, elles doivent être envoyées à l'utilisateur pour pouvoir les afficher dans son navigateur. Si un programme ou un script est demandé, il doit être exécuté sur le serveur et le résultat de son travail doit être envoyé à l'utilisateur. Le résultat lui-même peut exister sous forme de texte ou d'image. Le type d'acte résultant est déterminé dans le programme lui-même et l'utilisateur ne sait pas à l'avance quel type de document il recevra en appelant le programme. Le programme serveur est appelé par l'adresse URL habituelle du programme ou du script lui-même. En règle générale, le réseau utilise des scripts avec les extensions .pl, php et cgi (les deux premiers programmes désignent Perl et PHP, mais la dernière extension peut être utilisée pour tous les modules exécutables, y compris Perl PHP et EXE). Par exemple, l'adresse URL http://www.rambler.ru/cgi-bin/top.cgi nécessite d'exécuter une sorte d'application top.cgi sur l'hôte rambler.ru et de transmettre également au client le résultat du travail de cette application (document ou image html, par exemple).

Mais à partir d'applications serveur, il serait un peu déroutant de ne pas pouvoir transmettre de paramètres. URL permet cela. Pour transférer des paramètres vers des applications serveur (elles sont également appelées passerelles ), un format de transfert de données appelé CGI (Common Gateway Interface) est utilisé. Ce format vous permet de définir les données d’entrée des programmes sur une seule ligne.

Dans l'exemple ci-dessus, l'URL appelle une passerelle de serveur appelée search.pl et lui envoie également un paramètre en tant que donnée d'entrée avec le nom utilisateur également spécifié par masha . La chaîne CGI disparaît-elle du nom du script avec une marque de tâche ? . Si le script doit passer plusieurs paramètres, ils sont répertoriés séquentiellement via le symbole perluète & , par exemple: http://rambler.ru/cgi-bin/perl/search.pl?user=masha&password=kasha .

Nous notons la particularité suivante: étant donné que la plupart des technologies WEB sont basées sur des formats de données textuelles, un problème précoce ou tardif consiste à distinguer les commandes des données. Ainsi, par exemple, si, en tant que paramètre CGI, nous souhaitons passer un paramètre d’ expression donné avec la valeur C = A + B : http://site.com/script.cgi?expression=C=A+B , une telle demande sera alors comprise de manière incorrecte par CGI, car l’autre le signe = sera interprété comme un séparateur entre le nom du paramètre et sa valeur. Par conséquent, dans le protocole CGI (ainsi que dans toute salle URL), un codage de caractères spécial est utilisé sous le nom URL Data Format . Cet encodage affiche les lettres de l'alphabet latin telles qu'elles sont et les caractères restants sont sous la forme de % nnnn est le code de caractère hexadécimal. Par exemple, le caractère de guillemet double ressemblera à % 22 , mais le caractère = à % 3D, à l' exception d'un caractère d'espacement qui, en plus du codage standard % 20 , peut être codé de la même manière avec le signe + . Ainsi, l'URL exemple suivant doit être écrit comme suit: http: // site .com / script.cgi? expression = C% 3DA% 2BB .

Protocole HTTP

HTTP (Hypertext Transfer Protocol) est le principal protocole utilisé sur le Web. Bien que le protocole soit désigné sous le nom de protocole de transfert hypertexte (c.-à-d. HTML), dès la leçon, le protocole HTTP peut être utilisé (et est utilisé) pour transférer la plupart des données du réseau. Ce transfert comprend également des fichiers texte et image. À mon avis, la popularité de HTTP est liée à plusieurs facteurs: il s’agit de l’adressage d’un URL assez universel, de la possibilité de transmettre des données (du client au serveur, et inversement), mais le travail est similaire en mode sans ligne (c.-à-d. Transfert de données directement entre le client est aussi un serveur, sans intermédiaires). Le protocole HTTP peut être appelé double, dans le sens où, dans un système client-serveur, les données peuvent se déplacer dans plusieurs directions, également d'un client à l'autre, d'un serveur à un autre. Pourtant, la syntaxe HTTP elle-même vise précisément à transférer des données du client au serveur.

Considérez donc l'exemple de requête HTTP le plus simple. Si nous tapons l'adresse http://yandex.ru dans la fenêtre d'adresse du navigateur, celui-ci déterminera l'adresse IP du serveur, yandex.ru enverra également au 80e port la requête HTTP suivante:

OBTENIR http://yandex.ru/ HTTP / 1.0
Accepter: image / gif, image / x-xbitmap, image / jpeg, image / pjpeg, application / vnd.ms-excel, application / msword, application / vnd.ms-powerpoint, * / *
Accepter-Langue: ru
Cookie: yandexuid = 2464977781018373381
Agent utilisateur: Mozilla / 4.0 (compatible; MSIE 5.5; Windows 98)
Hôte: yandex.ru
Référent: narod.ru
Proxy-Connection: Keep-Alive

La demande est transmise en texte brut. La toute première partie de la requête se trouve sur la première ligne: il s’agit du type de requête ( GET ), l’adresse URL du document demandé ( http://yandex.ru ) est également un type de protocole HTTP ( HTTP / 1.0 ). Voici les paramètres de la requête. Chaque ligne correspond à un paramètre. À la source de la chaîne, le nom du paramètre est déplacé, les deux points étant également la valeur du paramètre. La signification des paramètres est claire et intuitive, mais nous allons décrire les principaux: Accepter - le type de données que le navigateur peut accepter (en codage MIME). Accept-Language est la langue par défaut dans laquelle le navigateur souhaite recevoir des données. User-Agent - le type de programme qui a envoyé la demande. Hôte - Nom d'hôte DNS (ou IP) auquel la demande est adressée. Cookies - Cookies (données enregistrées par le serveur sur le disque local du client lorsque l'hôte a visité cet hôte). Le référant est un hôte, à partir de la page de laquelle nous envoyons une demande. Par exemple, si nous sommes sur la page http://narod.ru , nous cliquons également sur le lien http://yandex.ru . La demande sera envoyée à l'hôte yandex.ru. Cependant, le champ de requête du référent aura le nom d'hôte narod.ru.

Le jeu de paramètres de requête n'est pas fixe. En plus de ce qui précède, il peut également y avoir d'autres paramètres.

Les paramètres les plus intéressants tels que referer et cookie . Ces paramètres sont principalement utilisés pour identifier l'utilisateur par le serveur.

Une demande GET peut avoir des données envoyées par le client au serveur. ils sont transmis directement via l'URL à l'aide du protocole CGI. Ainsi, par exemple, pour entrer dans la discussion, le navigateur peut envoyer la requête suivante au serveur:

GET http://chat.ru/ ? Login = Algol & pass = Algol HTTP / 1.0
Accepter: image / gif, image / x-xbitmap, image / jpeg, image / pjpeg, application / vnd.ms-excel, application / msword, application / vnd.ms-powerpoint, * / *
Accepter-Langue: ru
Cookie: yandexuid = 2464977781018373381
Agent utilisateur: Mozilla / 4.0 (compatible; MSIE 5.5; Windows 98)
Hôte: yandex.ru
Référent: narod.ru
Proxy-Connection: Keep-Alive

Lors de l'observation de la chaîne de requête, le login contient également le mot de passe de l'utilisateur, transmis via la chaîne d'URL. Ce type de transfert de données vers le serveur est pratique, mais a une limite de capacité. Des ensembles de données extrêmement impressionnants ne peuvent pas être transférés via l'URL. À ces fins, il existe un autre type de demande: demande POST . Une requête POST est très similaire à GET , la seule différence étant que les données de la requête POST sont transmises séparément de l'en-tête de requête lui-même. Ainsi, l'exemple ci-dessus dans la version POST possède le formulaire:

POST http://chat.ru/ HTTP / 1.0
Accepter: image / gif, image / x-xbitmap, image / jpeg, image / pjpeg, application / vnd.ms-excel, application / msword, application / vnd.ms-powerpoint, * / *
Accepter-Langue: ru
Cookie: yandexuid = 2464977781018373381
Agent utilisateur: Mozilla / 4.0 (compatible; MSIE 5.5; Windows 98)
Hôte: yandex.ru
Référent: narod.ru
Proxy-Connection: Keep-Alive

login = Algol & pass = Algol

Lorsque nous observons les informations de connexion, le mot de passe est également transmis séparément dans le corps de la demande. Le corps de la demande doit disparaître de l'en-tête vide. Si le serveur rencontre une chaîne vide dans la demande POST , tout ce sur quoi il se déplace est considéré comme le corps de la demande (données transmises). Notez les points suivants: le format des données dans le corps de la demande POST est arbitraire. Bien que le format CGI soit le plus souvent utilisé, il n’est pas requis. De plus, la requête POST ne nécessite pas la présence du corps de la requête, elle peut également transmettre des données de manière similaire via une URL.

En plus du format CGI, il est parfois possible d'utiliser ce que l'on appelle des informations pour transférer des quantités impressionnantes d'informations (par exemple, des fichiers). format en plusieurs parties :

POST http://photo.bigmir.net/form.php HTTP / 1.0
Accepter: image / gif, image / x-xbitmap, image / jpeg, image / pjpeg, application / vnd.ms-excel, application / msword, application / vnd.ms-powerpoint, * / *
Référent: http://photo.bigmir.net/form.php
Accepter-Langue: ru
Type de contenu: multipart / form-data; frontière = --------------------------- 7d20345dc
Accept-Encoding: gzip, deflate
Agent utilisateur: Mozilla / 4.0 (compatible; MSIE 5.01; Windows 98)
Hôte: photo.bigmir.net
Proxy-Connection: Keep-Alive
Pragma: no-cache
Cookie: Ukrainien = 2; BSX_TestCookie = Oui; rich_ad = 1; b = 1

----------------------------- 7d20345dc
Contenu-Disposition: données de formulaire; name = "id"

254353
----------------------------- 7d20345dc
Contenu-Disposition: données de formulaire; nom = "d"

22
----------------------------- 7d20345dc
Contenu-Disposition: données de formulaire; name = "login"

Algol
----------------------------- 7d20345dc
Contenu-Disposition: données de formulaire; name = "passw"

Algol
----------------------------- 7d20345dc
Contenu-Disposition: données de formulaire; name = "email"

tps99@mail.ru
----------------------------- 7d20345dc
Contenu-Disposition: données de formulaire; name = "submit"

Ajouter
----------------------------- 7d20345dc--

Faites attention à la ligne d'en - tête Content-Type: multipart / form-data; frontière = --------------------------- 7d20345dc . Ce paramètre indique au serveur que le client transmet les données dans un format en plusieurs parties avec un limiteur --------------------------- 7d20345dc . Le limiteur est généré par le client de manière aléatoire est également nécessaire pour que le serveur puisse séparer les différents éléments envoyés dans le corps de la demande. Comme vous pouvez le constater, le corps contient plusieurs éléments transmis au format ASCII (et non au format Unicode si nécessaire pour CGI ), également séparés par la chaîne spécifiée dans le paramètre Content-Type . Chaque partage contient des informations sur le type de données transférées, ainsi que le nom de cette partie. Le confort du format multipart est que les données transmises ont une valeur illimitée et ne nécessitent également aucun codage préalable.

Outre les requêtes GET et POST, il en existe d'autres, par exemple TRACE , PUT . Mais ils sont rarement utilisés et nous ne nous attarderons pas dessus.

Une fois de plus, j'attirerai l'attention sur le fait que TOUTES les informations transmises par le client au serveur sont contenues dans l'en-tête et le corps de la demande. D'une autre manière, le serveur ne peut pas obtenir d'informations du client à l'aide du protocole HTTP.

D'autre part, le serveur peut également transférer des informations au client uniquement à titre d'objection à la demande. Tout échange de données dans le protocole HTTP est initié uniquement par le client, le serveur ne peut rien transmettre "de la sorte" mais uniquement à la demande du client.

Ainsi, si nous sommes en mesure de contrôler les demandes transmises, nous contrôlons entièrement les informations reçues par le serveur et le client. C'est pratique, car pour modifier les données transmises / demandées, il n'est pas nécessaire de changer les fichiers HTML des pages, changer les cookies, etc., il suffit simplement de modifier la requête HTTP et de l'envoyer au serveur. Mais ceci est une autre chronique :) ...