Ce document est une pr´esentation succincte du protocole HTTP 1.0 et du serveur Apache qui l’utilise.
Le protocole HTTP1 est le protocole d’application utilis´e pour v´ehiculer, entres autres, de l’HTML2 sur l’Internet.
C’est le protocole le plus utilis´e en volume depuis 1995, devant FTP, NNTP et SMTP ; il accompagne l’explosion de l’utilisation du syst`eme global d’information “World–Wide Web”.
Depuis 1990, date d’apparition du “Web”, le protocole HTTP ´evolue doucement mais surement. Il est longtemps rest´e sous forme de “draft”. La premi`ere version d´eploy´ee largement a ´et´e la 1.0, d´efinie dans la RFC 1945 de mai 1996. Depuis le d´ebut du mois de janvier 1997 est apparue la version 1.1, deux fois plus volumineuse pour tenir compte des nouvelles orientations de l’usage du service.
Aujourd’hui ce protocole est tellement r´epandu que pour bon nombre de nouveaux utilisateurs du r´eseau, l’Internet c’est le “web” !
Techniquement, l’usage de ce protocole se con¸coit comme une relation entre un client et un serveur. Le client, appel´e g´en´eriquement un “browser”, un “User Agent”, ou encorebutineur de toile, interroge un serveur connu par son “url3” dont la syntaxe est bien d´ecrite dans la RFC 1738.
Par exemple la chaˆıne de caract`eres http ://www.sio.ecp.fr/ est une url ; il suffit de la transmettre en tant qu’argument `a un quelconque outil d’exploration et celui-ci vous renverra (si tout se passe comme pr´evu !) ce qui est pr´evu sur le serveur en question pour r´epondre `a cette demande (car il s’agit bien d’une requˆete comme nous le verrons plus loin dans ce chapitre).
Le serveur, suppos´e `a l’´ecoute du r´eseau au moment o`u la partie cliente l’interroge, utilise un port connu `a l’avance. Le port 80 est d´edi´e officiellement
1“Hypertext Transfer Protocol”
2“Hypertext Markup Language” — Consulter les “technical reports and publications”
du site :http ://www.w3.org/pub/WWW/TR/
3“Uniform Resource Locator”
au protocole http4, mais ce n’est pas une obligation (cette d´ecision est prise `a la configuration du serveur). L’url qui d´esigne un serveur peut contenir dans sa syntaxe le num´ero de port sur lequel il faut l’interroger, comme dans :
http ://www.sio.ecp.fr :11235/.
1.1 Exemple d’´ echange avec http
Le transport des octets est assur´e par TCP5 et le protocole est “human readable”, ce qui nous autorise des essais de connexion avec le client tcp
`a tout faire : telnet! Bien entendu on pourrait utiliser un “browser” plus classique, mais celui-ci g´erant pour nous le d´etail des ´echanges il ne serait plus possible de les examiner.
$ telnet localhost 80 Trying...
Connected to localhost.
Escape character is ’^]’.
Ce qui est tap´e par l’utilisateur et la r´eponse du serveur.
GET / HTTP/1.0
La requˆete, suivie d’une ligne vide.
HTTP/1.1 200 OK
Date: Fri, 01 Mar 2002 10:59:06 GMT Server: Apache/1.3.23 (Unix)
Last-Modified: Sat, 10 Nov 2001 16:13:02 GMT ETag: "1381-8b-3bed520e"
Connection closed by foreign host.
Enfin la r´eponse du serveur, que l’on peut d´ecomposer en trois parties :
1. Un code de retour (HTTP)
2. Un en-tˆete MIME
3. Des octets, ici ceux d’une page ´ecrite en HTML.
Notons ´egalement la decon-nexion `a l’initiative du ser-veur, en fin d’envoi de la page HTML.
1.2 Structure d’un ´ echange
L’exemple qui pr´ec`ede est typique d’un ´echange entre le client et le ser-veur : une question du client g´en`ere une r´eponse du serser-veur, le tout lors d’une connexion TCP qui se termine lors de l’envoi du dernier octet de la r´eponse (clˆoture `a l’initiative du serveur).
Le serveur ne conserve pas la m´emoire des ´echanges pass´es, on dit aussi qu’il est sans ´etat, ou “stateless”.
4http ://www.iana.org/assignments/port-numbers
5page 83
Le protocole HTTP 151 La question et la r´eponse sont bˆaties sur un mod`ele voisin : le message
HTTP.
Message HTTP
D B
A
Début du message C
figure IX.01
Les parties A, B et C forment l’en-tˆete du message, et D le corps.
A La premi`ere ligne du message, est soit la question pos´ee (“request-line”), soit le statut de la r´eponse (“status-line”).
– La question est une ligne termin´ee parCRLF, elle se compose de trois champs :
Une m´ethode `a prendre dans GET, HEAD, ou POST.
GET Plus de 99% des requˆetes ont cette m´ethode, elle retourne l’information demand´ee dans l’URL (ci-dessous).
HEAD La mˆeme chose que GET, mais seul l’en-tˆete du serveur est envoy´e. Utile pour faire des tests d’accessibilit´e sans sur-charger la bande passante. Utile ´egalement pour v´erifier de la date de fraicheur d’un document (information contenue dans l’en-tˆete).
POST Cette m´ethode permet d’envoyer de l’information au ser-veur, c’est typiquement le contenu d’un formulaire rempli par l’utilisateur.
Une ressource que l’on d´esigne par une URL6. Par exemple http ://www.site.org/.
La version du protocole , sous forme HTTP-Num´ero de version.
Par exemple HTTP/1.1!
– La r´eponse. Cette premi`ere ligne n’est que le statut de la r´eponse, les octets qui la d´etaillent se trouvent plus loin, dans le corps du message. Trois champs la composent, elle se termine par CRLF : La version du protocole , sous forme HTTP-Num´ero de version,
comme pour la question.
Statut C’est une valeur num´erique qui d´ecrit le statut de la r´eponse.
Le premier des trois digits donne le sens g´en´eral :
6“Uniform Resource Locator”, consulter la RFC 1630
1xx N’est pas utilis´e “Futur Use”
2xx Succ`es, l’action demand´ee a ´et´e comprise et ex´ecut´ee correctement.
3xx Redirection. La partie cliente doit reprendre l’interroga-tion, avec une autre formulation.
4xx Erreur cot´e client. La question comporte une erreur de syntaxe ou ne peut ˆetre accept´ee.
5xx Erreur cot´e serveur. Il peut s’agir d’une erreur interne, due `a l’OS ou `a la ressource devenue non accessible.
Phrase C’est un petit commentaire (“Reason- Phrase”) qui accom-pagne le statut, par exemple le statut 200 est suivi g´en´eralement du commentaire “OK” !
B C’est une partie optionnelle, qui contient des informations `a propos du corps du message. Sa syntaxe est proche de celle employ´ee dans le cour-rier ´electronique, et pour cause, elle repecte aussi le standard MIME7. Un en-tˆete de ce type est constitu´e d’une suite d’une ou plusieurs lignes (la fin d’une ligne est le marqueur CRLF) construite sur le mod`ele : Nom de champ: Valeur du champCRLF
Eventuellement le marqueur de fin de ligne peut ˆetre omis pour le´ s´eparateur “ ;”.
Exemple d’en-tˆete MIME :
Date: Fri, 01 Mar 2002 10:59:06 GMT Server: Apache/1.3.23 (Unix)
Last-Modified: Sat, 10 Nov 2001 16:13:02 GMT ETag: "1381-8b-3bed520e"
Accept-Ranges: bytes Content-Length: 79 Connection: close Content-Type: text/html
Date : C’est la date `a laquelle le message a ´et´e envoy´e. Bien sˆur il s’agit de la date du serveur, il peut exister un d´ecalage incoh´erent si les machines ne sont pas synchronis´ees (par exemple avec XNTP).
Server : Contient une information relative au serveur qui a fabriqu´e la r´eponse. En g´en´erale la liste des outils logiciels et leur version.
Content-type : Ce champ permet d’identifier les octets du corps du message.
Content-length : D´esigne la taille (en octets) du corps du message, c’est `a dire la partie D de la figure 1.
Last-modified : Il s’agit de la date de derni`ere modification du fi-chier demand´e, comme l’illustre le r´esultat de la commande ll (voir aussi la co¨ıncidence de la taille du fichier et la valeur du champ pr´ec´edent).
7“Multipurpose Internet Mail Extension”, consulter la RFC 1521
Le protocole HTTP 153
-rw-r--r-- 1 web doc 139 Nov 10 17:13 index.html ETag : C’est un identificateur du serveur, constant lors des ´echanges.
C’est un moyen de maintenir le dialogue avec un serveur en parti-culier, par exemple quand ceux-ci sont en grappe pour ´equilibrer la charge et assurer la redondance.
C Une ligne vide (CRLF) qui est le marqueur de fin d’en-tˆete. Il est donc absolument obligatoire qu’elle figure dans le message. Son absence en-traine une incapacit´e de traitement du message, par le serveur ou par le client.
D Le corps du message. Il est omis dans certains cas, comme une requˆete avec la m´ethode GET ou une r´eponse `a une requˆete avec la m´ethode HEAD.
C’est dans cette partie du message que l’on trouve par exemple les octets de l’HTML, ou encore ceux d’une image. . .
Le type des octets est intimement li´e `a celui annonc´e dans l’en-tˆete, plus pr´ecisement dans le champ Content-Type.
Par exemple :
Content-Type : text/html=⇒Le corps du message contient des oc-tets `a interpr´eter comme ceux d’une page ´ecrite en HTML.
Content-Type : image/jpg=⇒Le corps du message contient des oc-tets `a interpr´eter comme ceux d’une image au format jpeg