Hyper Text Transfer Protocol
Le protocole est le langage commun parlé par le client et le serveur pour se
comprendre. Le protocole HTTP/0.9 (version 0.9) est le protocole qui a été défini
pour transférer des documents hypermédia écrits en HTML. C'est un protocole sans
état (le client n'est pas averti sur les erreurs de transmission et de réception
parce qu'il n'y a pas de session permanente entre le serveur et le client afin de
traiter avec un maximum d'efficacité des requêtes nombreuses). Les documents sont
transmis en binaires (fichiers typés) pour pouvoir émettre des informations différentes
(texte, image, son). Une version évoluée de ce protocole a été introduite : HTTP/1.1.
Cette version est déjà supportée par la plupart des serveurs et permet de faire une
extension de la méthode unique pour obtenir un document (GET n'est plus le seul
moyen).
1. Les phases de communication :
L'émission d'un document par un serveur Web vers un client demandeur se
décompose en 4 phases :
1) Connexion : le client effectue une connexion TCP/IP sur le serveur. Le
serveur accepte la connexion.
2) Requête : le client émet sa requête ; cette requête est composée par une
commande comme GET suivie d'un espace et de l'adresse URL (elle sera définie
dans le paragraphe suivant) du document et suivie du caractère CR (Retour Chariot)
à la fin.
3) Réponse : le serveur expédie le document demandé, c'est un fichier HTML
par exemple.
4) Fermeture : le serveur coupe la connexion.
2. Le serveur Web :
Le serveur Web reste perpétuellement à l'écoute en attendant des requêtes
demandant des fichiers. Ces fichiers contiennent la plupart du temps du langage
HTML et des images incorporées au format GIF ou JPEG mais ils peuvent contenir
n'importe quel autre type de données (texte brut, Postscript, son, vidéo, programme
exécutable, etc.).
Parfois le client demande au serveur d'exécuter un programme et de lui renvoyer
le résultat. Par exemple, après avoir rempli les champs d'un formulaire, l'utilisateur
appuie sur le bouton du formulaire pour envoyer les données. Ces données sont
transmises au programme externe sur la machine du serveur. Ce programme va
produire un résultat qui sera envoyé au serveur puis renvoyé au client. Le
mécanisme par lequel le serveur et un programme externe échangent des données
en vue d'obtenir un résultat à renvoyer au client est appelé Common Gateway
Interface(CGI).
3. Le protocole HTTP: HyperText Transfert Protocol
HyperText Transfert Protocol, est la signification de l'acronyme HTTP.
Traduction primaire: protocole de transfert de document hypertexte. Les documents
hypertexte sont simplement les documents html des premières heures, en effet la
première version du protocole était exclusivement réservée aux pages web. La large
acceptation de ce protocole, sa simplicité de mise en œuvre, la configuration des
firewalls et routeurs dans les entreprises ont ensuite permis le développement de ce
protocole dans de nombreuses autres applications. La majorité des utilisations reste
la consultation de serveurs web et c'est dans cet esprit que ce protocole va être
expliqué et que les exemples seront donnés.
Le Protocole HTTP ( hypertext transfert protocol ) sert ( entre autre ) au dialogue
entre votre navigateur Web et un serveur.
Comme la plupart des protocoles internet, c'est un protocole texte basé sur TCP.
Il suffit donc d'ouvrir une connexion TCP sur le port 80 du serveur, et d'envoyer une
requête texte vers le serveur. Il est très facile de faire des tests avec la commande
telnet: telnet www.iprelax.net 80.
La requête a la forme suivante: GET /index.html HTTP/1.1 (suivi de 2 retours
chariot complet '\r\n'). Elle permet de demander le fichier index.html sur le serveur
www.iprelax.net
La réponse sera composée de deux parties, l'entète qui indique si la requête a
réussie et le corps du message.
Remarques: en plus de la ligne GET ..., la requête peut contenir des champs
supplémentaires sur les lignes suivantes, tel que Host qui est indispensable si l'on
passe par un proxy. Cette information est utilisée dans le programme client. En effet,
si vous vous êtes connectés à un proxy ( eg: telnet proxy 8080 ), il faut spécifier le
nom du serveur. Cela donne:
GET /index.html HTTP/1.1\r\n
Host: www.iprelax.net\r\n
\r\n
Un protocole client serveur
Le protocole HTTP est une implémentation de type client serveur des plus
simples qui soit. Le client est généralement votre navigateur web (mozilla,
konqueror...). Celui-ci envoie une requête à un serveur (apache ...) qui lui répond.
C'est un protocole en mode texte, généralement utilisé sur une connexion TCP,
dédié au transfert de ressource. Il n'est pas dédié à l'échange de fichiers même si
dans la pratique c'est souvent le cas avec les sites web. Il devient donc extrêmement
simple d'étudier son fonctionnement en utilisant le programme telnet.
Pour se connecter au serveur web de linuxmag, il suffit de faire :
telnet www.linuxmag-france.org 80
Le port 80 est celui généralement utilisé par le serveur pour recevoir une
connexion. Vous retrouverez cette valeur si vous jetez un oeil dans le fichier
/etc/services. Une fois la connexion établie, vous pouvez envoyer votre requête
HTTP :
GET / http/1.0 (Suivi d'une ligne blanche)
et si tout se passe bien vous recevrez une réponse de ce type :
HTTP/1.1 200 OK
Date: Mon, 26 Aug 2002 14:03:19 GMT
Server: Apache/1.3.23 (Unix) Debian GNU/Linux PHP/4.1.2
X-Powered-By: PHP/4.1.2
Connection: close
Content-Type: text/html; charset=iso-8859-1
La requête HTTP
La requête utilisée dans cet exemple est la plus simple que l'on puisse trouver,
elle se compose d'un seule ligne qui comprend trois éléments : la méthode, l'url (elle
identifie la ressource, dans la plupart des cas sur Internet il s'agit d'un simple fichier
texte ou d'une image) et la version du protocole HTTP utilisé (HTTP/1.0 ou
HTTP/1.1). En plus de cette ligne on peut trouver un certain nombre de champ (1 par
ligne) dont la forme est toujours la même, le nom du champ, suivi de : et d'un espace
et la valeur que l'on veut lui donner (toujours suivi des caractères \r et \n). Les
caractères \r et \n correspondent respectivement au retour chariot et saut de ligne.
Vient ensuite une ligne vide, composée donc seulement des deux caractères \r et \n
et le corps de la requête. Une requête a donc la forme suivante :
Méthode url HTTP/1.0\r\n
Champ1 : valeur 1\r\n
Champ2 : valeur 2\r\n
\r\n
Ceci est le corps de ma requête ...
Il existe cinq méthodes :
Méthode Description
GET Requête de la ressource située à l'URL spécifiée
Requête de la ressource située à l'URL spécifiée (la réponse ne
HEAD
contient que l'entête, et pas le contenu de la ressource)
Envoi de données au programme situé à l'URL spécifiée (le
POST
corps de la requête peut être utilisé)
PUT Envoi de données à l'URL spécifiée (idem POST)
DELETE Suppression de la ressource située à l'URL spécifiée
Les deux méthodes vraiment utilisées sont GET et POST (les amateurs d'html
reconnaîtront des mots clefs familiers à la construction d'un formulaire). La méthode
GET est la plus simple car le corps du message dans ce type de requête est vide. La
méthode POST permet d'envoyer des informations au serveur dans le corps du
message d'une requête HTTP. Lorsque des informations sont envoyées au serveur à
l'aide de la méthode GET, elles sont encodées à la suite de la ressource après le
symbole '?' dans l'url.
La méthode HEAD sert essentiellement pour les applications de cache. En effet
la réponse HTTP renseigne sur les propriétés de la ressource demandée (date de
dernière modification, …), il est donc intéressant pour économiser du temps de
traitement et de la bande passante de pouvoir ne demander que ces informations et
pas le contenu de la ressource (qui se trouve quand même très souvent être un
simple fichier).
Dans la pratique bien peu de serveurs autorisent les actions de type PUT et
DELETE pour des raisons évidentes de sécurité.
Les champs d'une requête HTTP
La première ligne d'une requête peut être suivi d'un certain nombre de champs
permettant de donner quelques renseignements sur le client (souvent un navigateur)
et son utilisateur (généralement vous). Il existe de nombreux champs, et seuls les
plus utilisés ou les plus utiles pour la programmation de petits clients seront
expliqués; la rfc du protocole vous permettra de voir toutes les possibilités offertes.
Nom du champ Description
Type de contenu accepté par le navigateur (par exemple
Accept
text/html, ce sont les codes MIME).
Content-Length Longueur du corps de la requête
Type de contenu du corps de la requête (par exemple
Content-Type
text/html).
Date Date de début de transfert des données
Forwarded Utilisé par les proxys entre le navigateur et le serveur
From Permet de spécifier l'adresse e-mail du client
Referer URL du lien à partir duquel la requête a été effectuée
If-Modified-Since Dernière date de réception du contenu de la ressource
Host Nom du serveur/domaine de destination
Chaîne donnant des informations sur le client, comme le nom
User-Agent
et la version du navigateur, du système d'exploitation
Le champ Accept est important car vous pouvez indiquer la liste des formats de
données que vous souhaitez recevoir. Les codes suivant sont particulièrement
intéressants : image/gif, image/jpeg, image/png. En l'absence de ce champ, le
serveur n'enverra pas de fichier d'image, ils sont donc indispensables pour écrire un
outil d'aspiration d'images sur le web.
Le Champ Content-Length est particulièrement utile pour les requêtes POST (en
effet, la valeur de ce champ est toujours nulle pour les requêtes GET) car certains
serveurs refusent de traiter la requête en l'absence de ce champ.
Pour l'écriture d'un outils de synchronisation entre un site web et une autre
source de données, utilisez le champ If-Modified-Since, suivi de la dernière date de
synchronisation, il indique au serveur de n'envoyer le contenu de la ressource que si
il a changé depuis cette date.
Le champ Host indique le nom du domaine destination de la requête. Il est
fréquent qu'un serveur web soit en charge de plusieurs sites web de noms de
domaines différents, ce champ permet de faire la distinction. Ce champ est
obligatoire avec la version HTTP/1.1.
Les auteurs de sites web n'apprécient guère l'usage des aspirateurs (tel que
wget) car ils permettent la consultation hors ligne de leur site et empêche l'affichage
de bannières publicitaires. Une technique classique consiste à vérifier le Referer
d'une requête avant de répondre. Le Referer indique l'url de la ressource
précédemment consultée (dans le cas d'un navigateur, c'est l'url de la page qui
contenait le lien sur lequel vous venez de cliquer). La plupart des outils utilisant
HTTP servent à récupérer de façon automatique des données (ou des ensembles de
fichiers) sur le web, il est donc parfois important de renseigner ce champ pour donner
l'impression qu'un vrai utilisateur est derrière son navigateur.
Pour les mêmes raisons que précédemment, il est toujours plus intéressant pour
un utilitaire de récupération de fichiers sur Internet de se faire passer pour un
navigateur ordinaire. Le champ User-Agent permet de vous faire passer pour le
dernier navigateur à la mode, celui que tous les sites web acceptent (le navigateur
Opera utilise cette technique).
La réponse http
Maintenant que vous êtes au point sur les requêtes, voici ce que vous devez
attendre pour la réponse. Une réponse HTTP est un ensemble de lignes envoyées
au navigateur par le serveur (exactement comme la requête). Elle comprend: une
ligne statut, une liste de champs, une ligne blanche, le corps de la réponse
(généralement le contenu du fichier demandé).
La ligne de statut précise la version du protocole utilisée et l'état du traitement de
la requête à l'aide d'un code et d'un texte explicatif. Le code est utilisé par le
programme client alors que l'explication permet d'informer l'utilisateur en cas
d'erreur.
Un ensemble de lignes facultatives permet de donner des informations
supplémentaires sur la réponse, la ressource et le serveur. Chacune de ces lignes
est composée d'un nom qualifiant le type de champ, suivi de deux points (:) et de la
valeur (encore une fois exactement comme pour la requête).
Une réponse HTTP a donc la syntaxe suivante (\r\n sont les caractères retour
chariot et saut de ligne):
HTTP/x.x Code Explication\r\n
Champ 1: Valeur1\r\n
Champ n: Valeurn\r\
(ligne vide)\r\n
corps de la réponse
Les codes retour
Les codes retour sont importants car ils représentent le statut de la transaction.
Le code de réponse est constitué de trois chiffres, le premier indique la classe de
statut et les suivants la nature exacte de l'erreur.
Les codes 20x indiquent que l'opération s'est correctement effectuée. Le plus
courant est le code 200 (OK).
Les codes de classe 30x indiquent que l'objet demandé a été déplacé, il faut
donc changer d'url ou de méthode pour accéder au contenu de cette ressource. Le
code 304 indique que la ressource n'a pas été modifiée ; c'est le code utilisé dans le
cas d'une requête avec le champ If-Modified-Since (le corps de la réponse est donc
vide dans ce cas).
La classe 4 sert lorsque le client a commis une erreur. Tout le monde a déjà
rencontré l'erreur '404 Not found' lorsque l'objet demandé n'existe plus, ou l'erreur
'403 FORBIDDEN' après la saisie d'un mauvais mot de passe.
La classe 5 signifie une erreur du coté du serveur tel qu'un bug dans un script
CGI.
Les champs d'une réponse http
Les champs à connaître ne sont pas nombreux. Vous pouvez vous en tirez très
bien avec seulement les quatre informations suivantes.
Content-Lenght : c'est la longueur du corps de la réponse, très pratique pour
dimensionner un buffer ou savoir quand on a finit de lire les informations.
Content-Type : le type de document dont le contenu se trouve dans le corps du
message. Si vous avez affaire à un document html (text/html) ou à une image
(image/png) vous n'utiliserez pas forcément la même routine pour sauver ou afficher
l'information.
Date : elle renseigne sur la date de dernière modification du fichier, vous pouvez
l'utiliser ensuite dans une requête conditionnelle (If-Modified-Since) pour réduire un
peu votre consommation de bande passante.
Location : dans les réponses de classe 3, vous pourrez trouver ce champ
indiquant la nouvelle adresse de la ressource que vous aviez demandée.
Session de connexion http
voici un petite connexion utilisant le protocole http.
En bleu, les textes du client.
En rouge, les textes reçus du serveur.
En vert, des commentaires pour donner quelques explications.
>telnet localhost 80 on ouvre une session telnet sur le port 80
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
GET /index.htm HTTP/1.1 on saisi la requête http
host: localhost le paramètre host est nécessaire pour certain serveur
un double retour chariot pour finir
HTTP/1.1 200 OK
Date: Thu, 20 Dec 2001 17:11:50 GMT
Server: Apache/1.3.19 (Unix) PHP/4.0.6
Last-Modified: Thu, 20 Dec 2001 16:36:22 GMT
ETag: "2cb9e7-61c-3c221386"
Accept-Ranges: bytes
Content-Length: 1564
Connection: close
Content-Type: text/html
X-Pad: avoid browser bug
<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<meta http-equiv="Pragma" content="no-cache">
<meta name="author" Lang="fr" content="Nicolas JEAN">
<meta name="description" content="tous les protocoles du web et de
l'internet, http, pop, smtp, nntp, imap, irc dans un programme
[ iprelax.net ]">
...
</html>
Connection closed by foreign host.
TP : code en C#, transformer le en java
Cette astuce explique comment envoyer des données par la commande HTTP
POST à un serveur.
using System;
using System.Net;
using System.IO;
using System.Text;
class Class1
static void Main(string[] args)
//les donnees a poster au serveur
StringBuilder strData = new StringBuilder();
strData.Append("function=Login");
strData.Append("&AdminPassword=mypassword");
strData.Append("&Login=Log on");
//On transforme le tout en tableau de byte
byte[] dataToPost = new ASCIIEncoding().GetBytes(strData.ToString());
// On cree la requete Http
HttpWebRequest myRequest =
(HttpWebRequest)WebRequest.Create("http://192.168.0.1");
//On specifie la commande a utiliser dans notre cas POST
// Envoi de donnes au programme situ l'URL spcifie
myRequest.Method = "POST";
//Le type de contenu du corps de la requte
myRequest.ContentType="application/x-www-form-urlencoded";
//Longueur du corps de la requte
myRequest.ContentLength = dataToPost.Length;
//On ecris les donnee dans la requete
Stream myStream = myRequest.GetRequestStream();
// Envoie des donnees
myStream.Write(dataToPost,0,dataToPost.Length);
myStream.Close();
//On recupere la reponse
WebResponse myResponse = myRequest.GetResponse();
//on cree un flux
Stream responseStream = myResponse.GetResponseStream();
//On instancie un objet de type streamreader
StreamReader streamReader = new StreamReader(responseStream);
//On lit la totalite du flux
string result = streamReader.ReadToEnd();
//on ferme les flux
streamReader.Close();
responseStream.Close();
myResponse.Close();
myStream.Close();
