HTTP

Hypertext Transfer Protocol

1
 Partie 1
Architecture du web
Quelques notions

2
 Architecture Client / Serveur
• On parle aussi d’architecture consommateur / fournisseur
– Le consommateur effectue des demandes auprès d’un fournisseur
– Le fournisseur répond à la demande du consommateur
• Le serveur est en attente permanente d’une requête d’un potentiel
client
– Le client initie la communication
– Le serveur établit un « échange 2 à 2 » (c’est-à-dire sur un canal
unique avec chaque client)
– Le serveur répond à la demande du client et à ses éventuelles futures
demandes
– Le client interprète les réponses du serveur pour
• Les afficher à l’écran
• Ou effectuer tout autre traitement
• Ce mode de fonctionnement est générique et le client, comme le
serveur, peuvent être des hommes ou des programmes

3
Des langages de communication « bas
niveau »
• Le client et le serveur doivent communiquer selon le même protocole
• Selon le besoin, des protocoles dédiés ont été créés pour s’adapter au
mieux à la demande, par exemple :
– HTTP : Hyper Text Transfert Protocol
– SMTP : Simple Mail Transfert Protocol
– POP : Post Office Protocol
– FTP : File Transfert Protocol
– IRC : Internet Relay Chat Protocol

4
 Fonctionnement du web
• Que se passe-t-il quand je tape www.google.fr ?
– Un serveur DNS (Domain Name System) résout le nom du site pour
déterminer son adresse IP
– Le client (navigateur) établit une connexion vers l’adresse IP en question
• Un serveur pouvant rendre plusieurs services (HTTP, FTP, SMTP, ...), il faut
que les clients puissent les spécifier et les différencier
– On utilise la notion de port (par défaut 80 depuis son navigateur)
– Un serveur écoute sur certains ports de sa machine hôte et interprète les
connexions entrantes selon un protocole précis

5
 Vers une architecture orientée
ressource
• Avec le web, évolution des applications
distribuées
– Avant, les architectures clients / serveurs
• Toujours valides pour certains types d’applications
• Mais moins pour les systèmes d’informations à grande
échelle

6
 Composants du Web : Pare-feu,
routeur, cache
• Pare-feu
– ces composants décident de l’entrée et de la sortie de messages
HTTP
– Ils renforcent/participent à la sécurité
• Routeur
– Ces composants participent à diriger les messages HTTP
– Ils gèrent le passage à l’échelle
• Caches
– Ces composants décident si la copie d’un message/d’une
donnée doit être effectuée
– Ils améliorent la vitesse
• Tous ces composants basent leurs décisions uniquement
sur le contenu des en-têtes des messages HTTP

7
 Les composants du Web et l’en-tête
des message HTTP
• Tous ces composants basent leurs décisions uniquement
sur le contenu des en-têtes des messages HTTP

Analogie avec une lettre – courrier postal:

1. Personne à part le destinataire d’une lettre ne doit en lire
le contenu
2. Seul l’extérieur, i.e. l’en-tête, doit être accessible et les
décisions d’acceptation (pare-feu), de redirection
(routeur) et de conservation d’une copie (cache) sont
prises en fonction de cet en-tête uniquement
8
Pare-feu – Puis-je POSTer un message
sur geocities?

•Le pare-feu décide si le message HTTP

peut le traverser
•Sa décision est basée sur l’en-tête HTTP
du message. Il ne regarde jamais le
•contenu (payload) ce qui est
fondamental!
• Le message est rejeté

9
 Qu’est-ce que le Web 2.0?
• Dépend de celui à qui vous demandez, mais on retiendra principalement:
• Le Web mature
– Cela marche vraiment maintenant (cf utilisation de AJAX)
• Exemple de Google maps: accès interactif à une vaste base de données (cartes, street
views)
• AJAX rend les navigateurs plus “intelligent” a accès aux serveurs web sous forme de
service
• Le Web programmable
• L’utilisation de Javascript permet d’aller encore plus loin
– Mise à jour partielle de pages web sans tout recharger
• Des applications classiques peuvent communiquer avec des
applications/services web
– Flickr uploader, mise à jour/synchronisation de calendriers
• Les applications Web peuvent discuter
– Import d’amis Facebook dans LinkedIn
• Mashups – composition simple de services

10
 Partie 2
Protôcole HTTP

