Archi Couche Application

Identification

Infoforall

4 - Protocole HTTP


Nous allons aujourd'hui voir un peu plus dans le détail le principe d'une communication Web et son passage sur le réseau Internet.

Cette activité spécifique se concentre sur la communication entre votre navigateur et le serveur.

Evaluation ✎ : questions 03-04-05-06-15-16-18-19-20-.

Documents de cours : open document ou pdf

1 - Couche Application

(Rappel) 1.1 Protocole HTTP

A - Principe

Le protocole HTTP est destiné à faire communiquer deux programmes :

  • Un programme client HTTP qui se connecte à
  • un programme serveur HTTP.

Le protocole HTTP est basé sur une communication en 3 étapes :

1 Requête - 2 - Traitement - 3 - Réponse
Requête - Traitement - Réponse
  1. Le client envoie sa requête (nous verrons qu'il utilise une URL).
  2. Le serveur reçoit et analyse la requête
  3. Le serveur renvoie sa réponse (nous verrons qu'elle contient parfois un texte nommé code-source HTML)
B - Une notion connue : le code de réponse

La réponse HTTP contient un nombre, le code de réponse. Vous connaissez certainement le 404. Les voici :

  • Code 200 : le serveur dit que tout s'est bien passé.
  • Code 404 : le serveur ne trouve aucune ressource correspondant à la requête.
  • Code 300 : le serveur dit que la ressource n'a pas été modifiée depuis la dernière fois que le client lui a demandé. Le client doit juste aller voir dans sa mémoire-cache.
  • Code 500 : le serveur rencontre une erreur de programmation en tentant de résoudre la requête....
C - Le programme client usuel : le navigateur Web
  • Firefox de la fondation Mozilla,
  • le moteur libre Chromium, produit par Google
  • Chrome, une surcouche propriétaire de Chromium, produit par Google.
  • Safari pour Apple
  • Brave, une surcouche libre de Chromium, produit par Brave Software.
  • Safari pour Apple
  • ...
(Rappel) 1.2 La couche APPLICATION
graph LR subgraph Programme A I(("Code\ninterne")) <-. communication .-> D["APPLICATION\nformatage\nou\nextraction"] end subgraph Programme B A["APPLICATION\nformatage\nou\nextraction"] <-. communication .-> S(("Code\ninterne")) end D <--> Mystere["..."] <--> A style A fill:#6ff,stroke:#880,stroke-width:2px style D fill:#6ff,stroke:#880,stroke-width:2px style Mystere fill:#99f,stroke:#333,stroke-width:2px

Qu'est que la couche APPLICATION ?

C'est un programme chargé de mettre en forme les informations sous un format précis connus de tous.

Deux cas se présentent :

  • Envoi : mise en forme codifié des informations que veut transmettre un programme.
  • Réception : extraction des informations contenus dans le message codifié réçu.

Cette couche fait donc office d'INTERFACE entre un programme et le monde extérieur.

Exemple : le format HTTP
  • On commence par écrire l'en-tête HTTP qui est composé de deux parties :
    1. une première ligne contenant 3 informations : la méthode d'envoi, la ressource voulue et le protocole utilisé. L'espace (octet de valeur 32) est le caractère délimiteur.
    2. plusieurs autres lignes constituant une sorte de dictionnaire : la clé (nom de l'information), le caractère : et la valeur de cette information.
  • On finit par le message en lui-même. Lorsque le serveur HTTP répond, c'est là qu'il place les octets d'un code HTML ou les octets d'une image par exemple.
Exemple de requête POST

Voici une requête POST qu'envoie un client (Firefox tournant sous Linux) pour tenter de connecter l'utilisateur bob dont le mot de passe est 1234! :

POST /login/ HTTP/1.1
Host: www.infoforall.fr
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:82.0) Gecko/20100101 Firefox/82.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: fr,fr-FR;q=0.8,en-US;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate, br
Content-Type: application/x-www-form-urlencoded
Content-Length: 118
Origin: https://www.infoforall.fr
Connection: keep-alive
Referer: https://www.infoforall.fr/act/archi/communication-client-serveur/
Upgrade-Insecure-Requests: 1
X-Real-Ip: 2a01:cb0c:902:ae00:414b:2c22:4edf:3b17
Via: 1.1 alproxy
X-Forwarded-Proto: https

alias=bob_eponge&mdp=1234!

FIN DE LA REQUETE

(Rappel) 1.3 Les différents protocoles

De nombreux protocoles ont été élaborés en fonction des besoins de données à transmettre :

Pourquoi pas un seul et unique protocole ?

Selon le type de l'application, on aura besoin d'optimiser certains aspects, de parler beaucoup ou pas, de transmettre certaines informations à propos de l'ordinateur ou pas... D'où un grand choix.

Quelques protocoles APPLICATION
  • Protocole HTTP pour le Web (entre le programme-navigateur et le programme-serveur par exemple)
  • Protocole FTP pour les téléchargements et les téléversements (entre votre programme et le programme-serveur qui stocke les fichiers)
  • Protocole POP pour lire ou envoyer les emails (entre le programme d'emails et le programme-serveur email)
  • Protocole IMAP pour lire ou envoyer les emails (un peu plus fourni que POP)
  • ...

Quel est le type de données envoyées par votre navigateur lorsqu'il fait une requête HTTP ? Du texte. Ou plutôt une suite d'octets encodant une chaîne de caractères en ASCII.
Pour transmettre un A, l'octet vaut 6510 ou 4116.
Pour transmettre un B, l'octet vaut 6610 ou 4216...

...ASCII...

Table ASCII en version hexadécimale
_0 _1 _2 _3 _4 _5 _6 _7 _8 _9 _A _B _C _D _E _F
0_ NUL SOH STX ETX EOT ENQ ACK BEL BS HT LF VT FF CR SO SI _0
1_ DLE DC1 DC2 DC3 DC4 NAK SYN ETB CAN EM SUB ESC FS GS RS US 1_
2_ ! " # $ % & ' ( ) * + , - . / 2_
3_ 0 1 2 3 4 5 6 7 8 9 : ; < = > ? 3_
4_ @ A B C D E F G H I J K L M N O 4_
5_ P Q R S T U V W X Y Z [ \ ] ^ _ 5_
6_ ` a b c d e f g h i j k l m n o 6_
7_ p q r s t u v w x y z { | } ~ DEL 7_
_0_1_2_3_4_5_6_7_8_9_A_B_C_D_E_F

2 - Protocole HTTP de la couche Application

Nous allons maintenant analyser l'un des protocoles de cette couche : le protocole HTTP.

1 Requête - 2 - Traitement - 3 - Réponse
Requête - Traitement - Réponse

Lorsque vous avez lancé cette page, la demande suivante étant présente dans votre barre de navigation :

https://www.infoforall.fr/act/archi/communication-tcp-ip/

Votre programme-navigateur a alors compris où vous vouliez aller et à codifier votre demande en utilisant la couche APPLICATION selon le protocole HTTP. Vous allez voir ci-dessous le texte que votre navigateur a réellement envoyé lorsque vous avez lancé votre requête le mar 21 Mai 2024 à 10:38 (heure serveur) pour afficher cette page.

Texte réel de la requête envoyée par le navigateur, conçu à partir de la barre d'adresses :

.............................DEBUT DE LA REQUETE HTTP

GET /act/archi/protocole-http-couche-application/ HTTP/1.1
Host: www.infoforall.fr

User-Agent: CCBot/2.0 (https://commoncrawl.org/faq/)
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
If-Modified-Since: Mon, 04 Dec 2023 20:10:09 GMT
Accept-Encoding: br,gzip
X-Real-Ip: 34.239.158.223
Via: 1.1 alproxy
X-Forwarded-Proto: https

MESSAGE VIDE

.............................FIN DE LA REQUETE HTTP

J'ai rajouté un visuel pour les passages à la ligne (line feed) car il s'agit d'un vrai octet (code ASCII 1010 ou 0A16). Normalement le caractère n'est pas visible car il n'est pas un caractère d'imprimerie mais un caractère de contrôle : il provoque...le passage à la ligne. Il s'agit du caractère encodé par \n dans un string Python.

Comme vous le voyez, la requête HTTP est donc un texte codifié, les informations sont placées à certains endroits précis pour que le programme-serveur puisse les retrouver.

01 Dans cette requête HTTP, quelles sont les informations transmises

  • Sur la première ligne (3 informations différentes)?
  • Sur la deuxième ligne ? (une information)
  • Sur la troisième ligne ? (une information)

...CORRECTION...

  • Sur la première ligne ? Méthode utilisée espace ressource demandée espace version de HTTP utilisée.
  • Sur la deuxième ligne ? Le nom de domaine du serveur qu'on veut joindre
  • Sur la troisième ligne ? Ca dépend des systèmes. Par exemple, c'est parfois la longueur en octet du message interne transmis avec la requête : ici 0 car c'est un GET : toutes les informations sont transmises via l'URL, il n'y a pas de message sous l'en-tête fournissant différentes informations.

Un exemple de réponse HTTP possible, envoyée par le programme-serveur après qu'il ai traité la requête HTTP :

.............................DEBUT DE LA REPONSE HTTP

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Content-Length: 36435
Vary: Cookie
Via: 1.1 alproxy
Date: Thu, 19 Mar 2020 12:54:47 GMT


<!DOCTYPE html>
<html lang="fr">
<head>
...
: la suite, c'est donc le reste du fichier html !
...
</html lang="fr">

.............................FIN DE LA REPONSE HTTP

Encore une fois, il s'agit d'un texte codifié par le serveur de façon à ce que le navigateur puisse facilement retrouver les informations dont il a besoin.

02 Dans cette réponse HTTP, quelles sont les informations transmises

  • Sur la première ligne (3 informations différentes)?
  • Sur la deuxième ligne ? (une information principale et ici une info complémentaire)
  • Sur la troisième ligne ? (une information)

...CORRECTION...

  • Sur la première ligne ? version de HTTP utilisée pour répondre espace code de la réponse espace texte complémentaire liée au traitement de la requête initiale
  • Sur la deuxième ligne ? Le type des données contenu dans le message sous l'en-tête : ici les octets d'un code HTML qu'il faudra décoder en utilisant UTF-8.
  • Sur la troisième ligne ? La longueur en octet du message interne transmis avec la requête : ici 36435 octets, soit 36ko environ.
Protocole HTTP de la couche Application (2) : la Communication HTTP

Le protocole HTTP est l'un des protocoles de la couche APPLICATION. HTTP est basé sur le principe client-serveur.

HTTP veut dire Hyper Text Transfert Protocol.

Le programme-client fait une requête HTTP composée de plusieurs parties :

  1. Une première ligne d'informations (méthode - ressource demandée - protocole utilisé)
  2. Les lignes de l'en-tête sous la forme clé: valeur
  3. Une ligne vide
  4. Le contenu du message lui-même

Le programme-serveur reçoit la requête, la traite et renvoie une réponse HTTP composée de plusieurs parties :

  1. Une première ligne d'informations (protocole utilisé - code réponse - texte descriptif complémentaire)
  2. Les lignes de l'en-tête sous la forme clé: valeur
  3. Une ligne vide
  4. Le contenu du message lui-même

Sous l'en-tête de la réponse HTTP, le message du serveur contient donc soit :

  • le code HTML de la page à afficher si le client demande un fichier HTML (une suite d'octets donc)
  • le code CSS si le client demande un fichier CSS (une suite d'octets donc)
  • le code JS si le client demande un fichier JS (une suite d'octets donc)
  • le code de l'image à afficher si le client demande une image (une suite d'octets donc)
  • ...

Notez bien la présence d'une ligne vide entre l'en-tête et le message transporté par la communication : imposée par le protocole HTTP, elle permet à celui qui reçoit la communication de détecter facilement la fin de l'en-tête et le début du message en lui-même : il suffit de détecter deux octets 10 (passages à la ligne) successifs.

Protocole HTTP de la couche Application (3) : les méthodes GET et POST

La requête HTTP peut se faire de plusieurs façons. En voici deux :

  1. La méthode GET :
    • on transmet les informations supplémentaires dans l'URL : le message de la requête est donc vide.
    • utile pour transmettre un nombre limité de données
    • jamais pour transmettre un mot de passe : l'url étant visible dans la barre de navigation, en regardant l'écran de quelqu'un on pourrait facilement voir le mot de passe !
  2. la méthode POST :
    • on transmet les informations supplémentaires dans le message : c'est que vous faites lorsque vous envoyez vos copies numériques : votre texte n'apparait pas dans l'URL.
    • utile pour transmettre un nombre important de données
    • utile pour transmettre des données sensibles : elles n'apparaissent pas dans l'URL affichée.

Culture générale : sachez qu'il existe aussi des requêtes :

  • HEAD : permet de ne recevoir que l'en-tête d'une page, pas le corps du message en lui-même : ça permet de savoir si une page existe, a été mise à jour ...
  • DELETE : permet de supprimer une ressource sur le serveur
  • PUT : permet de placer une ressource sur le serveur

✎ 03 QCM : La requête que vous avez effectué pour visualiser cette page est-elle une requête 

  • A : GET
  • B : POST
  • C : HEAD
  • D : PUT

✎ 04 QCM : Sur la fin de la première ligne de la requête se trouve la version du protocole HTTP utilisé pour formaliser la requête. Quelle version HTTP le serveur distant devra-t-il utiliser pour décoder correctement votre requête ?

  • A : 0.9
  • B : 1.0
  • C : 1.1
  • D : 2.0

✎ 05 Quel est le nom du serveur distant (Host) qu'on tente de joindre ?

✎ 06 En regardant les lignes sous la ligne du GET, on trouve l'ensemble des en-têtes que votre navigateur a envoyé au serveur ou que le serveur a récupéré d'une manière ou d'une autre. Est-ce une communication utilisant http ou https ? Trouvez la ligne comportant une indication sur la nature HTTP ou HTTPS dans la demande. Fournir la ligne et le protocole utilisé.

On notera que le serveur récupère également des informations qui seront rajoutées ensuite. Notamment votre adresse IP : ce que j'affiche sur cette page est une partie de l'en-tête reçu par le serveur. On y trouve surtout X-Real-Ip qui contient l'IP ayant à priori fait la requête HTTP initiale.

Regardons maintenant la vraie réponse que vous a fourni le serveur du site.

3 - Voir HTTP avec Firefox

Cette partie vous montrera comment utiliser certains menus de Firefox pour visualiser une partie de HTTP.

07° Dans Firefox, activer le menu, choisir Développement Web puis réseau :

Accès à l'outil Réseau

08° Actualiser la page https://www.infoforall.fr/act/archi/communication-tcp-ip/ sur laquelle vous êtes actuellement.

Remonter en haut des fichiers que vous venez de télécharger : vous devriez tomber sur un fichier HTML : il s'agit du code HTML de la page. C'est bien la première chose que vous transmet le serveur.

Quel est le code obtenu sur la plupart des fichiers ?

  • 200 pour dire que la réponse s'est bien passée
  • 304 pour signaler que le fichier demandé n'a pas été modifié depuis la dernière demande et que vous pouvez donc juste utiliser celui que vous avez en mémoire cache.
  • 404 pour signaler que la requête n'a pas pu aboutir : le serveur fonctionne bien mais il ne sait pas quoi vous répondre.
  • 500 pour signaler que le serveur rencontre un problème : la demande a créé un problème bloquant l'exécution

Parvenez-vous à reconnaitre d'autres types de fichiers parmi les fichiers affichés ?

...CORRECTION...

Sur le visuel ci-dessous, on voit que le premier document est un document de type HTML.

Le code 200 permet d'indiquer que la requête et la réponse se sont bien déroulées. Tout est ok.

On voit que le navigateur a fait plusieurs demandes :

  • D'abord le fichier HTML et ensuite
  • des fichiers CSS
  • des fichiers images
  • des fichiers JS

Voici un visuel des choses qu'on peut obtenir avec https://www.infoforall.fr :

Résultats d'une requête
Pourquoi cet ordre dans les demandes ?

Comment le client sait-il quels fichiers demandés en plus du code HTML reçu ? C'est simple : Firefox reçoit le code HTML, il le lit !

Si vous voulez savoir dans quel ordre vous devriez recevoir les fichiers, vous pouvez faire un clic-droit et utiliser AFFICHER CODE SOURCE. On part de la ligne 1 et on descend séquentiellement.. Si la ligne 13 contient la référence d'un fichier CSS, il le demande en envoyant une nouvelle requête HTTP.

Votre navigateur lit donc le HTML séquentiellement et fait les demandes de fichiers annexes au fur et à mesure qu'il détecte qu'il va en avoir besoin : CSS. JS, images apparaissent lors de la lecture du HTML.

09° Cliquer sur la première ligne : celle du fichier HTML. Vous devriez obtenir un affichage proche de celui présenté ci-dessous.

Détails d'une requête

10° En regardant le détail de la demande, répondre aux questions suivantes :

  • Avez-vous effectué une requête de type GET ou de type POST ?
  • Quelle est l'adresse IP (adresse numérique internet) du site joignable par le nom www.infoforall.fr ?
  • Le port 443 est-il bien compatible avec une liaison à un serveur HTTPS ou un serveur HTTP ?

...CORRECTION...

Nous avons fait une requête de type GET : on veut juste recevoir des informations (et au pire en fournir quelques unes peu nombreuses)

L'adresse IP du site est notée [2a00:b6e0:1:20:2::1]:443 sur l'image.

Vous avez peut-être déjà vu que le port 80 est le port des serveurs HTTP et 443 le port des serveurs HTTPS. Plus de détails dans la partie suivante.

11° Cliquer sur le bouton En-têtes brutes de la REPONSE de façon à voir le contenu de l'en-tête telle que le navigateur l'a reçu avant de vous le remettre en forme. Vous devriez constater qu'il s'agit bien d'un simple contenu texte.

ATTENTION : il s'agit juste de l'en-tête. On n'affiche pas le message interne qui se trouve normalement après l'en-tête HTTP. Mais il y a un onglet REPONSE si vous voulez le voir, et on y trouve un bouton code brut.

Un exemple de réception possible (j'ai rajouté l'endroit où se trouve le message interne renvoyé) :

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
X-Frame-Options: SAMEORIGIN
Content-Length: 36435
Vary: Cookie
Via: 1.1 alproxy
Date: Thu, 19 Mar 2020 12:54:47 GMT


<!DOCTYPE html>... : la suite, c'est le fichier html au complet !

12° Descendre encore un peu plus bas : activer également En-têtes brutes mais cette fois sur l'en-tête de la REQUETE que votre navigateur a réellement envoyé. Comme vous pourrez le voir, nulle trace à ce moment de votre adresse IP : elle apparaît sur l'en-tête reçu par le site, c'est bien qu'on a rajouté l'information à un moment.

13° Faire cette demande inconnue https://www.infoforall.fr/ast/snt/historique-du-webeeux/. Comment le navigateur va-t-il savoir que quelque chose s'est mal passé ? Quelle est le numéro de la réponse cette fois ?

Erreur 404

...CORRECTION...

Il s'agit de la fameuse erreur 404 !

Lorsque le navigateur reçoit une réponse http de ce type du serveur, il sait que le serveur lui dit que sa requête n'a pas pu aboutir pour une raison simple : la ressource demandée n'existe pas ! La plupart du temps, il s'agit d'une ressource qui a existé mais qu'on a supprimé du serveur.

La plupart des sites proposent des pages 404 personnalisées.

14° Faire la requête inconnue suivante sur le site de blizzard (bloqué au lycée):

https://www.blizzard.com/fr-fr/testrate/.

Répondre ensuite aux questions suivantes :

  • Quel protocole a été utilisé ?
  • Quel est le nom du serveur à contacter ?

...CORRECTION...

  • Quel protocole a été utilisé ? https
  • Quel est le nom du serveur a contacté ? www.blizzard.com
  • Quelle est la requête demandée à ce serveur ? /fr-fr/testrate/
  • Quel est son IP ? 34.253.25.0:443 au moment où moi j'ai fait le test
  • Quel est le numéro de sa réponse ? 404 !

✎ 15° Choisir et fournir une URL. A l'aide de code source de la page, donner les 3 premières requêtes qui vont être demandées après lecture de la première réponse HTTP contenant le code HTML de la page.

4 - Transférer des données : méthodes GET et POST

Nous avons vu que le HTTP était basé sur un modèle client-serveur.

1 Requête - 2 - Traitement - 3 - Réponse
Requête - Traitement - Réponse

Un programme-serveur tourne sur un ordinateur distant qu'on nomme machine-serveur ou juste serveur par simplification.

Les étapes de la communication :

  • Etape 1 : un programme-client (un navigateur, un robot-explorateur, ...), va envoyer une requête http au serveur.
  • Etape 2 : le programme-serveur reçoit la requête http et va la traiter. C'est cette étape que nous allons voir aujourd'hui.
  • Etape 3 : le programme-serveur répond en envoyant sa réponse http au client.

Pour transmettre des informations au serveur, nous avons vu que le client pouvait utiliser les méthodes GET et POST :

  • Avec GET, on transmet toutes les informations pour le serveur directement via l'URL.
  • Avec POST, on transmet une partie des informations pour le serveur dans le corps du message.

La différence est donc liée à l'endroit où on place les paramètres qu'on peut envoyer à la page.

✎ 16° Tapez ceci dans la barre de navigation et revenez ensuite à cette question 16.

https://www.infoforall.fr/act/archi/protocole-http-couche-application/?user=toto&password=1234

  1. regardez la requête ci-dessous
  2. regardez ce qui a changé dans la requête ci-dessous reçue par le serveur.

Question : dans une requête de type GET, les paramètres sont-ils transmis dans l'URL ou sont-ils intégrés au corps (BODY) de la requête ?

GET /act/archi/protocole-http-couche-application/ HTTP/1.1
Host: www.infoforall.fr

User-Agent: CCBot/2.0 (https://commoncrawl.org/faq/)
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
If-Modified-Since: Mon, 04 Dec 2023 20:10:09 GMT
Accept-Encoding: br,gzip
X-Real-Ip: 34.239.158.223
Via: 1.1 alproxy
X-Forwarded-Proto: https

BODY VIDE !

FIN DE LA REQUETE
Méthode GET : paramètres dans l'URL

La méthode GET permet de discuter très facilement avec le serveur : les paramètres qu'on veut lui transmettre sont directement dans l'URL.

Derrière la ressource demandée, vous allez trouver un caractère ? pour indiquer qu'il y a des paramètres à récupérer derrière.

Exemple : ?user=toto&password=1234

Voici la codification du passage en GET :

  • Présence de /? après la ressource demandée
  • Présence d'un premier couple user=toto
  • Présence optionnelle d'un & pour signaler qu'il y a un autre paramètre à la suite : &password=1234
  • Tant qu'il y a des &, on continue...

Sur cet exemple, on voit donc qu'on transfère deux paramètres au serveur :

  1. user valant toto
  2. password valant 1234

Petit rappel sur la lecture d'une URL 

https://www.infoforall.fr/act/archi/communication-client-serveur/?user=toto&password=1234

  • En première position, on trouve le protocole utilisé
    • https://www.infoforall.fr/act/archi/communication-client-serveur/?user=toto&password=1234
  • Ensuite le nom ou l'adresse IP de la machine serveur à joindre :
    • https://www.infoforall.fr/act/archi/communication-client-serveur/?user=toto&password=1234
      • Sous-domaine à gauche : www
      • Domaine à droite : infoforall.fr
  • L'adresse absolue de la ressource sur le serveur : elle commence par un slash / pour indiquer qu'on part de la racine du service :
    • https://www.infoforall.fr/act/archi/communication-client-serveur/?user=toto&password=1234
  • Derrière, ce sont les paramètres éventuels.

17° La boîte ci-dessus vous permet de voir la valeur des paramètres éventuels question et numero envoyés sur cette page. Avez-vous transféré de tels paramètres ou sont-ils inexistants dans votre URL pour l'instant ?

Valeur du paramètre question :

Valeur du paramètre numero :

Ce ne sont pas les bonnes valeurs de paramètres !

Deuxième partie : restez sur la page où vous êtes et :

  1. transférez (via l'URL de la barre d'adresses) le paramètre question à la valeur corrige et le paramètre numero à la valeur 2.
  2. appuyez sur Entrée dans la barre d'adresses puis revenez ici.
  3. label
  4. Vous devriez voir un affichage BRAVO ! juste au dessus.

Magie !

Noter sur la copie numérique l'URL que vous avez dû taper pour obtenir BRAVO.

SI VOUS BLOQUEZ : voir le bout de cours juste au dessus, celui nommé Méthode GET : paramètres dans l'URL.

✎ 18° Un serveur reçoit une requête GET de ce type :

www.infoforall.fr/question_trop_difficile/?difficulte=outch&note=4

A-t-on transmis des paramètres ? Lesquels ? Quelles sont leurs valeurs ?

✎ 19° Puisque taper des variables directement dans l'URL n'est pas très pratique pour un utilisateur, on utilise plutôt des formulaires sur le Web : l'utilisateur rentre ses valeurs, appuie sur le bouton ENVOYER ou SUBMIT et c'est le navigateur qui se charge de formuler correctement la demande en respectant les normes HTTP d'une méthode GET.

Utiliser le formulaire ci-dessous pour observer comment la demande a été reçu par le site.

Voyons maintenant la méthode POST. Cette fois, le client va transmettre les données fournies dans le corps de la requête HTTP.

✎ 20° Utiliser le formulaire ci-dessous en choisissant des valeurs pour les paramètres question et numero. En appuyant sur SUBMIT, vous allez envoyer les données vers une page acceptant la requête en POST. On y affiche le contenu de la requête.

Deux réponses à fournir sur la copie :

  1. En lisant la requête, où voit-on qu'il s'agit d'une requête POST ?
  2. Où se trouvent cette fois les informations liées aux paramètres envoyés : dans le corps (body) de la requête ou dans l'URL ?

Attention, il a donc deux façons de modifier une page en fonction des données fournies par le client :

Script côté CLIENT

Vous avez appliqué cette méthode lors de votre découverte de Javascript.

On peut utiliser un code côté client : un code Javascript a été envoyé par le serveur.

Le code tourne actuellement sur l'ordinateur-client.

C'est ce que vous avez fait lorsque vous avez découvert JS. On utilise donc les ressources du client pour réaliser le traitement des données : on peut lire le contenu dans le formulaire et modifier les balises en cherchant les références à l'aide des attributs. Le code HTML est donc modifié sur la machine client APRES l'envoi par le serveur.

JS modifiant le HTML côté CLIENT
Modification côté CLIENT
  • Langage de script usuel : Javascript.
  • Avantage : on utilise les ressources du client et on peut réagir à ses actions en temps réel.
  • Désavantage : un client sachant lire le code source peut lire votre code très facilement. Ce n'est pas utilisable pour gérer un mot de passe.
Programme côté SERVEUR

Cela, vous ne savez pas encore le faire.

On a utilisé un code côté serveur : le programme tourne sur l'ordinateur-serveur.

Ce programme analyse la requête GET ou POST pour récupérer les paramètres. Le serveur envoie alors un code HTML en fonction du résultat du test : bonne correspondance alias - mot de passe ou pas.

JS modifiant le HTML côté SERVEUR
Modification côté SERVEUR

Ca, vous ne l'avez pas encore fait. Nous allons le faire aujourd'hui.

  • Plein de langages disponibles :
    • PHP est certainement le plus connu car le premier a avoir permis de faire cela facilement. Wordpress fonctionne en PHP.
    • on peut utiliser Python
    • on peut utiliser Javascript (mais côté serveur attention !)
    • ... et plein d'autres encore.
  • Avantage : le client ne peut aucunement avoir accès à ce code. Et ça, c'est fondamental dès que vous voulez gérer des mots de passe.
  • Désavantage : c'est l'ordinateur-serveur qui travaille. Il doit donc être assez puissant pour gérer toutes les demandes des clients.
Couche TRANSPORT Protocole : TCP (et +) Adresse : PORT Message : SEGMENT DATA d'un programme SEGMENT TCP Port SRC 443 Port DST 2050 Seq 4 Suiv 2 Flags : ACK CS : 15241 PAQUET IP IP DST 25.25.25.5 IP SRC 45.45.45.2 TRAME (Ethernet ou Wifi) SEQUENCE INTIALE MAC DST MAC SRC CheckSum selon le type de trame Couche RESEAU Protocole : IP (et +) Adresse : IP Message : PAQUET Couche LIAISON Protocole : WLAN ... Adresse : MAC Message : TRAME Couche Application HTTP pour Firefox Couche Application IMAP pour Thunderbird Couche Application Serveur HTTP Communication prog A Comm. prog B A B Rq TCP Rp1 TCP Rp2 TCP vide TCP ? A TCP IP Trame B TCP IP Trame data SRC 2050 DST 443 Seq data SRC 24945 DST 443 Seq data SRC DST CS data Seq Suiv F vide Seq Suiv F SRC 2050 DST 443 F ACK Suiv 0 Seq 1 CS XXXXX

Nous avons donc vu comment deux programmes parviennent à communiquer, ici en se transférant un simple texte codifié respectant un protocole et possèdant des informations supplémentaires en plus du message en lui-même.

La couche APPLICATION est chargée de structurer la communication entre deux programmes utilisant un même protocole. Pour cela, elle doit pouvoir

  1. structurer correctement la communication qu'un programme envoie ou reçoit : elle sait faire
  2. transmettre la communication à l'autre programme : elle ne sait pas faire cela...

Du coup, comment fait-elle ?

La couche APPLICATION va faire appel à une amie qui pourra transmettre le message : la couche TRANSPORT.

On retrouve bien l'idée que pour faire une chose complexe, on décompose en plusieurs tâches plus simples.

Le détail dans l'activité suivante.

5 - FAQ

Rien pour le moment

6 - QCM de fin de 1er

En cours de réalisation

La prochaine activité traitera donc du transfert du message à l'aide de la couche TRANSPORT qui peut utiliser notamment le protocole TCP.

Activité publiée le 15 05 2021
Dernière modification : 27 05 2021
Auteur : ows. h.