Récap séquence 1

• CM 1-2 : introduction architecture
• HP 0-1
  • langage PHP
• TP 1
  • Appli ligne de commande « mini-allociné » en ligne de commande, accès lecture BD avec Doctrine
• TP 2
  • Démarrage du projet

Plan de la séquence

Architecture Client-Serveur

HTTP (HyperText Transfer Protocol)

• Multiples clients simultanés
• Serveur sans « connaissance » particulière des clients
• Réseau internet TCP/IP

Le client construit la requête

1. Le client (navigateur) interprète l’URL
2. demande au service de nom une adresse IP pour le nom du site (www.monsite.fr)
3. établit une connexion TCP avec cette adresse, sur le numéro de port : 80 pour HTTP (ou 443 pour HTTPS, …)
4. formule sa requête d’action (par ex. méthode GET) sur une ressource (/projet/doc.html), en écrivant un message :
   ex.: « GET /projet/doc.html »

Le serveur traîte la requête

1. Analyse la requête (GET /projet/doc.html)
2. Vérification validité, autorisations d’accès…

3. Envoi d’une réponse au client avec :

   • un code de statut
   • le contenu (document ou résultat exécution)

   ou :

   • message d’erreur, ou une demande authentification, ou adresse de redirection
4. Fermeture de la connexion

Requête - Réponse

Contenu des messages

Production du contenu sur le serveur

• chemin d’accès à la ressource reçu : identifie la ressource demandée (« /projet/doc.html »);
• En fonction du contexte de la requête, pour la même URL, le serveur peut renvoyer différentes représentations de cette ressource, différents contenus/formats;
• La façon dont le serveur fabrique le contenu renvoyé lui appartient : le client ne peut rien supposer, juste suivre les liens hypertextes.

• Arborescence de chemins d’accès aux ressources accessibles (dans les URL) différente d’une éventuelle arborescence de stockage effectif à l’intérieur du serveur.

  • Peut-être envoi d’un document stocké sur un système de fichier ?
  • Peut-être une application générant des documents dynamiquement ?

  - …

Choix du serveur arbitraire en fonction du contexte de la requête.

Transmettre des données au serveur

Comment le client peut-il transmettre des données au serveur ?

Contexte explicite pour les applications dynamiques

L’URL peut contenir des informations, des variables ayant des valeurs.

Les arguments d’une méthode GET : clés - valeurs

Exemple :

http://www.monsite.fr/projet/service.php?id=3&nb=42

Le corps de la requête peut aussi servir transmettre des données : ex. méthode POST (voir ci-après)

Protocole sans état (stateless)

• Chaque requête est effectuée de façon indépendante, et le serveur ne garde pas la trace des requêtes précédentes effectuées par le même client.
• De base, pas de gestion de session dans HTTP (mais des solutions existent, vues plus tard).
• Le contexte peut être transporté explicitement dans des arguments du GET… mais URL pas constantes (et passablement longues)

Démo

Installation Apache en local

Format des messages HTTP

• Très peu de types de requêtes / méthodes (moins d’une dizaine)
• Tout en texte ASCII 7 bits (facile à débugger)
• Syntaxe très simple, avec 4 zones
  1. ligne 1 : requête (ou statut réponse)
  2. plusieurs lignes : en-têtes (optionnels)
  3. ligne vide : séparateur (obligatoire)
  4. reste du message : corps/contenu (qui peut être vide)

Structure d’une requête client

