Protocole HTTP

• Ouvrez un terminal puis utilisez la commande mkdir un_nom_de_répertoire pour créer un nouveau répertoire « protocole-http » dans « $HOME » suivie de la commande cd un_chemin_relatif_ou_absolu pour vous placer dans le répertoire
• Initialisez le dépôt Git du projet

  git init

• Effectuez une première validation

  git commit --allow-empty -m "Initial commit"

• Éditez le fichier « .gitignore » pour exclure les fichiers binaires inutiles à votre projet (fichiers pptx du cours, …), les fichiers qui contiennent des mots de passe ou, dans le cas des projets collaboratifs, les fichiers créés par votre éditeur de texte (répertoire « .idea » pour PhpStorm)
• Éditez un fichier « README.md » dans lequel doivent figurer :
  • un titre de niveau 1 contenant le titre explicite du projet
  • un titre de niveau 2 « Auteur(s) » vous permettant de préciser votre nom et votre prénom (ainsi que ceux de votre binôme, le cas échéant)
  • un titre de niveau 2 « Installation / Configuration » précisant les points essentiels permettant d'installer, de configurer et de lancer le projet
• Ajoutez les fichiers au dépôt

  git add .

• Effectuez une nouvelle validation

  git commit -m "Repository setup"

• Si nécessaire, renommez la branche principale en « main » (une branche vide ne peut pas être renommée, c'est pourquoi ceci est fait après le premier commit)

  git branch -m main

  Notez que vous pouvez le faire de façon définitive avec la commande suivante, à condition d'utiliser git dans une version supérieure à 2.28

  git config --global init.defaultbranch main

• Connectez-vous à l'application GitLab et créez un dépôt portant le même nom que votre nouveau répertoire en pensant à décocher la case « Initialize repository with a README »
• Accordez la permission « Reporter » à votre enseignant de TP/TD
• Associez le dépôt local et le dépôt distant

  git remote add origin https://iut-info.univ-reims.fr/gitlab/votre_login/protocole-http.git

• Poussez le dépôt local vers le dépôt distant

  git push -u origin main

• Vous effectuerez une validation après chaque question.
• À la fin de chaque séance, vous effectuerez une validation. Si cette validation contient du code incomplet ou ne fonctionnant pas, mentionnez-le dans le message de validation. Vous pousserez ensuite votre travail vers le dépôt distant.
• Ce dépôt sera utilisé par votre enseignant(e) de TP pour évaluer votre travail, que cela conduise à un note ou pas. Assurez-vous donc régulièrement que tous les fichiers que vous souhaitez lui rendre sont bien présents dans le dépôt. Respectez les noms des fichiers qui vous sont demandés si des consignes particulières vous sont données.
• Le dépôt lui-même sera évalué, soignez l'écriture de vos messages : clarté, pertinence, orthographe.

L'aide-mémoire Git et l'aide-mémoire GitLab de Monsieur Nourrit pourront vous être utiles.

Lorsque la ressource récupérée est un contenu HTML, ce dernier est interprété par le navigateur afin de produire un rendu graphique pour l'utilisateur. Si ce contenu HTML fait référence à des feuilles de style, images, scripts JavaScript, le navigateur doit effectuer des nouvelles requêtes HTTP afin de récupérer ces ressources liées.

Dans le contexte de HTTP 1.0, le serveur ferme systématiquement la connexion réseau après avoir répondu au client. Ceci engendre des pertes de temps et de la consommation inutile de ressources pour établir de nouveau la connexion en cas de requêtes multiples sur le même serveur Web :

HTTP 1.1 introduit la possibilité de demander au serveur de ne pas mettre fin à la connexion réseau, et ainsi permettre d'effectuer plusieurs échanges HTTP sur la même connexion réseau pour gagner du temps et des ressources :

Ce mécanisme est rendu possible par l'introduction de l'en-tête Connection sur lequel nous reviendrons lors de l'étude des requêtes HTTP.

Les navigateurs Web intègrent une « barre de développement » qui apportent des outils précieux pour les développeurs Web. Cette « barre de développement » propose des outils similaires sur tous les navigateurs, avec toutefois quelques variations. Nous utiliserons systématiquement Firefox afin d'illustrer les outils et ne pas avoir à chercher la localisation ou l'option équivalente sur unn autre navigateur. Vous pourrez utiliser le navigateur de votre choix dans la suite de votre cursus.

La première ligne de la requête HTTP est composée de 3 parties :

method path version

• method (méthode ou verbe HTTP) est classiquement GET, POST ou HEAD (mais aussi PUT, DELETE ou PATCH pour les API Web) et correspond à l'opération que le client souhaite effectuer
• path est l'URL de la ressource dont les éléments déductibles sont retirés en fonction du contexte, c'est-à-dire le protocole, l'hôte et port puisque la connexion est déjà établie
• version est HTTP/1.0 ou HTTP/1.1 (HTTP/2 et HTTP/3 modifient le transport des données, mais pas la structure des messages)

• GET / HTTP/1.0
• POST /login HTTP/1.1
• GET /register.php?firstname=John&lastname=Doe HTTP/1.1
• HEAD /avatar.png HTTP/1.1
• …

Cette première ligne peut être suivie d'informations relatives à la requête, les en-têtes HTTP :

• en-tête général : concerne l'échange, la requête
  • Connection: close
  • Cache-Control: no-cache
• en-tête de requête : précisions sur la requête ou le client
  • User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/97.0.4692.71 Safari/537.36
  • Host: example.com
  • Accept-Language: fr-FR,fr;q=0.9,en-US;q=0.8,en;q=0.7
  • Cookie: UserID=JohnDoe
• en-tête d'entité : précisions sur les données envoyées dans le corps du message (payload)
  • Content-Length: 42
  • Content-Type: multipart/form-data; boundary=----WebKitFormBoundary37htlZnm5RVOvzxr

Le corps de la requête, utilisé en méthode POST, peut fournir :

• la partie interrogative (la « query string »)
• la partie interrogative et des fichiers à envoyer au serveur (méthode POST et contenu du corps multipart/form-data)

Le message HTTP qui suit est une requête envoyée l'hôte « example.com », utilisant la methode « GET » pour demander la ressource « / » :

GET / HTTP/1.1
Host: example.com
Connection: close
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Accept-Encoding: gzip, deflate
Accept-Language: fr-FR,fr;q=0.9,en-US;q=0.8,en;q=0.7,pl;q=0.6
Cache-Control: no-cache
Connection: keep-alive
Pragma: no-cache
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/97.0.4692.71 Safari/537.36

Maintenant que vous êtes conscient des échanges HTTP et de la structure des requêtes HTTP, vous allez observer des requêtes en fonction du navigateur et de la manière d'interroger le serveur. Pour cela, vous utiliserez, de manière directe ou indirecte, la ressource http://demo.ad-urca.univ-reims.fr/request/dump/ qui affiche la requête HTTP brute reçue par le serveur.

Les précédentes observations ne concernent qu'une requête GET et sans « query string », c'est-à-dire sans paramètre. Vous allez maintenant tester divers cas de figure en utilisant comme point de départ la page Web http://demo.ad-urca.univ-reims.fr/request/.

La première ligne de la réponse HTTP est composée de 3 parties :

"HTTP/"version status_code status_message

• version vaut 1.0 ou 1.1 (HTTP/2 et HTTP/3 modifient le transport des données, mais pas la structure des messages)
• status_code est le code d'état de la réponse sur 3 chiffres
• status_message est le message typique associé au code précédent (n'importe quel message lisible par un humain peut être fourni)

• HTTP/1.0 200 OK
• HTTP/1.1 301 Moved Permanently
• HTTP/1.1 404 Not Found
• HTTP/1.1 500 Internal Server Error
• …

Les codes d'état de réponse sont regroupés en fonction du premier chiffre :

• 1xx : information
  • HTTP/1.1 100 Continue
• 2xx : succès
  • HTTP/1.0 200 OK
  • HTTP/1.1 201 Created
  • …
• 3xx : redirection
  • HTTP/1.1 301 Moved Permanently
  • HTTP/1.1 302 Found
  • HTTP/1.1 304 Not Modified
  • …
• 4xx : erreur du client
  • HTTP/1.1 400 Bad Request
  • HTTP/1.1 403 Forbidden
  • HTTP/1.1 404 Not Found
  • HTTP/1.1 418 I'm a teapot
  • …
• 5xx : erreur du serveur
  • HTTP/1.1 500 Internal Server Error
  • HTTP/1.1 501 Not Implemented
  • HTTP/1.1 503 Service Unavailable
  • …

La ligne de statut de la réponse est suivie, comme dans tout message HTTP, d'éventuels en-têtes, d'une ligne vide et possiblement d'un corps de réponse. Tout comme dans les requêtes HTTP, les en-têtes de réponse HTTP peuvent être regroupés en :

• en-tête général : concerne l'échange, la requête
  • Connection: close
  • Cache-Control: no-cache
• en-tête de réponse : précisions sur la réponse ou le serveur
  • Location: /login
  • Server: Apache/2.4.6 (CentOS) OpenSSL/1.0.2k-fips PHP/8.0.13
  • Set-Cookie: UserID=JohnDoe; Max-Age=3600
• en-tête de l'entité : précisions sur les données envoyées dans le corps du message (payload)
  • Content-Length: 52
  • Content-Type: text/html; charset=utf-8
  • Content-Disposition: attachment; filename="bill.pdf"
  • Last-Modified: Mon, 24 Jan 2022 12:41:42 GMT

Le corps de la réponse, contient possiblement la ressource demandée par le client.

Suite à cette requête vue dans la partie précédente, le serveur a transmis cette réponse HTTP dont le corps (payload) a été tronqué :

HTTP/1.1 200 OK
Age: 243853
Cache-Control: max-age=604800
Content-Type: text/html; charset=UTF-8
Date: Sat, 22 Jan 2022 18:05:22 GMT
Etag: "3147526947+ident"
Expires: Sat, 29 Jan 2022 18:05:22 GMT
Last-Modified: Thu, 17 Oct 2019 07:18:26 GMT
Server: ECS (bsa/EB15)
Vary: Accept-Encoding
X-Cache: HIT
Content-Length: 1256
Connection: close


<!doctype html>
<html>
<head>
    <title>Example Domain</title>

    <meta charset="utf-8" />
    <meta http-equiv="Content-type" content="text/html; charset=utf-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1" />
    <style type="text/css">
    body {
        background-color: #f0f0f2;
…
    <p><a href="https://www.iana.org/domains/example">More information...</a></p>
</div>
</body>
</html>

Habituellement, les agents utilisateurs (user agents) qui interrogent les sites Web sont les navigateurs Web, les robots d'indexation des moteurs de recherche ou encore les lecteurs d'écran ou les navigateurs en accessibility. Votre navigateur vous permet de :

1. effectuer la connexion TCP sur l'adresse IP du serveur Web identifié dans l'URL saisie dans la barre d'adresse
2. formuler la requête HTTP et de l'envoyer au serveur Web
3. récupérer la réponse HTTP envoyée par le serveur Web
4. décoder le contenu de la réponse HTTP pour en faire un rendu graphique

L'objectif étant ici d'étudier le protocole, les échanges et les messages HTTP, vous allez utiliser un outil en ligne de commande qui permet de :

1. effectuer la connexion TCP sur l'adresse IP du serveur Web dont le nom est fourni en paramètre de la ligne de commande
2. envoyer au serveur Web la requête HTTP que vous aurez formulée dans un fichier désigné en paramètre de la ligne de commande
3. récupérer la réponse HTTP envoyée par le serveur Web
4. afficher dans le terminal le contenu brut de la réponse HTTP

Cet outil en ligne de commande, écrit en PHP et développé en interne, s'utilise de la façon suivante :

http [--secure] --host host --port port file

• --secure est une option facultative pour effectuer une connexion sécurisée sur le serveur (pour HTTPS)
• --host host permet de donner le nom ou l'adresse IP du serveur sur lequel vous souhaitez vous connecter
• --port port permet de donner le port du serveur sur lequel vous souhaitez vous connecter
• file correspond au nom du fichier contenant la requête HTTP complète que vous souhaitez soumettre au serveur

Afin de vous rendre compte des échanges de messages HTTP, vous allez utiliser l'outil d'interrogation HTTP en ligne de commande vu plus tôt pour effectuer diverses requêtes HTTP et prendre connaissance des réponses HTTP fournies par le serveur interrogé.

Le premier mécanisme permettant de produire des réponses spécifiques pour un client est celui des cookies. Le serveur décide de donner la responsabilité au client de lui rappeler un ensemble de valeurs. Le client qui les reçoit doit donc les retransmettre à chaque nouvelle requête sur le même serveur.

Vous connaissez à présent le fonctionnement d'un cookie, vous allez tenter de mesurer les conséquences de sa modification non contrôlée par le client.

Les cookies ont une utilité limitée quand il s'agit de mémoriser des informations volumineuses ou sensibles puisqu'elles sont stockées sur le client et que ce dernier transmet les valeurs à chaque nouvelle requête sur le serveur concerné. Vous avez découvert les sessions en cours magistral et leur capacité à stocker sur le serveur une grande quantité de données, sensibles ou non, dont le lien avec un client particulier est maintenu par un cookie de session qui identifie ledit client.