Client-serveur et HTTP

Le client demande un service ; le serveur traite la demande et renvoie une réponse. Dans le cas d’une page Web, le navigateur joue généralement le rôle de client. Le serveur peut fournir un fichier déjà disponible ou fabriquer une réponse à partir de paramètres et de calculs. Ces rôles décrivent une relation, pas une catégorie absolue de machines : un serveur peut lui-même devenir client d’un autre service. Pour analyser une action, on suit donc l’échange précis plutôt que le seul nom des ordinateurs.

HTTP fixe des règles d’échange entre un client et un serveur. Une requête comporte notamment une méthode, une cible et des en-têtes ; elle peut aussi contenir un corps. La réponse indique un code de statut, des en-têtes et éventuellement un corps. Ce corps peut être du HTML, du texte ou des données dans un autre format. Le navigateur interprète ensuite le contenu reçu. Une réponse à une requête ne signifie pas que tout le site fonctionne : il faut aussi vérifier le contenu attendu.

Lors du chargement d’une page, d’autres requêtes peuvent être nécessaires pour les feuilles de style, scripts ou images. Une action locale sur le DOM peut au contraire ne créer aucune requête. Les outils réseau du navigateur permettent d’observer ce qui est effectivement envoyé et reçu. Pour expliquer le comportement, distingue les événements de l’interface, les messages du réseau et les calculs. Ces trois aspects sont liés mais ne sont pas interchangeables.

Une URL peut contenir un schéma, un nom d’hôte, un chemin et une partie de requête. Dans https://exemple.test/chercher?q=climat, https annonce le mode d’accès, exemple.test désigne l’hôte, /chercher le chemin et q=climat un paramètre. Le point d’interrogation introduit la partie de requête ; le signe & peut séparer plusieurs paramètres. Le caractère # introduit un fragment, généralement utilisé par le navigateur pour viser une partie du document ; ce fragment n’est pas transmis dans la requête HTTP ordinaire.

Les noms et valeurs doivent être encodés selon les règles des URL et des formulaires. Une espace ou un caractère réservé ne s’ajoute pas au hasard dans la cible. Pour une explication simple, on peut suivre des valeurs sans caractères particuliers, puis identifier l’opération d’encodage lorsque les données en comportent. Une URL est une représentation textuelle : voir le paramètre n’indique pas encore si le serveur l’a accepté ni comment il l’a interprété.

Un formulaire HTML regroupe des contrôles de saisie. L’attribut action du formulaire indique la cible ; method indique la méthode choisie. Un champ doit notamment posséder un nom, indiqué par name, pour que sa valeur soit transmise comme paramètre par le mécanisme ordinaire du formulaire. Un id peut servir à associer le champ à un libellé, mais il ne remplace pas name. Le texte visible près d’un champ ne détermine pas non plus automatiquement le nom envoyé.

Avec GET, les données d’un formulaire de recherche sont généralement encodées dans la partie de requête de l’URL. Cette méthode convient à une demande de représentation d’une ressource, telle qu’une recherche consultable et partageable. Elle ne doit pas servir à demander une modification comme la création d’une réservation. Une URL contenant une recherche peut apparaître dans l’historique, être copiée ou être enregistrée dans des journaux ; on évite d’y placer des données confidentielles.

Avec POST, les données du formulaire sont placées dans le corps de la requête, selon un format indiqué par les en-têtes. Cette méthode sert notamment à soumettre des données en vue d’un traitement. Le corps ne se voit pas directement dans la barre d’adresse, mais il reste transmis et accessible aux parties concernées. POST ne chiffre rien à lui seul. La décision GET ou POST exprime donc le sens de l’opération et la manière de transmettre les paramètres ; la confidentialité du transport relève de HTTPS.

Le navigateur peut conserver des informations dans la mémoire de la page, dans des cookies ou dans d’autres stockages locaux. Une variable JavaScript ordinaire disparaît avec le contexte de la page ; un stockage persistant peut durer au-delà. Ces mécanismes n’ont pas tous les mêmes règles de retransmission. Par exemple, certains cookies sont joints automatiquement aux requêtes auxquelles ils s’appliquent. Une valeur dans un stockage local n’est pas, à elle seule, automatiquement envoyée à chaque requête : un programme peut devoir la lire et la transmettre.

HTTP ne suppose pas que le serveur se souvienne spontanément de chaque client entre deux requêtes. Une application peut établir une continuité à l’aide de mécanismes de session. Un identifiant de session peut relier une demande à un état conservé côté serveur. L’information envoyée par le client reste une donnée reçue de l’extérieur : le serveur doit vérifier sa forme, sa validité et les droits associés. Un champ désactivé dans l’interface ou une vérification JavaScript ne suffisent pas à imposer une règle au serveur.

HTTPS ajoute une protection cryptographique du transport, avec TLS : les échanges sont chiffrés entre les extrémités concernées et le client peut vérifier l’identité du serveur au moyen du certificat. Cela protège contre la lecture ou la modification du trafic en transit dans les conditions prévues par le protocole. Cela ne prouve pas qu’un site est honnête ni que les données seront correctement traitées après réception. Le navigateur et le serveur ont accès aux données qu’ils envoient ou reçoivent.

La rubrique S’entraîner est accessible à l’adresse /exercices. Exerce-toi à dessiner l’ordre d’un échange, puis à justifier un choix de méthode pour une recherche et pour une création.