[ Accueil | Notions | Le protocole | Informations cachées | Scripts côté client | Le proxy | Squid et SquidGuard ]
Nous allons maintenant jouer un peu avec quelques possibilités qui font parfois peur...
Voici un exemple simple de ce qu'un serveur HTTP reçoit de votre part comme informations "cachées" :
| Votre Adresse IP : | 84.97.127.122 |
| Le port que vous utilisez : | 4096 |
| Le nom de votre machine telle qu'elle est connue sur le Net : | 84.97.127.122 |
| La façon dont vous vous présentez en tant que client HTTP : | Mozilla/4.5 (compatible; HTTrack 3.0x; Windows 98) |
| La version de protocole HTTP utilisée : | HTTP/1.1 |
| Votre navigateur accepte les types MIME suivants : | image/png, image/jpeg, image/pjpeg, image/x-xbitmap, image/svg+xml, image/gif;q=0.9, */*;q=0.1 |
|
Notez un comportement un peu particulier d'Internet Explorer qui n'indique pas systématiquement tous les types MIME acceptés. Vous ne verrez peut-être q'un simple "*/*" |
|
| Le document qui vous a conduit jusqu'ici : | http://christian.caleca.free.fr/http/ |
Il est intéressant de pouvoir visualiser cette page avec divers navigateurs. Ces informations sont transmises à chaque requête, ou presque, au serveur HTTP.
Pas le moins du monde. Cette page est dynamique. Une partie des informations qu'elle contient est construite à la volée par le serveur, avant de vous l'envoyer. La technologie utilisée est ici PHP, comme le montre l'URI de cette page. Dans le tableau ci-dessus, la partie dynamique est constituée par les variables d'environnement que votre navigateur envoie à chaque commande GET.
PHP n'est qu'un moyen de construire une page HTML dynamique qui vous renvoie ces informations, ça aurait aussi pu être fait avec un CGI (dans les limites de ce que permet l'hébergeur).
Si vous regardez le "source" de cette page, vous n'y trouverez que du HTML
Les formulaires ont pour but de permettre au client d'envoyer des données au serveur. A charge pour lui de les traiter correctement.
Un formulaire peut envoyer ses données de deux manières :
Avec cette méthode, les données sont envoyées dans l'URI de la page qui sera appelée lorsque vous cliquerez sur "envoyer".
Dans le formulaire ci-dessous :
A première vue, les données sont envoyées de façon "invisible".
Dans le formulaire ci dessus :
Un cookie, c'est un petit fichier qu'un serveur HTTP peut écrire (et lire) sur votre machine par l'intermédiaire de votre navigateur. L'objectif initial n'est en rien malicieux et peut même vous rendre service. Nous l'avons déjà vu, HTTP ne gère pas le concept de session. Une session, c'est une période pendant laquelle un certain contexte reste constant, même si vous y faites des choses différentes. Par exemple, vous entrez dans un lieu protégé par une porte fermant à clé. Vous ouvrez cette porte au moyen de la clé. Une fois rentré dans ce lieu, vous pouvez y faire tout ce qui est autorisé et vous n'aurez plus besoin de la clé, jusqu'à ce que vous soyez sorti.
HTTP ne sait pas faire cela et ne conserve aucune mémoire du passé si ce n'est l'URI de la page d'où vous venez. C'est un peu faible, surtout si l'on doit gérer des identifications de personnes, par exemple. Dans ces cas là, un cookie permettra de contourner le problème en permettant au serveur de retrouver à chaque page des informations écrites dans ce cookie.
Le formulaire suivant vous permet de saisir une information dans un formulaire et de l'envoyer avec la méthode POST (ça aurait été pareil avec la méthode GET, d'ailleurs).
La différence par rapport aux exemples précédents, c'est que la page qui va être appelée à l'envoi des données de ce formulaire va écrire un cookie contenant cette donnée sur votre machine (sauf si vous avez interdit à votre navigateur d'accepter les cookies).
Nous avons vu quelques exemples de ce que l'on peut faire avec :
Nous n'avons pas vu ce que pourrait faire un script CGI, mais ce serait du même ordre. Toutes ces démonstrations sont donc axées sur du "server side". Le client envoie les données et reçoit du HTML statique. C'est le serveur qui traite les données reçues et agit en fonction.
La page suivante va vous donner quelques exemples simples de Java scripts qui s'exécutent côté client, donc sur votre machine.