11
 HyperText Transfert Protocol
• HTTP permet d’accéder aux fichiers situés sur le réseau Internet. Il est notamment
utilisé pour le World Wide Web
• HTTP se place au dessus de TCP et fonctionne selon un principe de
requête/réponse
– le client transmet une requête comportant des informations sur le document demandé
– le serveur renvoie le document si disponible ou, le cas échéant, un message d’erreur.

HTTP est un protocole synchrone initialement sans connexion et chaque couple

requête/réponse est de ce fait indépendant.

12
 HTTP – Bref historique
• De HTTP 1.0 à HTTP 1.1
• Protocole au CERN au début des années 1990 afin
de fournir au Web un protocole de transfert
simple.
• Deux versions du protocole existent :
– HTTP 1.0 définit en 1996 par la RFC 1945
– HTTP 1.1 définit en 1999 par la RFC 2616
• La version 1.1 apporte, entre autre, les
améliorations suivantes :
– Cinq nouvelles méthodes
– Connexions persistantes
13
 URI, URL, URN
• On va voir dans l’ordre :
– URI (Uniform Ressource Identifier) c’est un mécanisme
permettant aux utilisateurs et aux programmes de
nommer et de localiser les ressources Web
(information, documents, programmes, services)
– L’URI est utilisé par les protocoles de base du Web
(HTTP, FTP) et aussi par la plupart des techniques
récentes telles que :
• Les espace de noms (namespaces)
• XML
• SMIL (Synchronized Multimedia Integration Language )
• SVG (Scalable Vector Graphic )

14
 URI, URL, URN
• Les URI sont classés en trois
groupes :
– ceux qui permettent de
localiser des ressources sur un
réseau, appelés URL (Uniform
Resource Locator) ;
– ceux qui permettent
d’identifier et de nommer des
ressources de manière unique
et persistante, appelés URN
(Uniform Resource Name) ;
– et ceux qui permettent à la
fois de localiser et d’identifier
une ressource.
15
 URI, URL, URN : Composition
• Un URI est toujours constitué de la manière suivante :
<modèle>:<chemin ou partie spécifique du modèle>
– Le modèle ou schéma définit l’espace de noms de l’URI et
peut donc introduire des restrictions dans la syntaxe ou la
sémantique du chemin. En d’autres termes, la syntaxe d’un
URI dépend du modèle utilisé.
• Il existe néanmoins une syntaxe générique des URI, que
voici :
<modèle>://<autorité><chemin> ?<requête>
– Par exemple :
• ftp://www.monsite.com/pub
• http://www.monsite.com/index.htm?param1=1&param2=essai
• file:///c:/program%20files/monfichier.txt

16
URI, URL, URN : Composition
Format d’une URI

17
 URI, URL, URN : Composition
• Comme nous l’avons dit, un URN a pour objectif de
nommer une ressource indépendamment de sa
localisation.
• Un modèle (schéma) spécifique a été défini par le
RFC2141 et est utilisé en tant que standard pour
identifier des ressources sur le Web.
• Sa syntaxe est la suivante :
urn:<espace de noms><identifiant au sein de l’espace de noms>

• Par exemple :
urn:MonEspace:MonIdentifiant

18
 Protocole HTTP : Requête (1/2)
• La requête transmise par le client au serveur comprend :
– une ligne de requête (request-line) contenant la méthode
utilisée, l’URI du service demandé, la version utilisée de HTTP
– une ou plusieurs lignes d'en-têtes, chacune comportant un nom
et une valeur.

19
 Protocole HTTP : Requête (2/2)

