Web HTTP

Le Protocole HTTP
par Mathieu Lemoine
Date de publication : 25/06/2006 Dernire mise jour : 09/10/2006
Protocole parmi les plus courants, le protocole HTTP est trs souvent mconnu pour ne pas dire inconnu des webmasters et des dveloppeurs d'applications Web en gnral. Ce tutoriel vous aidera acqurir les connaissances de base (ainsi que certaines autres plus avances) concernant ce protocole.
Le Protocole HTTP par Mathieu Lemoine
Notes Remerciements Introduction I - Gnralits I-A - Prsentation I-B - Structure I-C - Caractres Interdits ou Rservs I-D - L'URL-Encoding II - Les Requtes HTTP II-A - La ligne d'Introduction La Mthode La Page La Version Les Mthodes II-B - Les en-ttes de requte II-C - Le corps de la requte III - Les Rponses HTTP III-A - La ligne d'Introduction Informations : les 1xx Succs : les 2xx Redirection : les 3xx Requte Invalide : les 4xx Erreur Serveur : les 5xx D'autres codes status III-B - Les en-ttes de rponse IV - Divers IV-A - Le cache : qu'est-ce que c'est ? IV-B - Et PHP/ASP/JSP/les CGI dans tout a ? IV-C - Et (D)(X)HTML/JavaScript/ActiveX dans tout a ? IV-D - Une connexion = Un change ? IV-E - Les cookies : le clignotant du Web ? IV-F - Voir le protocole HTTP IV-G - Voir aussi
-2Copyright 2006 - Mathieu Lemoine. Aucune reproduction, mme 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' 3 ans de prison et jusqu' 300 000 E de domages et intrts.
http://mathieu-lemoine.developpez.com/tutoriels/web/http/
Notes Remerciements
Merci Yogui et neguib pour leurs relectures et leurs conseils.
Introduction
Cet article prsente le protocole HTTP (HyperText Transfert Protocole) d'une manire simple et, normalement, comprhensible pour n'importe qui ayant un minimum de connaissances en matire de Thorie des Rseaux Informatiques (notamment la structure client/serveur, changes binaires/changes textes, ...). Sur l'Internet, de nombreux protocoles sont utiliss. Le protocole HTTP est l'un des plus courants. C'est notamment celui qui est utilis pour la navigation sur les sites Web. Par exemple, si vous lisez actuellement la version en ligne de cet article, votre navigateur a eu recours au protocole HTTP pour rcuprer la page Web, les diffrentes images, feuilles de styles, etc. Ce protocole est relativement simple dans sa forme et ses utilisations fondamentales devraient tre connues de tous les dveloppeurs Web.
I - Gnralits I-A - Prsentation

