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

Protocole HTTP

Pour la source, découvrons par nous-mêmes quel est le protocole général. Un protocole est un certain ensemble de règles également de signes clés, conçu pour la communication entre les périphériques. Il est nécessaire que les ordinateurs ou leurs éléments soient reconnus sans ambiguïté par un ami d'un ami.

Protocole - une discussion sur les ordinateurs du réseau.

En fait, tout ensemble de commandes peut être appelé un protocole, mais dans la pratique, le concept de protocole ne s'applique qu'aux soi-disant protocoles réseau, à savoir les langues des ordinateurs d'un réseau. Chaque protocole a un objectif spécifique et est pris en charge par un logiciel spécialisé.

URL, adresses IP et DNS, domaines

Donc, URL (Uniform Resource Locator) est l’ itinéraire complet du document . URL est l'adresse où il est permis de rechercher sans ambiguïté un document (fichier) sur Internet. La ligne que vous tapez dans la case "adresse" de votre navigateur contient également l'adresse URL du document.

Une URL peut avoir un aspect plutôt sophistiqué et se composer de plusieurs parties. Pour commencer, considérez 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, ainsi que le nom de l'acte lui-même (nom de fichier et extension). La base (et le seul partage requis pour le protocole http) de l'adresse est le nom d'hôte. Il définit la machine sur laquelle l'acte est situé (sur un réseau, des 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 et é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 .

Toutefois, dans la 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 (DNS) a été introduit, dans lequel chaque adresse IP se voit attribuer le rapport d’un nom composé de lettres ou de chiffres. Ainsi, par exemple, dans l'exemple DNS ci-dessus, le nom était rambler.ru et l'adresse IP 217.73.192.109 lui correspond également .

Il est à noter que différents noms DNS correspondent presque toujours à différentes adresses IP, mais que les mêmes adresses IP peuvent correspondre à différents noms DNS. Par exemple, des noms DNS différents tels que www.rambler.ru et rambler.ru en ont un qui a également une adresse IP. Dans les URL, il est autorisé d'utiliser à la fois les noms DNS et les adresses IP. Ainsi, les deux URL http://rambler.ru/index.html sont également http://217.73.192.109/index.html sont équivalentes. Certaines méthodes permettant de définir l'adresse IP sont décrites ici http://www.xakep.ru/post/11980/default.htm .

Notez également que, en principe, un hôte ne doit pas posséder de nom de domaine. En d'autres termes, certains hôtes ne sont autorisés à accéder que par adresse IP.

Vous avez probablement déjà veillé à ce que tout nom DNS se compose de mots séparés, séparés par des points. Chaque nom signifie individuellement le domaine auquel appartient l'hôte. L'ensemble du système DNS est construit sur une base hiérarchique. Tous les domaines du 1er niveau (com, org, ru, etc.) sont inclus dans le domaine racine du 0e niveau (qui n’est généralement pas écrit dans le système DNS, comme cela est implicite par défaut). Les domaines d'un autre niveau (par exemple, rambler, mail ou kiev) entrent également dans les domaines de niveau principal, etc. Les domaines dans DNS sont enregistrés de droite à gauche, dans l'ordre croissant des niveaux.

Nous notons deux caractéristiques importantes: 1. Un 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 par base géographique ou cible et n’a également aucun rapport avec le périphérique physique d’Internet.

Dans l'exemple d'URL fourni, nous définissons explicitement le nom de la loi index.html qui nous intéresse, mais sur chaque site, un document s'ouvre 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 Web sans spécifier le nom de fichier dont nous avons besoin, le serveur ouvrira automatiquement l'acte par défaut pour nous. Ainsi, l'adresse http://crackchat.h1.ru est équivalente à l'adresse http://crackchat.h1.ru/index.html . Tout comme il existe un fichier ouvert par défaut, il existe également un dossier par défaut. Sur la plupart des serveurs, le dossier par défaut des documents HTTP possède le nom WWW .

Après DNS, le nom de l'acte auquel nous faisons référence suit dans l'adresse URL. Cela implique que ce fichier se trouve dans le dossier racine. Si tel n'est pas le cas, nous pouvons indiquer l'itinéraire rempli pour l'acte, en répertoriant les sous-dossiers par le biais d'une barre oblique directe:

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 fier de prendre en compte les éléments suivants: étant donné que la plupart des serveurs Web reposent sur des systèmes de type UNIX, vous devez tenir compte de la différence entre les majuscules et les minuscules lors du routage. 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 minuscules se produit uniquement dans la route menant au fichier, alors que DNS est insensible à la casse (alors RAMBLER.RU équivaut à manger l'adresse rambler.ru ).

Comme indiqué précédemment, 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 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 par exemple de la manière suivante: h1.ru/crackchat/ ou h1.ru/crosswords/ . L'outil d'accès (via un domaine de troisième niveau ou via un chemin d'accès au disque) est déterminé par les paramètres du serveur.

Le dossier racine est également considéré comme un domaine, ce qui explique également pourquoi la plupart des URL peuvent être spécifiées dans deux formats différents: à la fois avec le domaine www (par exemple www.crackchat.h1.ru ) et également sans celui-ci ( crackchat.h1.ru ). Dans ce cas, le serveur est de toute façon vous dirige automatiquement vers le dossier www, car il est accepté par défaut.

Protocoles, ports, protocole CGI

Comme nous l’avons déjà vu, l’adresse URL se compose de trois éléments principaux: le nom DNS, l’itinéraire du fichier et le nom du protocole. Si les deux premiers éléments vous permettent de localiser le document, le protocole détermine comment accéder au document. En d'autres termes, à quel moment le client essaie de recevoir 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, dont les plus courants sont http (protocole de transfert hypertexte - protocole de transfert de fichiers hypertexte), ftp (protocole de transfert de fichier - protocole de transfert de fichiers), mailto (préfixe d'une famille de protocoles de messagerie), fichier (protocole d'accès de fichier). 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 , les fichiers aussi en ftp , mais ne peut pas fonctionner avec le protocole mailto . Par conséquent, si vous tapez dans votre navigateur, dans la ligne d'adresse mailto: microsoft.com , un programme de messagerie spécial pouvant fonctionner avec ce protocole va démarrer (par exemple, Outlook Express ou The Bat!). Le nom du protocole est indiqué par le plus important dans l'URL qui doit également se terminer par un deux-points. Le registre n'a pas d'importance du tout.

Parmi les protocoles, il y en a de très bizarres, par exemple, le protocole ou le protocole (pour vous amuser, vous pouvez entrer l'adresse à propos de: <a href="mailto:bill@microsoft.com"> envoyer des salutations à Bill </a> dans la barre d'adresse du navigateur. :) . Un autre protocole ldap intéressant (essayez par exemple ldap: //microsoft.com ).

Tous les protocoles ne peuvent pas agir en tant que protocole pour une URL. Puisque les protocoles about ou javascript n’ont rien à voir avec l’itinéraire complet du document, également parce que les URL associées à ces protocoles ne sont pas du tout des URL.

Le préfixe de protocole indique au client dans quel "langage" la communication avec le serveur commencera. 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 à «nous parler» dans le langage de protocole requis, il (le serveur) est obligé d'exécuter le programme approprié qui comprendra ce protocole. Pour résoudre ce problème, utilisez les ports . Par conséquent, si le nom DNS ou l'adresse IP détermine la machine à laquelle nous avons accès, le port détermine le programme auquel nous avons accès sur cet hôte. Les ports sont indiqués par un entier allant de 0 à 65535.

Chaque protocole se voit attribuer un port par défaut via 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 des clients sur le port 80 (ce port est accepté par défaut pour le protocole http ). Si cet hôte bla bla prend également en charge 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 également autorisé à spécifier explicitement. Le numéro de port est indiqué par deux points après le nom DNS ou l'adresse IP:

Dans l'exemple donné, nous nous tournons vers un certain programme "raccroché" sur le port 8080 , nous lui demandons également de nous fournir le fichier index.html via le protocole http . S'il n'existe aucun programme de ce type sur le serveur (aucun programme ne suivra les demandes du port 8080 ), le navigateur nous indiquera le mauvais URL.

Comme 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 tenus de prendre en charge http sur le 80e port. 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 spécifier explicitement le numéro de port sans escale: http://rambler.ru//128

Lors de l'accès au serveur, il est parfois nécessaire d'indiquer, en plus de l'adresse de l'acte, l'ID utilisateur, qui 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 transférer de telles informations. Pour ce faire, mettez un signe @ devant le nom DNS, avant lequel le nom d'utilisateur est indiqué:

En règle générale, pour le protocole http , l'authentification de l'utilisateur n'est pas obligatoire, mais pour les protocoles tels que ftp ou mailto, elle est obligatoire. En plus du nom d'utilisateur, il est également possible de spécifier un mot de passe d'accès. Le mot de passe n'est plus un colon. 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 masha avec le mot de passe kasha . Mais une telle adresse mailto: //masha@mail.ru est utilisée pour accéder à la boîte aux lettres de l'utilisateur masha dans l'hôte mail.ru.

Le nom d'utilisateur peut également exister pour un principe de domaine et se composer de divers éléments séparés par un point. Par exemple, mailto: //bill.geits@microsoft.com .

Comme déjà mentionné, une URL est un itinéraire de document rempli. Un acte désigne tout fichier pouvant exister également en texte (fichiers HTML, doc ou pdf, par exemple), ainsi qu’une image (jpg ou gif), ainsi qu’un programme. Dans le même temps, le protocole http implique que si un texte ou une image est demandé dans l'URL, ils doivent être transmis à l'utilisateur pour pouvoir les afficher dans son navigateur. Toutefois, si un programme ou un script est demandé, il doit être exécuté sur le serveur et le résultat de son travail doit également être envoyé à l'utilisateur. Le résultat lui-même peut exister dans le texte ou dans une image. Le type de l'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 du serveur est appelé par l'adresse URL habituelle du programme ou du script. En règle générale, les scripts portant les extensions .pl, .php et cgi sont utilisés sur le réseau (les deux premiers sont des programmes écrits en Perl et PHP, cependant, la dernière extension peut être appliquée à tous les modules exécutables, y compris PHP et EXE pour Perl). Par exemple, l'URL http://www.rambler.ru/cgi-bin/top.cgi requiert l'exécution d'une certaine application top.cgi sur l'hôte rambler.ru et le transfert du résultat de cette application vers le client (par exemple, un document ou une image HTML).

Mais les applications de serveur seraient un peu inutiles si les paramètres ne pouvaient pas leur être transmis. L'URL le permet. 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 spécifier les données d'entrée des programmes sur une seule ligne.

Dans l'exemple ci-dessus, on peut voir que l'URL appelle une passerelle de serveur appelée search.pl le transmet également en entrée au même paramètre portant le nom utilisateur, en terminant également par masha . Une chaîne CGI supprime-t-elle le nom du script en tant que signe de tâche ? . Si un script doit transmettre plusieurs paramètres, ils sont répertoriés séquentiellement dans le symbole et commercial, 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 texte, le problème de distinguer les commandes des données se pose tôt ou tard. Ainsi, par exemple, si nous voulons passer un paramètre d' expression avec la valeur C = A + B en tant que paramètre CGI: http://site.com/script.cgi?expression=C=A+B, une telle demande sera mal comprise par CGI, car une autre le signe = sera perçu comme un séparateur entre le nom du paramètre et sa valeur. Par conséquent, un codage de caractères spécial appelé URL Data Format est utilisé dans le protocole CGI (ainsi que dans les locaux d'une URL). Cet encodage affiche les lettres de l'alphabet latin telles qu'elles sont et les caractères restants sous la forme de % nnnn est le code hexadécimal du caractère. Par exemple, le guillemet double " ressemblera à % 22 , mais le symbole = similaire à % 3D . Le caractère d’espace constitue une exception. En plus du codage standard % 20 , il peut être codé de la même manière avec + . L’exemple d’URL doit donc ê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. Malgré le fait que le protocole s'appelle le protocole de transfert hypertexte (HTML), dans 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 du texte et des images, ainsi que des fichiers. À 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 transférer des données (du client au serveur ou inversement). Toutefois, le travail est similaire en mode sans ligne (transfert direct de données entre le client est aussi un serveur, sans intermédiaires). Le protocole HTTP peut être appelé double, en ce sens que dans un système client-serveur, les données peuvent se déplacer dans des paires de directions et que, d'un serveur à l'autre, elles peuvent également être inversées d'un serveur à un autre. Néanmoins, la syntaxe HTTP vise spécifiquement à transférer des données du client au serveur.

Examinons donc l'exemple de requête HTTP le plus simple. Si, dans la fenêtre d'adresse du navigateur, nous tapons l'adresse http://yandex.ru , le navigateur déterminera l'adresse IP du serveur. Yandex.ru lui enverra également la requête HTTP suivante sur le port 80:

GET 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 sous forme de texte non crypté. La toute première partie de la requête se trouve à la première ligne: il s’agit du type de requête ( GET ), l’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. Le nom du paramètre se déplace à la source de la ligne, puis les deux points définissent également la valeur du paramètre. La signification des paramètres est claire, 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 préférée 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 stockées par le serveur sur le disque local du client lors de la dernière visite de cet hôte). Référent - l'hôte à partir duquel nous envoyons la demande. Ainsi, 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, mais le champ de demande de référent aura le nom d'hôte narod.ru.

L'ensemble des paramètres de requête n'est pas fixe. Outre ce qui précède, d'autres paramètres peuvent également être présents.

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

Une demande GET peut avoir des données transmises 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

Nous observons que la chaîne de requête contient le nom d'utilisateur et le mot de passe de l'utilisateur, transmis via la chaîne d'URL. Ce type de transfert de données sur le serveur est pratique, mais sa capacité est limitée. Des ensembles de données extrêmement impressionnants ne peuvent pas être transmis via des URL. À ces fins, il existe un autre type de demande: une demande POST . La requête POST est très similaire à la requête 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 a la forme suivante:

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 devrait tomber de la chaîne vide de l'en-tête. Si le serveur rencontre une chaîne vide dans une requête POST , tout ce qui continue à avancer est considéré comme le corps de la requête (données transmises). Notez les points suivants: le format des données dans le corps de la demande POST est arbitraire. Malgré le fait que le format CGI le plus couramment utilisé, il n’est pas requis. En plus de la requête POST , elle ne nécessite pas la présence d'un corps de requête, elle peut également transmettre des données de manière similaire via une URL.

En plus du format CGI, parfois le soi-disant 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--

Occupons-nous de la ligne d'en - tête Content-Type: multipart / form-data; frontière = --------------------------- 7d20345dc . Ce paramètre indique au serveur que le client transmet des données au format multipart avec un délimiteur --------------------------- 7d20345dc . Un limiteur généré aléatoirement par le client 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 ) sont également séparés par la ligne spécifiée dans le paramètre Content-Type . Chaque partage contient des informations sur le type de données transmises, ainsi que le nom de cette partie. Le confort du format multipart est que les données transmises sont illimitées et ne nécessitent pas de codage préalable.

Outre les demandes GET , il existe également des demandes POST , telles que TRACE , PUT . Mais ils sont rarement utilisés et nous ne nous attarderons pas dessus.

Une fois encore, j’attirerai votre 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 en aucun cas recevoir d'informations du client via le protocole HTTP.

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

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