Le Protocole HTTP


précédentsommaire

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ées 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 plate-formes. Pour celà faites :

 
Sélectionnez
telnet {nom de domaine} 80

Puis 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 :

précédentsommaire

Vous avez aimé ce tutoriel ? Alors partagez-le en cliquant sur les boutons suivants : Viadeo Twitter Facebook Share on Google+   

  

Copyright © 2006 Mathieu Lemoine. Aucune reproduction, même partielle, ne peut être faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.