031.3 Leçon 1
Certification : |
Web Development Essentials |
---|---|
Version : |
1.0 |
Thème : |
031 Développement de logiciels et technologies Web |
Objectif : |
031.3 Bases du HTTP |
Leçon : |
1 sur 1 |
Introduction
Le protocole de transfert hypertexte (HTTP : HyperText Transfer Protocol) définit la manière dont un client demande une ressource spécifique au serveur. Son principe de fonctionnement est assez simple : le client crée un message de requête identifiant la ressource dont il a besoin et transmet ce message au serveur via le réseau. À son tour, le serveur HTTP évalue où extraire la ressource demandée et renvoie un message de réponse au client. Le message de réponse contient des détails sur la ressource demandée, suivis de la ressource elle-même.
Plus précisément, HTTP est l’ensemble des règles qui définissent comment l’application client doit formater les messages de requête (request) qui seront envoyés au serveur. Le serveur suit ensuite les règles HTTP pour interpréter la requête et formater les messages de réponse (replay). Outre la requête ou le transfert du contenu demandé, les messages HTTP contiennent des informations supplémentaires sur le client et le serveur concernés, sur le contenu lui-même, voire sur son indisponibilité. Si une ressource ne peut être envoyée, un code dans la réponse explique la raison de cette indisponibilité et, si possible, indique où la ressource a été déplacée.
La partie du message qui définit les détails de la ressource et d’autres informations contextuelles est appelée l'en-tête du message. La partie qui suit l’en-tête, qui contient le contenu de la ressource correspondante, est appelée charge utile (payload) du message. Les messages de requête et les messages de réponse peuvent tous deux avoir une charge utile, mais dans la plupart des cas, seul le message de réponse en a une.
Requête du client
La première étape d’un échange de données HTTP entre le client et le serveur est initiée par le client, lorsqu’il écrit un message de requête au serveur. Prenons l’exemple d’une tâche courante du navigateur : charger une page HTML à partir d’un serveur hébergeant un site web, tel que https://learning.lpi.org/en/
. L’adresse web, ou URL, fournit plusieurs éléments d’information pertinents. Trois éléments d’information apparaissent dans cet exemple particulier :
-
Le protocole : HyperText Transfer Protocol Secure (
https
), une version chiffrée du protocole HTTP. -
Le nom de réseau de l’hôte web (
learning.lpi.org
) -
L’emplacement de la ressource demandée sur le serveur (le répertoire
/en/
dans ce cas, la page d’accueil en anglais).
Note
|
Un localisateur uniforme de ressource (URL : Uniform Resource Locator) est une adresse qui pointe vers une ressource sur l’internet. Cette ressource est généralement un fichier qui peut être copié à partir d’un serveur distant, mais les URL peuvent également indiquer un contenu généré dynamiquement et des flux de données. |
Comment le client traite une URL
Avant de contacter le serveur, le client doit convertir learning.lpi.org
en son adresse IP correspondante. Le client utilise un autre service internet, le système de noms de domaine (DNS : Domain Name System), pour demander l’adresse IP d’un nom d’hôte à un ou plusieurs serveurs DNS prédéfinis (les serveurs DNS sont généralement définis automatiquement par le fournisseur d’accès internet, FAI).
Avec l’adresse IP du serveur, le client essaie de se connecter au port HTTP ou HTTPS. Les ports réseau sont des numéros d’identification définis par le protocole de contrôle de transmissions (TCP : Transmission Control Protocol) pour entrelacer et identifier des canaux de communication distincts dans une connexion client/serveur. Par défaut, les serveurs HTTP reçoivent des requêtes sur les ports TCP 80 (HTTP) et 443 (HTTPS).
Note
|
Il existe d’autres protocoles utilisés par les applications web pour mettre en œuvre la communication client/serveur. Pour les appels audio et vidéo, par exemple, il est plus approprié d’utiliser les WebSockets, un protocole de niveau inférieur qui est plus efficace que le protocole HTTP pour transférer des flux de données dans les deux sens. |
Le format du message de requête que le client envoie au serveur est le même en HTTP et en HTTPS. HTTPS est déjà plus largement utilisé que HTTP, car tous les échanges de données entre le client et le serveur sont chiffrés, ce qui est une caractéristique indispensable pour promouvoir la confidentialité et la sécurité sur les réseaux publics. La connexion chiffrée est établie entre le client et le serveur avant même l’échange de tout message HTTP, à l’aide du protocole de chiffrement sécurité de la couche de transport (TLS : Transport Layer Security). Ce faisant, toutes les communications HTTPS sont encapsulées par TLS. Une fois déchiffré, la requête ou la réponse transmise par HTTPS n’est pas différente d’une requête ou d’une réponse effectuée exclusivement par HTTP.
Le troisième élément de notre URL, /en/
, sera interprété par le serveur comme l’emplacement ou le chemin de la ressource demandée. Si le chemin n’est pas fourni dans l’URL, l’emplacement par défaut /
sera utilisé. L’implémentation la plus simple d’un serveur HTTP associe les chemins d’accès dans les URL aux fichiers du système de fichiers sur lequel le serveur est exécuté, mais ce n’est qu’une des nombreuses options disponibles sur les serveurs HTTP plus sophistiqués.
Message de requête
HTTP fonctionne par le biais d’une connexion déjà établie entre le client et le serveur, généralement implémentée en TCP et chiffrée avec TLS. En fait, dès qu’une connexion répondant aux exigences imposées par le serveur est prête, une requête HTTP tapée à la main en texte clair pourrait générer la réponse du serveur. En pratique, cependant, les programmeurs ont rarement besoin d’implémenter des routines pour composer des messages HTTP, car la plupart des langages de programmation fournissent des mécanismes qui automatisent la fabrication du message HTTP. Dans le cas de l’URL de notre exemple, https://learning.lpi.org/en/
, le message de requête le plus simple possible aurait le contenu suivant :
GET /en/ HTTP/1.1 Host: learning.lpi.org User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:87.0) Gecko/20100101 Firefox/87.0 Accept: text/html
Le premier mot de la première ligne identifie la méthode HTTP. Il définit l’opération que le client veut effectuer sur le serveur. La méthode GET
informe le serveur que le client demande la ressource qui suit : /en/
. Le client et le serveur pouvant prendre en charge plusieurs versions du protocole HTTP, la version à adopter dans l’échange de données est également indiquée sur la première ligne : HTTP/1.1
.
Note
|
La version la plus récente du protocole HTTP est HTTP/2. Entre autres différences, les messages écrits en HTTP/2 sont codés dans une structure binaire, alors que les messages écrits en HTTP/1.1 sont envoyés en texte clair. Ce changement permet d’optimiser les taux de transmission des données, mais le contenu des messages reste fondamentalement le même. |
L’en-tête peut contenir d’autres lignes après la première pour contextualiser et aider à identifier la requête au serveur. Le champ d’en-tête Host
, par exemple, peut sembler redondant, car l’hôte du serveur a évidemment été identifié par le client afin d’établir la connexion et il est raisonnable de supposer que le serveur connaît sa propre identité. Néanmoins, il est important d’informer l’hôte du nom d’hôte attendu dans l’en-tête de la requête, car il est courant d’utiliser le même serveur HTTP pour héberger plus d’un site Web. (Dans ce scénario, chaque hôte spécifique est appelé hôte virtuel). Par conséquent, le champ Host
est utilisé par le serveur HTTP pour identifier celui auquel la requête fait référence.
Le champ d’en-tête User-Agent
contient des détails sur le programme client qui effectue la requête. Ce champ peut être utilisé par le serveur pour adapter la réponse aux besoins d’un client spécifique, mais il est plus souvent utilisé pour produire des statistiques sur les clients qui utilisent le serveur.
Le champ Accept
a une valeur plus immédiate, car il informe le serveur du format de la ressource demandée. Si le client est indifférent au format de la ressource, le champ Accept
peut spécifier */*
comme format d’entrée.
De nombreux autres champs d’en-tête peuvent être utilisés dans un message HTTP, mais les champs présentés dans l’exemple sont suffisants pour demander une ressource au serveur.
En plus des champs de l’en-tête de la requête, le client peut inclure d’autres données complémentaires dans la requête HTTP qui sera envoyée au serveur. Si ces données consistent uniquement en de simples paramètres textuels, au format nom=valeur
, ils peuvent être ajoutés au chemin de la méthode GET
. Les paramètres sont incorporés dans le chemin après un point d’interrogation et sont séparés par des caractères d’esperluette (&
) :
GET /cgi-bin/receive.cgi?name=LPI&email=info@lpi.org HTTP/1.1
Dans cet exemple, /cgi-bin/receive.cgi
est le chemin d’accès au script sur le serveur qui traitera et utilisera éventuellement les paramètres name
et email
, obtenus à partir du chemin de la requête. La chaîne qui correspond aux champs, au format name=LPI&email=info@lpi.org
, est appelée chaîne de requête et elle est fournie au script receive.cgi
par le serveur HTTP qui reçoit la requête.
Lorsque les données sont constituées de plus de champs de texte court, il est plus approprié de les envoyer dans la charge utile (playload) du message. Dans ce cas, la méthode HTTP POST
doit être utilisée pour que le serveur reçoive et traite les données utiles du message, conformément aux spécifications indiquées dans l’en-tête de la requête. Lorsque la méthode POST
est utilisée, l’en-tête de la requête doit indiquer la taille de la charge utile qui sera envoyée ensuite et le mode de formatage du corps du message :
POST /cgi-bin/receive.cgi HTTP/1.1 Host: learning.lpi.org Content-Length: 1503 Content-Type: multipart/form-data; boundary=------------------------405f7edfd646a37d
Le champ Content-Length
indique la taille en octets de la charge utile et le champ Content-Type
indique son format. Le format multipart/form-data
est le plus couramment utilisé dans les formulaires HTML traditionnels qui utilisent la méthode POST
. Dans ce format, chaque champ inséré dans les données utiles de la requête est séparé par le code indiqué par le mot-clé boundary
. La méthode POST
ne doit être utilisée que lorsque cela est approprié, car elle utilise une quantité de données légèrement supérieure à celle d’une requête équivalente effectuée avec la méthode GET
. Comme la méthode GET
envoie les paramètres directement dans l’en-tête de message de la requête, l’échange total de données a une latence plus faible, car une étape de connexion supplémentaire pour transmettre le corps du message ne sera pas nécessaire.
En-tête de la réponse
Après avoir reçu l’en-tête du message de requête, le serveur HTTP renvoie un message de réponse au client. Une requête de fichier HTML comporte généralement un en-tête de réponse comme celui-ci :
HTTP/1.1 200 OK Accept-Ranges: bytes Content-Length: 18170 Content-Type: text/html Date: Mon, 05 Apr 2021 13:44:25 GMT Etag: "606adcd4-46fa" Last-Modified: Mon, 05 Apr 2021 09:48:04 GMT Server: nginx/1.17.10
La première ligne indique la version du protocole HTTP utilisée dans le message de réponse, qui doit correspondre à la version utilisée dans l’en-tête de la requête. Ensuite, toujours sur la première ligne, apparaît le code d’état de la réponse, qui indique comment le serveur a interprété et a généré la réponse à la requête.
Le code d’état est un nombre à trois chiffres, le chiffre le plus à gauche définit la classe de réponse. Il existe cinq classes de codes d’état, numérotées de 1 à 5, chacune indiquant un type d’action prise par le serveur :
- 1xx (Information)
-
La requête a été reçue, ce qui a permis de poursuivre le processus.
- 2xx (Succès)
-
La requête a été reçue, comprise et acceptée avec succès.
- 3xx (Redirection)
-
D’autres mesures doivent être prises afin de compléter la requête.
- 4xx (Erreur du client)
-
La requête contient une mauvaise syntaxe ou ne peut pas être satisfaite.
- 5xx (Erreur du serveur)
-
Le serveur n’a pas réussi à satisfaire une requête apparemment valide.
Les deuxième et troisième chiffres sont utilisés pour indiquer des détails supplémentaires. Le code 200, par exemple, indique que la requête a pu être satisfaite sans problème. Comme le montre l’exemple, une brève description textuelle suivant le code de réponse (OK
) peut également être fournie. Certains codes spécifiques présentent un intérêt particulier pour garantir que le client HTTP peut accéder à la ressource dans des situations défavorables ou pour aider à identifier la raison de l’échec en cas de requête infructueuse :
301 Moved Permanently
-
La ressource cible s’est vue attribuer une nouvelle URL permanente, fournie par le champ d’en-tête
Location
de la réponse. 302 Found
-
La ressource cible réside temporairement sous une autre URL.
401 Unauthorized
-
La requête n’a pas été appliquée car il manque des informations d’authentification valides pour la ressource cible.
403 Forbidden
-
La réponse
Forbidden
indique que, bien que la requête soit valide, le serveur est configuré pour ne pas la fournir. 404 Not Found
-
Le serveur d’origine n’a pas trouvé de représentation actuelle pour la ressource cible ou n’est pas disposé à révéler qu’il en existe une.
500 Internal Server Error
-
Le serveur a rencontré une condition inattendue qui l’a empêché de répondre à la requête.
502 Bad Gateway
-
Le serveur, agissant comme une passerelle ou un proxy, a reçu une réponse invalide d’un serveur entrant auquel il a accédé en tentant de répondre à la requête.
Bien qu’ils indiquent qu’il n’a pas été possible de répondre à la requête, les codes d’état 4xx
et 5xx
indiquent au moins que le serveur HTTP fonctionne et il est capable de recevoir des requêtes. Les codes 4xx
nécessitent une action de la part du client, car son URL ou ses informations d’identification sont erronées. En revanche, les codes 5xx
indiquent que quelque chose ne va pas du côté du serveur. Par conséquent, dans le contexte des applications veb, ces deux classes de codes d’état indiquent que la source de l’erreur se trouve dans l’application elle-même, soit le client ou le serveur, et non dans l’infrastructure sous-jacente.
Contenu statique et dynamique
Les serveurs HTTP utilisent deux mécanismes de base pour répondre au contenu demandé par le client. Le premier mécanisme fournit un contenu statique : c’est-à-dire que le chemin indiqué dans le message de requête correspond à un fichier sur le système de fichiers local du serveur. Le second mécanisme fournit un contenu dynamique : le serveur HTTP transmet la requête à un autre programme, probablement un script, pour construire la réponse à partir de différentes sources, telles que des bases de données et d’autres fichiers.
Bien qu’il existe différents serveurs HTTP, ils utilisent tous le même protocole de communication HTTP et adoptent plus ou moins les mêmes conventions. Une application qui n’a pas de besoin spécifique peut être mise en œuvre avec n’importe quel serveur traditionnel, comme Apache ou NGINX. Tous deux sont capables de générer du contenu dynamique et de fournir du contenu statique, mais il existe des différences subtiles dans la configuration de chacun.
L’emplacement des fichiers statiques à servir, par exemple, est défini de différentes manières dans Apache et NGINX. La convention est de conserver ces fichiers dans un répertoire spécifique à cet effet, ayant un nom associé à l’hôte, par exemple /var/www/learning.lpi.org/
. Dans Apache, ce chemin est défini par la directive de configuration DocumentRoot /var/www/learning.lpi.org
, dans une section qui définit un hôte virtuel. Dans NGINX, la directive utilisée est root /var/www/learning.lpi.org
dans une section serveur
du fichier de configuration.
Quel que soit le serveur que vous choisissez, les fichiers de /var/www/learning.lpi.org/
seront servis via HTTP de manière presque identique. Certains champs de l’en-tête de réponse et leur contenu peuvent varier entre les deux serveurs, mais des champs comme Content-Type
doivent être présents dans l’en-tête de réponse et doivent être cohérents sur tous les serveurs.
Mise en cache
HTTP a été conçu pour fonctionner sur tout type de connexion Internet, rapide ou lente. En outre, la plupart des échanges HTTP doivent traverser de nombreux nœuds de réseau en raison de l’architecture distribuée d’internet. Par conséquent, il est important d’adopter une stratégie de mise en cache du contenu afin d’éviter le transfert redondant de contenu précédemment téléchargé. Les transferts HTTP peuvent fonctionner avec deux types de cache de base : partagé et privé.
Un cache partagé est utilisé par plus d’un seul client. Par exemple, un grand fournisseur de contenu peut utiliser des caches sur des serveurs géographiquement répartis, de sorte que les clients obtiennent les données du serveur le plus proche. Une fois qu’un client a fait une requête et que sa réponse a été stockée dans un cache partagé, les autres clients qui font la même requête dans la même zone recevront la réponse en cache.
Un cache privé est créé par le client lui-même pour son usage exclusif. Il s’agit du type de cache que le navigateur web utilise pour les images, les fichiers CSS, le JavaScript ou le document HTML lui-même, afin qu’ils ne soient pas téléchargés à nouveau s’ils sont demandés dans un avenir proche.
Note
|
Toutes les requêtes HTTP ne doivent pas être mises en cache. Une requête utilisant la méthode |
Les stratégies de cache partagé et privé utilisent toutes les deux des en-têtes HTTP pour contrôler la manière dont le contenu téléchargé doit être mis en cache. Pour le cache privé, le client consulte l’en-tête de réponse et vérifie si le contenu du cache local correspond toujours au contenu distant actuel. Si c’est le cas, le client renonce au transfert des données utiles de la réponse et utilise la version locale.
La validité de la ressource mise en cache peut être évaluée de plusieurs façons. Le serveur peut fournir une date d’expiration dans l’en-tête de réponse de la première requête, de sorte que le client se débarrasse de la ressource mise en cache à la fin de la période et la demande à nouveau pour obtenir la version mise à jour. Cependant, le serveur n’est pas toujours en mesure de déterminer la date d’expiration d’une ressource, il est donc courant d’utiliser le champ d’en-tête de réponse ETag
pour identifier la version de la ressource, par exemple Etag : "606adcd4-46fa"
.
Pour vérifier qu’une ressource mise en cache doit être mise à jour, le client demande uniquement son en-tête de réponse au serveur. Si le champ ETag
correspond à celui de la version stockée localement, le client réutilise le contenu mis en cache. Sinon, le contenu mis à jour de la ressource est téléchargé depuis le serveur.
Sessions HTTP
Dans un site web ou une application web classique, les fonctions qui gèrent le contrôle des sessions sont basées sur les en-têtes HTTP. Le serveur ne peut pas supposer, par exemple, que toutes les requêtes provenant de la même adresse IP proviennent du même client. La méthode la plus traditionnelle qui permet au serveur d’associer différentes requêtes à un même client est l’utilisation de cookies, une étiquette d’identification qui est donnée au client par le serveur et qui est fournie dans l’en-tête HTTP.
Les cookies permettent au serveur de conserver des informations sur un client spécifique, même si la personne qui exécute le client ne s’identifie pas explicitement. Grâce aux cookies, il est possible de mettre en place des sessions où les identifiants, les paniers d’achat, les préférences, etc., sont conservés entre différentes requêtes adressées au même serveur qui les a fournis. Les cookies sont également utilisés pour suivre la navigation des utilisateurs, il est donc important de demander leur consentement avant de les envoyer.
Le serveur définit le cookie dans l’en-tête de réponse à l’aide du champ Set-Cookie
. La valeur du champ est une paire nom=valeur
choisie pour représenter un attribut associé à un client spécifique. Le serveur peut, par exemple, créer un numéro d’identification pour un client qui demande une ressource pour la première fois et le transmettre au client dans l’en-tête de réponse :
HTTP/1.1 200 OK Accept-Ranges: bytes Set-Cookie: client_id=62b5b719-fcbf
Si le client autorise l’utilisation des cookies, les nouvelles requêtes adressées à ce même serveur comportent le champ cookie dans l’en-tête :
GET /en/ HTTP/1.1 Host: learning.lpi.org Cookie: client_id=62b5b719-fcbf
Grâce à ce numéro d’identification, le serveur peut récupérer des définitions spécifiques pour le client et générer une réponse personnalisée. Il est également possible d’utiliser plusieurs champs Set-Cookie
pour délivrer différents cookies au même client. De cette façon, plusieurs définitions peuvent être conservée du côté du client.
Les cookies soulèvent à la fois des problèmes de confidentialité et des failles de sécurité potentielles, car il est possible qu’ils soient transférés à un autre client, qui sera identifié par le serveur comme le client d’origine. Les cookies utilisés pour préserver les sessions peuvent donner accès à des informations sensibles du client d’origine. Il est donc très important que les clients adoptent des mécanismes de protection locaux pour empêcher que leurs cookies soient extraits et réutilisés sans autorisation.
Exercices guidés
-
Quelle méthode HTTP le message de requête suivant utilise-t-il ?
POST /cgi-bin/receive.cgi HTTP/1.1 Host: learning.lpi.org User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:87.0) Gecko/20100101 Firefox/87.0 Accept: */* Content-Length: 27 Content-Type: application/x-www-form-urlencoded
-
Lorsqu’un serveur HTTP héberge de nombreux sites Web, comment peut-il identifier celui auquel s’adresse une requête ?
-
Quel paramètre est fourni par la chaîne de requête de l’URL
https://www.google.com/search?q=LPI
? -
Pourquoi la requête HTTP suivante ne convient-elle pas à la mise en cache ?
POST /cgi-bin/receive.cgi HTTP/1.1 Host: learning.lpi.org User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:87.0) Gecko/20100101 Firefox/87.0 Accept: */* Content-Length: 27 Content-Type: application/x-www-form-urlencoded
Exercices d’exploration
-
Comment pouvez-vous utiliser le navigateur web pour surveiller les requêtes et les réponses faites par une page HTML ?
-
Les serveurs HTTP qui fournissent du contenu statique font généralement correspondre le chemin d’accès demandé à un fichier dans le système de fichiers du serveur. Que se passe-t-il lorsque le chemin d’accès de la requête pointe vers un répertoire ?
-
Le contenu des fichiers envoyés par HTTPS est protégé par chiffrement, de sorte qu’il ne peut pas être lu par les ordinateurs situés entre le client et le serveur. Malgré cela, ces ordinateurs intermédiaires peuvent-ils identifier la ressource que le client a demandée au serveur ?
Résumé
Cette leçon couvre les bases du protocole HTTP, le principal protocole utilisé par les applications clientes pour demander des ressources aux serveurs web. La leçon aborde les concepts suivants :
-
Messages de requêtes, champs d’en-tête et méthodes.
-
Codes d’état de la réponse.
-
Comment les serveurs HTTP génèrent des réponses.
-
Fonctions HTTP utiles pour la mise en cache et la gestion des sessions.
Réponses aux exercices guidés
-
Quelle méthode HTTP le message de requête suivant utilise-t-il ?
POST /cgi-bin/receive.cgi HTTP/1.1 Host: learning.lpi.org User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:87.0) Gecko/20100101 Firefox/87.0 Accept: */* Content-Length: 27 Content-Type: application/x-www-form-urlencoded
La méthode
POST
. -
Lorsqu’un serveur HTTP héberge de nombreux sites Web, comment peut-il identifier celui auquel s’adresse une requête ?
Le champ
Host
de l’en-tête de la requête fournit le site web ciblé. -
Quel paramètre est fourni par la chaîne de requête de l’URL
https://www.google.com/search?q=LPI
?Le paramètre nommé
q
avec la valeurLPI
. -
Pourquoi la requête HTTP suivante ne convient-elle pas à la mise en cache ?
POST /cgi-bin/receive.cgi HTTP/1.1 Host: learning.lpi.org User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:87.0) Gecko/20100101 Firefox/87.0 Accept: */* Content-Length: 27 Content-Type: application/x-www-form-urlencoded
Comme les requêtes effectuées avec la méthode
POST
impliquent une opération d’écriture sur le serveur, elles ne doivent pas être mises en cache.
Réponses aux exercices d’exploration
-
Comment pouvez-vous utiliser le navigateur web pour surveiller les requêtes et les réponses faites par une page HTML ?
Tous les navigateurs populaires offrent des outils de développement qui, entre autres, peuvent montrer toutes les transactions réseau qui ont été effectuées par la page actuelle.
-
Les serveurs HTTP qui fournissent du contenu statique font généralement correspondre le chemin d’accès demandé à un fichier dans le système de fichiers du serveur. Que se passe-t-il lorsque le chemin d’accès de la requête pointe vers un répertoire ?
Cela dépend de la façon dont le serveur est configuré. Par défaut, la plupart des serveurs HTTP recherchent un fichier nommé
index.html
(ou un autre nom prédéfini) dans ce même répertoire et l’envoient comme réponse. Si le fichier n’est pas là, le serveur envoie une réponse404 Not Found
. -
Le contenu des fichiers envoyés par HTTPS est protégé par chiffrement, de sorte qu’il ne peut pas être lu par les ordinateurs situés entre le client et le serveur. Malgré cela, ces ordinateurs intermédiaires peuvent-ils identifier la ressource que le client a demandée au serveur ?
Non, car les en-têtes HTTP de la requête et de la réponse sont eux aussi chiffrés par TLS.