Requête HTTP et paramètres

Client et serveur

Sur le Web, deux acteurs se parlent :

• le client : ton navigateur (sur ordinateur, tablette ou téléphone), qui demande une page ;

• le serveur : un ordinateur toujours allumé, quelque part dans un centre de données, qui répond.

C'est le modèle client/serveur. Le client envoie une requête, le serveur renvoie une réponse. Le dialogue suit des règles communes : le protocole HTTP (ou HTTPS quand les échanges sont chiffrés).

Le client et le serveur ne font pas le même travail :

• côté serveur : le serveur lit la requête, exécute éventuellement des programmes (par exemple en PHP ou Python), consulte une base de données, puis envoie la page. Ce code reste sur le serveur ;

• côté client : le navigateur reçoit le HTML, le CSS et les scripts (par exemple en JavaScript), affiche la page et exécute les scripts. Ce code a été envoyé au client, donc on peut le lire avec l'inspecteur du navigateur (touche F12).

Décomposer une URL

Une URL est l'adresse d'une ressource sur le Web. Elle se lit de gauche à droite :

https://www.exemple.fr/recherche?q=velo&page=2

Ici, deux paramètres sont passés : q vaut velo et page vaut 2. Le serveur s'en sert pour construire la page : il cherche « velo » et affiche la page 2 des résultats.

La requête HTTP

Quand tu valides une URL, le navigateur envoie un texte structuré au serveur. La première ligne s'appelle la ligne de requête :

GET /index.html HTTP/1.1

• GET : la méthode (ce qu'on veut faire) ;

• /index.html : la ressource demandée ;

• HTTP/1.1 : la version du protocole.

Deux méthodes sont à connaître :

Un formulaire HTML précise la méthode :

<form action="/inscription" method="post">

À la validation, le navigateur envoie une requête POST vers /inscription, avec les champs du formulaire comme paramètres.

La réponse et les codes

Le serveur répond par une page (ou un autre fichier) et un code de statut à trois chiffres :

Le premier chiffre donne la famille : 2 = succès, 4 = erreur du côté du client (mauvaise demande), 5 = erreur du côté du serveur.

Une page web est rarement un seul fichier. Le navigateur demande d'abord le fichier HTML ; en le lisant, il découvre les images, feuilles de style et scripts à charger, et envoie une requête par fichier.

Inspecter et ne pas faire confiance

L'inspecteur du navigateur (F12) affiche le HTML, le CSS, les scripts reçus et les requêtes envoyées, avec leurs paramètres et leurs codes. Il permet de comprendre comment une page fonctionne.

En revanche, il ne montre pas :

• le code exécuté côté serveur (PHP, Python…) ;

• la base de données du site ;

• les mots de passe des autres utilisateurs.

Tout ce qui vient du client peut être modifié : un utilisateur peut changer un paramètre dans la barre d'adresse (promo=OUI devient promo=NON, ou l'inverse), ou désactiver un script de vérification. Le serveur doit donc toujours revérifier les données reçues.

Retour au début : quand tu cherches Lyon – Paris, ton navigateur envoie une requête GET dont l'URL contient depart=Lyon&arrivee=Paris. Le serveur lit ces paramètres, construit la page correspondante et la renvoie avec le code 200.

L'essentiel

• Le client (navigateur) envoie une requête ; le serveur renvoie une réponse avec un code (200 : OK, 404 : introuvable).

• Une URL se décompose en protocole, nom de domaine, chemin, puis paramètres nom=valeur séparés par & après le ?.

• Une requête commence par la méthode, la ressource et la version : GET /index.html HTTP/1.1.

• GET met les données dans l'URL ; POST les met dans le corps de la requête. Seul HTTPS chiffre l'échange.

• Le code côté client est visible dans l'inspecteur ; le code côté serveur ne l'est pas.

• Le serveur ne doit jamais faire confiance aux données reçues : il les revérifie.