• Canevas :

  Méthode Document Version_HTTP
  En-têtes
                                       (Ligne vide)
  Contenu du Message          optionnel
    ...(saisie d'un formulaire, document à publier)...
  
  

  La ligne vide est importante (fin des en-têtes)

• Exemple :

  1: GET /hello.txt HTTP/1.1
  2: User-Agent: curl/7.16.3 libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3
  3: Host: www.example.com
  4: Accept-Language: en, mi
  5:  
  6: 
  

Structure d’une réponse serveur

• Canevas :

  Version_HTTP Code Signification
  En-têtes
                                       (Ligne vide)
  Contenu du Message
    ...(document HTML, image, ...)...
  
  

• Exemple :

  1: HTTP/1.1 200 OK
  2: Date: Mon, 27 Jul 2009 12:28:53 GMT
  3: Server: Apache
  4: Content-Length: 72
  5: Content-Type: text/plain
  6: 
  7: Salut tout le monde. Mon contenu contient un retour charriot à la fin.
  8:  
  

Actions sur les ressources (CRUD)

• Le client demande dans la requête à effectuer des actions/opérations sur les ressources
• Il « invoque » différents types de méthodes

cf. RFC 9110 HTTP Semantics

Exemple de requête GET

• Demande du document premier.html par le navigateur (firefox)

  GET /premier.html  HTTP/1.1            requête
  Connection: Keep-Alive                 en-têtes (début)
  User-Agent: Mozilla/5.0 (Firefox/3.0.2)
  Host: telecom-sudparis.eu
  Accept: image/gif, image/jpeg, */*     en-têtes (fin)
                                         ligne vide
                                         ici contenu vide
  

Regardez les en-têtes dans les outils pour le développeur de vos navigateurs

Exemple de réponse à un GET

• Envoi du document HTML par le serveur Web Apache

     HTTP/1.1 200 OK                         réponse
     Date: Mon, 11 Nov 2008 17:47:24 GMT     en-têtes (début)
     Server: Apachee/2.2.3 (Debian GNU/Linux) 
             Perl/v5.8.4 PHP/5.2.6 
     Last-Modified: Wed, 28 Apr 2008 15:55:02 GMT
     Content-length: 327
     Content-type: text/html                 en-têtes (fin)
                                             ligne vide
     <HTML>                                  contenu
     ... document HTML ...
     </HTML>
  

  La première ligne contient le code de statut :
  200 OK

Méthode GET

Récupérer la représentation d’une ressource

• Seule méthode à l’origine
  ⇒ usage très simple : GET doc.html
• Méthode la plus utilisée qui permet de :
  • Récupérer le contenu d’un document
  • Activer exécution de programme sur serveur
  • Envoyer des données : ...programme?nom=paul
• Avec GET, contenu du message dans la requête toujours vide

Autres méthodes

• HEAD : comme GET, mais récupérer seulement l’en-tête
• POST : envoi de données pour traitement côté serveur (ex : contenu d’un formulaire HTML)
• PUT : envoi du contenu d’un document, pour enregistrement sur le serveur
• DELETE : suppression d’un document

• CONNECT : établir un tunnel vers le serveur hébergeant une ressource (serveur proxy)
• OPTIONS : demande des options gérées par le serveur pour l’accès à une ressource
• TRACE : effectue un test d’accès complet le long du chemin d’accès à une ressource (ping / echo)

Keep Calm

En pratique, au-delà de cette séquence, vous utiliserez et gérerez principalement :

• GET
• POST

L’affaire se corsera pour ceux qui s’intéresseront aux services Web fonctionnant avec des API sur HTTP (REST)

Codes de réponse du serveur

De 100 à 199

Messages d’information

De 200 à 299

Succès. Exemple : 200 Okay

De 300 à 399

Redirections

De 400 à 499

Erreurs du client. Ex. : 404 Not Found

De 500 à 599

Erreurs du serveur. Ex. : 501 Internal Server Error

Rôle des en-têtes (headers)

• Ajoute du contexte (propriétés du client, autorisations …)
• Détaille les caractéristiques des flux (encodage, taille …)
• Optimisations (cache, …)
• Gestion d’une session au-dessus d’un protocole sans état (cookies, …)
• Éléments propres à l’application (extensible)

En-têtes généraux

Aussi bien dans requêtes ou réponses

Les caches et proxy

Cache-Control, Pragma, Via

La connexion

Connection

La date

Date

Le codage

MIME-Version, Transfer-Encoding

En-têtes de requêtes

• Préférences du client : types, caractères, langage…
  • Accept
  • Accept-Encoding, Accept-Charset, Accept-Language, …
• Identification du client/serveur : site, e-mail, source…
  • Host
  • From
  • Referer
  • User-Agent

En-têtes de requêtes (suite)

• Contrôle d’accès et sessions (login, cookies…)
  • Authorization
  • Cookie
• Conditions pour le serveur (sur la date…)
  • If-Modified-Since
  • If-Match
  • If-Range
  • If-Unmodified-Since
• Autres (pour proxy)
  • Max-Forwards

En-têtes de réponses

• Informations sur le contenu : type, taille, URL, encodage…
  • Content-Type
  • Content-Length
  • Content-Encoding
  • Content-Location
• Informations sur la date de modification ou la durée
  • Last-Modified
  • Expires

En-têtes de réponses (suite)

• Identification du serveur : nom, formats…
  • Server
  • Accept-Range
  • Location

• Compléments pour le client : durée, âge…
  • Age
  • Retry-After
  • Warning

• Autres :
  • Allow : méthodes autorisées
  • Etag : entité de balisage

En-têtes de réponses (suite)

• Demande d’authentification
  • WWW-Authenticate
• Envoi de cookies
  • Set-Cookie

Moniteur réseau dans navigateur

Sera vu en partie TP

CURL en ligne de commande

https://curl.haxx.se/

Client en ligne de commande

man curl

Barre d’outils Symfony

Take away

• client HTTP
• serveur HTTP
• format des requêtes / réponses dans HTTP
  • requêtes GET, POST, …
  • status codes : 200, 40x, …

Séquence TP n°4

• Découverte Contrôleur Web Symfony, sur ToDo
• Ajout Contrôleurs Web dans projet

Q / R

Copyright

• Document propriété de ses auteurs et de Télécom SudParis (sauf exceptions explicitement mentionnées).
• Réservé à l’utilisation pour la formation initiale à Télécom SudParis.