• Exemple
• Le client demande le document à l'adresse
– http://www.example.com/index.html
• Accepte tous les types de document en retour
• Préfère les documents en français
• Utilise un navigateur (browser) compatible Mozilla 4.0 sur un système
Windows NT 5.1 (Windows XP)
• Signale au serveur qu'il faut garder la connexion TCP ouverte à l'issue de la
requête (car il a d'autres requêtes à transmettre).

20
 Protocole HTTP : type de méthodes
(1/2)
• Lorsqu’un client se connecte à un serveur et envoie une
requête, cette requête peut prendre plusieurs types,
appelées méthodes
• Requêtes de type GET
– Pour extraire des informations
• Document, graphique
– Intègre les données de formatages de l’URI (chaîne
d’interrogation)
• www.toto.com/hello?key1=titi&key2=tata&…
• Requête de type POST
– Pour poster des informations secrètes (au sens pas visibles dans
l’en-tête), des données graphiques, …
– Transmises dans le corps de la requête

21
 Protocole HTTP : type de méthodes
(2/2)
• Les méthodes

22
 Principales méthodes – GET (1/2)
• La méthode GET est une requête d’information sur une ressource
– L’information fournie en réponse l’est sous forme
• D’un ensemble d’headers
• Et d’une représentation
– Le client n’envoie jamais de représentation avec la requête (corps de la
requête vide)

23
 Principales méthodes – GET (2/2)
• La méthode GET est une requête d’information sur une ressource
– L’information fournie en réponse l’est sous forme
• D’un ensemble d’headers
• Et d’une représentation (dans le corps de la requête)

24
 Principales méthodes – DELETE
• La méthode DELETE permet de supprimer une ressource
– Tous les paramètres à transmettre au services peuvent l’être dans le
header
– Aucune donnée attendue en réponse (mais ceci est toutefois possible)

25
 Principales méthodes – POST
• La méthode POST permet de créer / ajouter une nouvelle ressource
– Tous les paramètres à transmettre au services peuvent l’être dans le header
– Aucune donnée attendue en réponse (mais ceci est toutefois possible)

26
 Principales méthodes – PUT
• La méthode PUT permet de mettre à jour une ressource
– Inclut l’ajout d’une sous-ressource
– Tous les paramètres à transmettre au services peuvent l’être dans le header
– Aucune donnée attendue en réponse (mais ceci est toutefois possible)

27
 Principales méthodes – sureté et
idempotence
• Deux caractéristiques importantes
– La sureté
– L’idempotence
• Une méthode sûre ne doit jamais modifier l’état de la
ressource.
– Cas des méthodes GET et HEAD
– POST, DELETE et PUT ne sont pas sûres
• Une méthode est idempotente dès lors qu’elle peut être
répétée un nombre quelconque de fois, l’ensemble des
ressources reste toujours dans le même état après
l’application de la méthode
– Autrement dit, le résultat d’une opération idempotente reste
toujours le même dans un contexte donné avec des paramètres
donnés
28
 Principales méthodes – sureté et
idempotence
• La méthode GET est sure et idempotente
– Un client qui fait une requête de type GET sur une ressource ne
requiert aucun changement de cette ressource
– Le serveur peut bien sûr changer mais le client ne peut pas être
tenu pour responsable (log de la requête ou incrément d’un
compteur par exemple)
– Faire un nombre quelconque de GET ou aucun devrait avoir le
même effet (ou aucun)
• Les méthodes PUT et DELETE sont idempotentes
– Faire plusieurs requêtes PUT (ou DELETE) sur une ressource doit
avoir le même effet que d’en faire une seule
• La méthode POST n’est ni sure ni idempotente
– C’est elle qui sert de « boite à outils » à divers framework
(messages personnalisés, etc.)

29
 Protocole HTTP : réponse (1/3)
• La réponse transmise par le serveur au client comprend :
– Une ligne de statut contenant la version utilisée de HTTP et un code d’état
– Une ou plusieurs lignes d’en-têtes comportant un nom et une valeur
– Le corps du document retourné (les données HTML ou binaires par exemple).
• Une réponse ne contient pas obligatoirement un corps (exemple : s’il s’agit d’une
réponse à une requête HEAD, seule la ligne de statut et les en-têtes sont retournés.

30
 Protocole HTTP : réponse (2/3)
Exemple
• Le code 200 indique que le document demandé a été trouvé.
• Pour faciliter la gestion du cache du client, le serveur transmet
– la date actuelle,
– la date de dernière modification du document
– la date d'expiration (après laquelle le document doit être demandé à nouveau).

31
 Protocole HTTP : réponse (3/3)
Exemple
• L'en-tête Content-Type indique que le document retourné est de type HTML
• L'en-tête Content-Length indique que le corps du document a une longueur de
1456 octets.
• L'en-tête Server renseigne sur le logiciel serveur utilisé.
– L’envoi d’une telle information n’est pas recommandé d’un point de vue sécuritaire.

32
En-têtes génériques des messages
HTTP

33
En-têtes des requêtes HTTP

34
En-têtes des réponses HTTP

35
36