Navigateur, serveur et échanges HTTP

Le navigateur joue le rôle de client

Lorsqu’on demande une page, le navigateur envoie une requête à un serveur identifié par l’adresse. Le serveur traite cette demande et renvoie une réponse. Le navigateur interprète les ressources reçues pour afficher le document ; il peut ensuite demander d’autres fichiers, comme une image ou une feuille de style. Client et serveur désignent des rôles dans l’échange, pas nécessairement deux catégories de machines immuables. Un ordinateur peut héberger un serveur dans un autre contexte. Pour une trace simple, on suit chaque demande puis la réponse correspondante.

Une page visible peut résulter de plusieurs échanges : le document principal référence souvent des images, des styles et des scripts. Le nombre de pages ouvertes ne correspond donc pas nécessairement au nombre de requêtes. Une trace simplifiée doit préciser les ressources qu’elle prend en compte.

HTTP structure les messages

Une requête HTTP comporte notamment une méthode, une cible et des en-têtes ; elle peut aussi contenir un corps. Une réponse comporte un statut, des en-têtes et éventuellement un contenu. Un statut 200 indique une réussite habituelle ; 404 signale que la ressource demandée n’a pas été trouvée. Le code de statut ne décrit pas à lui seul la qualité de l’information reçue. La réponse peut contenir du HTML, des données structurées ou un autre type de ressource. Le navigateur utilise ces éléments pour décider comment poursuivre le chargement ou présenter le résultat.

Une réponse 404 est bien une réponse reçue du serveur. Elle diffère d’une absence de réponse causée par un problème de liaison. Le navigateur peut afficher une page explicative fournie avec ce statut ; voir du contenu à l’écran ne signifie donc pas que la ressource demandée existe.

Localiser calculs et données mémorisées

Changer la couleur d’un bouton ou vérifier provisoirement un champ peut se faire dans le navigateur avec les ressources déjà reçues. Lire une base située sur le serveur ou contrôler un accès privé demande un traitement côté serveur. Le client peut mémoriser certaines données, par exemple dans des cookies ou un stockage local. Les cookies correspondant à une requête peuvent être retransmis automatiquement selon leurs règles ; le stockage local n’est pas automatiquement envoyé comme un cookie. Une application peut toutefois décider de transmettre une valeur qu’elle y a lue.

Un cookie n’est transmis que s’il est applicable à la requête selon ses paramètres et les règles du navigateur. L’atelier suppose explicitement cette applicabilité. Il n’affirme pas que tous les cookies partent vers tous les sites ou qu’une action purement locale provoque un envoi.

HTTPS protège le transport, pas toutes les propriétés du site

HTTPS ajoute une protection cryptographique aux échanges HTTP. Il protège notamment la confidentialité et l’intégrité pendant le transport et permet l’authentification du serveur dans le cadre du mécanisme de certificats. Cela n’empêche pas le serveur destinataire de lire les données, ni le navigateur de les conserver. Une adresse en HTTPS n’affirme pas que les conseils du site sont vrais ou que son propriétaire est honnête. Il faut donc distinguer la sécurité du canal, les décisions de stockage et la fiabilité du contenu. Les mécanismes cryptographiques seront approfondis en Terminale.

Le chiffrement ne remplace pas le choix de la bonne destination. Le serveur auquel on s’adresse reçoit les données nécessaires à son traitement. Il faut donc distinguer qui peut lire pendant le transport, qui reçoit la demande et qui décide ensuite de sa conservation.

Suivre un chargement avec plusieurs ressources

Un navigateur demande le document /cours. La réponse contient du HTML qui référence une feuille de style et deux images. Dans un modèle où rien n’est déjà en cache et chaque fichier est distinct, le chargement exige quatre requêtes : une pour le document et trois pour les ressources supplémentaires. Le serveur traite chaque demande correspondante.

Si une image renvoie 404, le document principal peut quand même être affiché. Le défaut concerne alors cette ressource particulière. Lire séparément les cibles et les statuts permet de localiser le problème sans conclure que toute la connexion ou tout le site est indisponible.

Distinguer une préférence locale d’une donnée transmise

Une préférence de couleur peut être enregistrée dans le stockage local puis relue par un script déjà présent. Changer la couleur ne demande aucun échange supplémentaire dans ce scénario. Un cookie applicable, lui, peut accompagner automatiquement une nouvelle demande de page. Le stockage et la transmission sont donc deux étapes distinctes.

Pour savoir si une préférence quitte le navigateur, il faut examiner le programme et les requêtes : un script peut décider de la placer dans un paramètre ou un corps de message. Le seul nom du mécanisme de stockage ne prouve ni qu’une donnée est envoyée, ni qu’elle restera toujours locale.

De la compréhension à l’autonomie

À vous de résoudre

Cherchez d’abord par vous-même. Vérifiez les résultats demandés, utilisez les indices si nécessaire, puis comparez votre méthode à la correction.

Les erreurs qui méritent un détour

Attribuer tout changement visuel à un serveur

Un programme exécuté dans le navigateur peut modifier la page sans nouvel échange.

Déduire la confidentialité totale du seul HTTPS

Le navigateur et le serveur restent les extrémités qui utilisent les données ; leur stockage doit être examiné séparément.

Le prochain pas

• Formulaires Web : comprendre GET et POST

Retrouver le catalogue de Première

Ce chapitre s’appuie sur le programme officiel de Première (PDF, nouvel onglet). Les explications et exercices sont proposés pour l’apprentissage.