IV. Divers▲
IV-A. Le cache : qu'est-ce que c'est ?▲
Afin de réduire la bande passante utilisée, le protocole HTTP met à disposition des clients le support d'un mécanisme de sauvegarde des données. Ainsi, sous certaines conditions, les clients sont autorisés à stocker les réponses du serveur afin de ne pas devoir redemander toute la page au serveur. Tout un ensemble d'en-têtes tant pour les requêtes que pour les réponses est dédié à cette gestion. De plus, le rôle de la méthode HEAD entre exclusivement dans ce cadre.
IV-B. Et PHP/ASP/JSP/les CGI dans tout ça ?▲
PHP, ASP, JSP et les CGI (aussi bien les scripts CGI et les CGI-bin) sont des langages ou des applications côté serveur, c'est le serveur et LUI SEUL qui se doit de les gérer. Il peut leur permettre d'interférer avec la réponse HTTP envoyée, via les headers ou le corps par exemple, mais cela relève de sa seule responsabilité et doit être transparent pour le client.
IV-C. Et (D)(X)HTML/JavaScript/ActiveX dans tout ça ?▲
(D)(X)HTML, JavaScript, ActiveX, CSS, etc. sont des langages ou des applications côté client, ils sont contenus dans le corps de la réponse HTTP et doivent être transparents pour le serveur. Ils ne peuvent normalement pas interférer avec le protocole HTTP puisqu'ils entrent en jeu après réception de la réponse par le client. Cependant, ils peuvent parfois interférer sur la création de la requête (formulaires (X)HTML) ou sur l'utilisation de l'échange HTTP (AJAX).
IV-D. Une connexion = Un échange ?▲
En théorie : OUI !
Ensuite, HTTP propose des mécanismes d'optimisation qui permettent de conserver la connexion entre le serveur et le client. Ainsi, nous pouvons charger des ressources annexes ou faire d'autres requêtes HTTP, car la mise en place d'une connexion est relativement coûteuse (surtout en temps d'exécution). Dans ce cas encore, ce sont des en-têtes spécifiques qui sont chargés de la gestion de cette connexion.
IV-E. Les cookies : le clignotant du Web ?▲
La gestion des cookies est assez complexe.
Côté client, on peut, en théorie, y accéder en permanence puisque c'est là qu'ils sont stockés.
Côté serveur, le comportement doit être étudié au cas par cas : configuration du client, configuration du serveur, langage utilisé côté serveur, configuration du module coté serveur sont autant de paramètres qui peuvent influer sur leurs réactions.
IV-F. Voir le protocole HTTP▲
Si vous souhaitez tester le protocole HTTP par vous-même, vous pouvez utiliser telnet. Ce programme est disponible sur la plupart des plates-formes. Pour cela, faites :
telnet {nom de domaine} 80Puis tapez votre requête. En théorie, vous devriez voir votre requête arriver.
IV-G. Voir aussi▲
Voici des ressources disponibles sur le protocole HTTPÂ :