Il s'agit d'un protocole reposant sur un unique change initi par le client. Il est synchrone : le serveur ne peut commencer rpondre avant que le client ait fini d'envoyer la requte. Il en existe trois versions : 0.9 (1991), 1.0 (fvrier 1997) et 1.1 (octobre 2000). La version 0.9 est compltement obsolte et nous ne l'tudieront pas ici. De nos jours, la version 1.0 est trs rarement utilise ; elle est d'ailleurs obsolte. Les principaux changements entre les versions 1.0 et 1.1 sont l'ajout de 2 types de requtes ainsi que la possibilit d'hberger plusieurs sites Web sur un mme serveur dans la version 1.1. L'change entre le client et le serveur se fait en mode texte. Le charset gnralement utilis est l'US-ASCII sur 8 bits. Il est cependant possible que cet encoding soit modifi selon le client ou le serveur.
I-B - Structure
Les requtes et les rponses sont bties sur le mme modle :
{Ligne d'introduction}{SEP} {En-ttes spares par des {SEP} } {SEP}{SEP} {Corps}
En thorie, le seul lment capable de diffrencier une requte d'une rponse, c'est la Ligne d'introduction. En fait, certaines en-ttes sont plutt caractristiques des requtes, tandis que d'autres sont plutt utilises pour les rponses. Les requtes ont cette forme :
{Nom}{HSEP}{Valeur}
Le sparateur HSEP reprsente la combinaison deux points + espace ": ". Le protocole HTTP dfinit un ensemble d'en-ttes standard. Des en-ttes supplmentaires peuvent tre ajoutes, la condition que leur nom commence par "X-".
I-C - Caractres Interdits ou Rservs

Certains caractres sont interdits ou rservs certains endroits du message : nom du caractre retour chariot (Carriage Return, CR) Son utilisation l'intrieur de la Ligne d'Introduction et des en-ttes est donc interdite. Il fait partie du sparateur SEP. code US-ASCII 0x0D (13) notation courante \r rserves et interdictions Il fait partie du sparateur SEP.
nouvelle ligne (New Line ou Line Feed,
0x0A (10)
\n
nom du caractre LF)
code US-ASCII
notation courante
point d'interogation
0x3F (63)
rserves et interdictions Son utilisation l'intrieur de la Ligne d'Introduction et des en-ttes est donc interdite. Il est utilis certains endroits de la Ligne d'Introduction. Son utilisation l'intrieur de celle-ci est donc rglemente. Il est utilis certains endroits de la Ligne d'Introduction. Son utilisation l'intrieur de celle-ci est donc rglemente. Il est utilis certains endroits de la Ligne d'Introduction. Son utilisation l'intrieur de celle-ci est donc rglemente. Il est utilis certains endroits de la Ligne d'Introduction. Son utilisation l'intrieur de celle-ci est donc rglemente. Il est utilis dans le cadre de l'URL-Encoding. Son utilisation l'intrieur de celui-ci est donc rglemente. Il sont utiliss dans les en-ttes. Son utilisation l'intrieur de celles-ci est donc rglemente. Il est utilis dans la Ligne d'Introduction et les en-ttes. Son utilisation l'intrieur de celles-ci est donc rglemente.
gal
0x3D (31)
esperluette (et commercial)
0x26 (38)
&
dise
0x23 (35)
pourcentage
0x25 (37)
deux points
0x3A (58)
espace (Space, SP)
0x20 (32)
' ' ou " "
Le sparateur SEP correspond en fait au duo "\r\n" (Carriage Return, New Line : CRLF)
I-D - L'URL-Encoding
L'URL-Encoding permet d'insrer les caractres rservs, ou des caractres accentus, dans certaines parties des messages HTTP. Cet encodage consiste simplement remplacer un caractre interdit par : le caractre pourcentage suivi des deux caractres reprsentant le code hexadcimal US-ASCII du caractre remplacer. Exemple : le sparateur SEP (\r\n) deviendrait : %0D%0A Pour dcoder une chane URL-Encode, il suffit de remplacer le triplet %?? par le caractre dont le code US-ASCII correspond.
II - Les Requtes HTTP

Ds que le client est connect au serveur, il envoie sa requte. C'est en ce sens que l'change est initi par le client. Nous allons voir les spcificits des requtes HTTP.
II-A - La ligne d'Introduction

Comme prcis auparavant, le seul point qui change catgoriquement entre requte et rponse HTTP, c'est cette Ligne d'Introduction. Voici la forme qu'elle a pour une requte :
{Mthode}{SP}{Page}{SP}{Version}
Le sparateur SP correspond l'espace.
La Mthode
GET HEAD POST PUT DELETE OPTIONS TRACE CONNECT
On parle aussi parfois de type de requtes. Les Mthodes autres que GET et POST sont propres la version 1.1 de HTTP. Ces mthodes seront dtailles un peu plus loin.
La Page
Le spcificateur Page dsigne le chemin vers la ressource charge de traiter, ou de correspondre la requte partir de la racine du site. Il doit commencer par un slash (/) et la chane doit tre URL-Encode. Les paramtres d'URL (paramtres GET) L'identificateur de fragment (fragment identifier)
Les paramtres d'URL sont indiqus avec cette syntaxe :

{Nom}{EQ}{Valeur}
Le Nom et la Valeur sont URL-Encods. Forcment, il n'y a pas d'espace. Le sparateur EQ correspond au caractre gal. Chaque paramtre est spar du suivant par un esperluette. La chane ainsi forme est place la suite du chemin, le tout tant spar par un point d'interrogation. Le fragment identifier permet de dsigner une partie prcise du document. Il n'a pour le moment que peu (voire pas) de signification pour le serveur, car il est surtout utile au client. Par exemple, c'est lui qui est utilis pour dsigner une ancre dans un document HTML. Le langage XPointer est prvu pour tre notamment utilis dans le fragment identifier. Il doit galement tre URL-Encod. Il est ajout la suite des paramtres d'URL (ou du chemin s'il n'y a pas de paramtre d'URL) et il en est spar par un dise.
La Version
HTTP/1.0 pour la version 1.0 HTTP/1.1 pour la version 1.1
Les Mthodes
Nous allons maintenant voir un peu plus en dtail les 4 mthodes proposes par la version 1.1 du protocole HTTP. Les informations sur les mthodes GET et POST sont galement valables pour la version 1.0. GET Cette mthode est la plus courante, il s'agit normalement d'une simple requte de tlchargement d'un document. Deux requtes GET portant sur le mme document devraient retourner des rponses smantiquement identiques (certaines en-ttes pouvant influer sur le comportement du serveur, les rponses peuvent ne pas tre totalement identiques). Aucune donne traiter ne peut tre envoye au serveur par cette mthode. Il est par contre possible d'ajouter les paramtres d'URL (aussi nomms paramtres GET). Le corps de la requte DOIT tre vide, et le document spcifi dans la requte (la Page) est celui qui doit tre retourn.
HEAD Cette mthode est similaire et presque quivalente la mthode GET. C'est en fait la rponse finale du serveur qui est tronque. La rponse une requte HEAD est la rponse la requte GET qui lui est similaire, sauf que le corps de la rponse HTTP n'est pas transmis. Cela permet souvent d'conomiser beaucoup de bande passante.
POST
La Mthode POST est la mthode de base pour demander un traitement d'informations au serveur. Ces requtes sont censes mettre en jeu des mcanismes propres au serveur et provoquant des communications avec d'autres modules, voire d'autres serveurs, pour effectuer le traitement des dites donnes. De ce fait, il est tout fait probable que deux requtes POST identiques reoivent des rponses diffrentes ou mme smantiquement opposes. Les donnes traiter sont spcifies dans le corps de la requte. Le document dsign par la requte via la page est la ressource qui doit traiter les donnes et gnrer la rponse.
PUT et DELETE Ces mthodes sont censes permettre l'upload (le chargement sur le serveur) ou la suppression d'un document sans passer par un serveur FTP ou autre. Bien videmment, cela peut provoquer des remplacements de fichiers, et donc de trs grosses failles de scurits sur un serveur. De ce fait, la plupart des serveur Webs requierent une configuration spciale indiquant une ressource ou un document charg de traiter ces requtes. Le document dsign par la requte est celui qui doit tre remplac (ou cr), et le contenu du document est dans le corps de la requte. En thorie, les paramtres d'URL et le fragment identifier devraient tre interdits ou ignors par le serveur. En pratique, ils sont gnralement transmis la ressource charge de traiter la requte.
OPTIONS et TRACE Ces mthodes permettent au client de demander certaines informations sur le serveur. Tous les serveurs ne les implmentent pas forcment.
CONNECT Cette mthode est cense tre utilise pour demander une utilisation du serveur en tant que proxy. Tous les serveurs ne les implmentent pas forcment.
II-B - Les en-ttes de requte

Nous allons ici prsenter certaines en-ttes utilises dans les requtes HTTP. Elles ne sont pas forcment spcifiques aux requtes, mais ont une signification particulire dans le cadre d'une requte. Host Cette en-tte est la seule obligatoire pour les requtes HTTP/1.1, c'est elle qui permet d'hberger plusieurs sites Web sur un mme serveur.
Sa valeur est le domaine du site Web. Elle est gnralement spcifie juste aprs la Ligne d'Introduction.
User-Agent Cette en-tte permet d'indiquer la signature du programme effectuant la requte. C'est une chane de caractres qui permet d'identifier le programme. En gnral, il s'agit du nom complet du programme et de sa version.
Content-type et Content-length Ces deux en-ttes ne peuvent tre spcifies que dans le cadre d'une requte POST ou PUT. Elles indiquent respectivement le type MIME et la taille en octets du corps de la requte. Si elles ne sont pas spcifies, c'est le serveur qui est seul responsable de leur ventuelle valeur par dfaut.
Cookie Cette en-tte permet au client de fournir un cookie au serveur. Sa valeur est simplement le nom et la valeur du cookie, spars par un gal.
D'autres en-ttes De nombreuses autres en-ttes ont t prvues dans le protocole HTTP. Elles servent par exemple prciser la gestion du cache, la langue ou le format prfr pour la rponse, l'authentification du client, etc. Les Requests For Comments (RFC) du protocole HTTP vous fourniront toutes les en-ttes [pour ses versions 1.0 et 1.1]. Toute en-tte non reconnue par le serveur doit thoriquement tre ignore.
II-C - Le corps de la requte

Le corps de la requte doit tre vide pour les requtes GET, HEAD, DELETE, CONNECT, TRACE et OPTIONS (dans le dernier cas, il est laiss ventuellement rempli pour de futures versions du protocole HTTP). Dans le cas des requtes POST et PUT, il correspond aux donnes traiter. Il n'y a pas de caractres rservs ou interdits dans le corps de la requte au niveau du protocole HTTP. Cependant, les donnes doivent tre conformes au format attendu par la ressource responsable de leur traitement.
- 10 Copyright 2006 - Mathieu Lemoine. Aucune reproduction, mme 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' 3 ans de prison et jusqu' 300 000 E de domages et intrts.
III - Les Rponses HTTP

Quand le serveur a fini de recevoir la requte, il la traite et renvoie la rponse approprie (ventuellement une erreur). Les rponses sont bties sur un modle similaire celui des requtes. Voyons leurs spcificits.
III-A - La ligne d'Introduction

Les lignes d'Introduction des rponses HTTP ont une structure plus simple que celle des requtes, mais tout aussi riches en informations. Le format est :
{Version}{SP}{Code Status}{SP}{Phrase Status}
La Version est la mme que pour la requte. Le Code Status est un code sur trois chiffres qui indique le status de la requte. Nous y reviendrons plus tard. Le sparateur SP est un espace. La Phrase Status est simplement une phrase permettant de rendre le status plus lisible pour un humain. Elle est purement indicative et n'a aucune valeur informative sur le plan du protocole, elle est d'ailleurs facultative. Nous indiquerons cependant les Phrases Status (Reason Phrase) proposes par les RFC pour les codes que nous dtaillerons. Les Codes Status sont regroups en familles, qui sont au nombre de cinq pour les versions 1.0 et 1.1 de HTTP. La famille est indique par le premier chiffre du code (celui des centaines), il va de 1 5. Tout code inconnu doit tre trait par le client comme le code de base de la famille (X00) et tre prsent l'utilisateur. Si la famille est inconnue, le code doit tre trait comme un code Erreur Serveur (famille 5xx) et tre indiqu l'utilisateur.
Informations : les 1xx

Ces codes sont l simplement pour permettre au serveur d'envoyer une notification. 100 Continue Ce code status est rarement utilis et informe simplement que la partie de la requte qui a dj t reue est valide. Il n'est pas envoy par dfaut, mais seulement dans des cas prcis.
101 Switching protocol Ce code status permet de changer le protocole ou la version du protocole utilis lors de la communication. Le nouveau protocole utiliser est spcifi par l'en-tte Upgrade.
Succs : les 2xx

Ces codes indiquent que tout s'est bien droul et que la ressource demande est renvoye. 200 OK Tout est bon, c'est la rponse la plus souvent employe.
201 Created Peut tre utilis par exemple dans le cadre d'un requte PUT pour indiquer que le document a bien t upload.
204 No Content La requte s'est bien droule, mais le corps de la rponse est vide.
206 Partial Content Ce code est gnralement utilis dans le cadre d'une rcupration de tlchargement, ou de l'utilisation du cache. Seule une partie du document demand est renvoye.
Redirection : les 3xx

Ces codes indiquent que la ressource demande n'est plus l'emplacement indiqu. Ils sont trs utilss pour les redirections. L'en-tte, accompagnant la redirection et qui indique le nouvel emplacement de la ressource, est alors l'en-tte Location. 300 Multiple Choice Ce code est utilis quand on peut trouver plusieurs versions de la ressource (diffrence de format ou de langue par exemple).
301 Moved Permanently Quand une ressource est dplace dfinitivement, c'est ce code qui permet d'indiquer le dplacement notamment aux moteurs de recherche. La requte ayant gnr l'erreur doit alors tre renvoye pour correspondre avec la nouvelle ressource.
307 Temporary Redirect Ce code permet d'indiquer une redirection temporaire.
Requte Invalide : les 4xx

Ces codes indiquent une erreur de la part du client, ressource invalide, authentification invalide, etc. La requte doit alors tre modifie et ventuellement retransmise pour pouvoir tre traite. 400 Bad Request Erreur gnrique.
401 Unauthorized ou Authorization required Le client n'est pas cens avoir accs la requte au vu de son niveau actuel d'identification. Il doit s'identifier de manire correcte. S'il ne peut remplir les conditions d'identification, alors les requtes suivantes aboutiront une erreur 403.
403 Forbidden La ressource est interdite au client.
404 Not Found La fameuse erreur 404, elle indique que la ressource demande n'a pu tre trouve.
405 Method Not Allowed Le client n'est pas cens pouvoir envoyer ce type de requte, une authentification est certainement ncessaire.
Erreur Serveur : les 5xx

Ces codes sont utiliss en cas d'erreur de la part du serveur, en cas de surcharge, d'erreur de configuration, etc. Le plus simple est d'attendre un peu et de retenter plus tard : si l'erreur persiste, contactez l'administrateur du serveur. 500 Internal Server Error Erreur Interne au serveur, il n'est pas en tat de rpondre actuellement.
501 Not Implemented Certaines fonctionnalits requises par les en-ttes ou la mthode employes ne sont pas supportes par le serveur.
503 Service Unavaible Utilis par exemple quand le serveur est surcharg.
505 HTTP Version Not Supported Le serveur ne supporte pas la version du protocole HTTP qui a t utilise.
D'autres codes status

Tous les codes n'ont bien entendu pas t lists ici, certains ont mme t invalids lors du passage de HTTP/1.0 HTTP/1.1 (306 par exemple), ou bien sont rservs pour des versions ultrieures du protocole (402 par exemple).
III-B - Les en-ttes de rponse

Voici les principales en-ttes utilises lors des rponses. Content-type et Content-length Ces deux en-ttes sont censes indiquer le type MIME et la taille en octets du corps de la rponse. De plus, l'en-tte Content-type peut indiquer le charset utilis dans le corps de la rponse (dans le cadre d'un type texte). Il est alors indiqu par la mention "charset=" suivie du nom du charset. Il suit le type MIME, en est spar par un point-virgule. Si elles ne sont pas indiques, c'est le client qui est seul responsable de leur ventuelle valeur par dfaut.
Location Cette en-tte permet d'indiquer une redirection. A sa rception, le client est gnralement cens renvoyer une requte sur l'adresse indique. Ce comportement dpend du code status renvoy avec la rponse.
Set-Cookie Cette en-tte permet d'indiquer au client des cookies stocker. Sa valeur peut prendre une forme assez complexe. La forme par dfaut est celle de l'en-tte de requte Cookie. Les formes plus volues consistent l'indication d'informations telles que : la date de premption (Expires), le domaine d'application (Domain), le chemin d'application (Path), etc. Toutes ces informations sont indiques la suite du couple nom/valeur de la mme manire (nom de l'information, gal, valeur) et spars entre elles et de celui-ci par un point-virgule.
D'autres en-ttes Bien sr, toutes les en-ttes ne sont pas listes ici. Vous trouverez srement une description exhaustive dans la RFC.
IV - Divers IV-A - Le cache : qu'est-ce que c'est ?

Afin de rduire la bande passante utilise, le protocole HTTP met disposition des clients le support d'un mcanisme de sauvegarde des donnes. Ainsi, sous certaines conditions, les clients sont autoriss stocker les rponses du serveur afin de ne pas devoir redemander toute la page au serveur. Tout un ensemble d'en-ttes tant pour les requtes que pour les rponses est ddi cette gestion. De plus, le rle de la mthode 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 ct serveur, c'est le serveur et LUI SEUL qui se doit de les grer. Il peut leur permettre d'interfrer avec la rponse HTTP envoye, via les headers ou le corps par exemple, mais cela relve 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 ct client, ils sont contenus dans le corps de la rponse HTTP et doivent tre transparents pour le serveur. Ils ne peuvent normalement pas interfrer avec le protocole HTTP puisqu'ils entrent en jeu aprs rception de la rponse par le client. Cependant, ils peuvent parfois interfrer sur la cration de la requte (formulaires (X)HTML) ou sur l'utilisation de l'change HTTP (AJAX).
IV-D - Une connexion = Un change ?

En thorie : OUI! Ensuite, HTTP propose des mcanismes 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 requtes HTTP, car la mise en place d'une connexion est relativement coteuse (surtout en temps d'excution). Dans ce cas encore, ce sont des en-ttes spcifiques qui sont charges de la gestion de cette connexion.
IV-E - Les cookies : le clignotant du Web ?

La gestion des cookies est assez complexe : Ct client, on peut, en thorie, y accder en permanence puisque c'est l qu'ils sont stocks. Ct serveur, le comportement doit tre tudi au cas par cas : configuration du client, configuration du serveur, langage utilis ct serveur, configuration du module cot serveur sont autant de paramtres qui peuvent influer sur leurs ractions.
IV-F - Voir le protocole HTTP

Si vous souhaitez tester le protocole HTTP par vous-mme, vous pouvez utiliser telnet. Ce programme est disponible sur la plupart des plate-formes. Pour cel faites :
telnet {nom de domaine} 80
Puis tapez votre requte. En thorie, vous devriez voir votre requte arriver.
IV-G - Voir aussi

RFC HTTP/1.0 (Version franaise) RFC HTTP/1.1

Web HTTP

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Web HTTP

Uploaded by

Copyright:

Available Formats

Le Protocole HTTP

par Mathieu Lemoine

Date de publication : 25/06/2006 Dernire mise jour : 09/10/2006

Le Protocole HTTP par Mathieu Lemoine

Le Protocole HTTP par Mathieu Lemoine

Le Protocole HTTP par Mathieu Lemoine

I - Gnralits I-A - Prsentation

I-C - Caractres Interdits ou Rservs

nouvelle ligne (New Line ou Line Feed,

Le Protocole HTTP par Mathieu Lemoine

nom du caractre LF)

esperluette (et commercial)

espace (Space, SP)

' ' ou " "

Le Protocole HTTP par Mathieu Lemoine

Le Protocole HTTP par Mathieu Lemoine

II - Les Requtes HTTP

II-A - La ligne d'Introduction

Le sparateur SP correspond l'espace.

Les paramtres d'URL sont indiqus avec cette syntaxe :

Le Protocole HTTP par Mathieu Lemoine

Le Protocole HTTP par Mathieu Lemoine

II-B - Les en-ttes de requte

Le Protocole HTTP par Mathieu Lemoine

II-C - Le corps de la requte

Le Protocole HTTP par Mathieu Lemoine

III - Les Rponses HTTP

III-A - La ligne d'Introduction

Informations : les 1xx

Le Protocole HTTP par Mathieu Lemoine

Succs : les 2xx

Redirection : les 3xx

307 Temporary Redirect Ce code permet d'indiquer une redirection temporaire.

Le Protocole HTTP par Mathieu Lemoine

Requte Invalide : les 4xx

403 Forbidden La ressource est interdite au client.

Erreur Serveur : les 5xx

Le Protocole HTTP par Mathieu Lemoine

D'autres codes status

III-B - Les en-ttes de rponse

Le Protocole HTTP par Mathieu Lemoine

IV - Divers IV-A - Le cache : qu'est-ce que c'est ?

IV-B - Et PHP/ASP/JSP/les CGI dans tout a ?

IV-C - Et (D)(X)HTML/JavaScript/ActiveX dans tout a ?

IV-D - Une connexion = Un change ?

IV-E - Les cookies : le clignotant du Web ?

IV-F - Voir le protocole HTTP

Le Protocole HTTP par Mathieu Lemoine

telnet {nom de domaine} 80

IV-G - Voir aussi

You might also like