HTTP est le protocole qui nous permet d’acheter des fours à micro-ondes sur Amazon.com, de retrouver un vieil ami dans un chat sur Facebook et de regarder des vidéos de chats amusantes sur YouTube. HTTP est le protocole derrière le World Wide Web. Il permet à un serveur Web d'un centre de données situé aux États-Unis d'envoyer des informations à un café Internet en Australie, où un jeune étudiant peut lire une page Web décrivant la dynastie Ming en Chine..
Dans ce livre, nous examinerons HTTP du point de vue d'un développeur de logiciel. Avoir une solide compréhension de HTTP peut vous aider à rédiger de meilleures applications Web et services Web. Il peut également vous aider à déboguer des applications et des services en cas de problème. Nous couvrirons toutes les bases, y compris les ressources, les messages, les connexions et la sécurité en ce qui concerne HTTP.
Nous allons commencer par examiner les ressources.
L'adresse HTTP est peut-être la partie la plus familière du Web. Lorsque je veux trouver une recette pour un plat au brocoli, ce qui n’est presque jamais, je peux ouvrir mon navigateur et entrer http://food.com
dans la barre d'adresse, accédez au site Web food.com et recherchez des recettes. Mon navigateur Web comprend cette syntaxe et sait qu'il doit envoyer une requête HTTP à un serveur nommé food.com. Nous parlerons plus tard de ce que signifie "faire une requête HTTP" et de tous les détails de mise en réseau impliqués. Pour l'instant, nous voulons juste nous concentrer sur l'adresse: http://food.com
.
L'adresse http://food.com
est ce que nous appelons une URL, un localisateur de ressources uniforme. Il représente une ressource spécifique sur le web. Dans ce cas, la ressource est la page d'accueil du site Web food.com. Les ressources sont des éléments avec lesquels je souhaite interagir sur le Web. Les images, les pages, les fichiers et les vidéos sont toutes des ressources.
Il y a des milliards, voire des milliards, d'endroits où aller sur Internet. En d'autres termes, il y a des milliards de ressources. Chaque ressource aura une URL que je peux utiliser pour la trouver. http://news.google.com
est un endroit différent de http://news.yahoo.com
. Ce sont deux noms différents, deux sociétés différentes, deux sites Web différents et par conséquent deux URL différentes. Bien sûr, il y aura également différentes URL sur le même site Web.. http://food.com/recipe/broccoli-salad-10733/
est l'URL d'une page avec une recette de salade de brocoli, alors que http://food.com/recipe/grilled-cauliflower-19710/
est toujours à food.com, mais est une ressource différente décrivant une recette de chou-fleur.
Nous pouvons diviser la dernière URL en trois parties:
http
, la partie avant la : //
, est ce que nous appelons le Schéma d'URL. Le schéma décrit Comment accéder à une ressource particulière, et dans ce cas, il indique au navigateur d’utiliser le protocole de transfert hypertexte. Plus tard, nous examinerons également un schéma différent, HTTPS, qui est le protocole HTTP sécurisé. Vous pouvez également utiliser d'autres méthodes, telles que FTP pour le protocole de transfert de fichiers et mailto pour les adresses électroniques.. Tout après le : //
sera spécifique à un régime particulier. Ainsi, une URL HTTP légale peut ne pas être une adresse mailto légale. Ces deux noms ne sont pas vraiment interchangeables (ce qui est logique car ils décrivent différents types de ressources)..
food.com
est le hôte. Ce nom d'hôte indique au navigateur le nom de l'ordinateur hébergeant la ressource. L’ordinateur utilisera le système de noms de domaine (DNS) pour traduire food.com
dans une adresse réseau, et il saura alors exactement où envoyer la demande pour la ressource. Vous pouvez également spécifier la partie hôte d'une URL à l'aide d'une adresse IP../ recette / chou-fleur grillé-19710 /
est le Chemin de l'URL. L’hôte de food.com doit reconnaître la ressource spécifique demandée par cette voie et répondre de manière appropriée..Parfois, une URL pointe vers un fichier du système de fichiers ou du disque dur de l'hôte. Par exemple, l'URL http://food.com/logo.jpg
peut pointer vers une image qui existe vraiment sur le serveur food.com. Cependant, les ressources peuvent aussi être dynamiques. L'URL http://food.com/recipes/brocolli
ne fait probablement pas référence à un fichier réel sur le serveur food.com. Au lieu de cela, une sorte d’application est en cours d’exécution sur l’hôte food.com qui prendra cette demande et créera une ressource en utilisant le contenu d’une base de données. L'application peut être créée à l'aide d'ASP.NET, PHP, Perl, Ruby on Rails ou d'une autre technologie Web qui sait comment répondre aux demandes entrantes en créant du code HTML à afficher par un navigateur..
En fait, ces jours-ci, de nombreux sites Web essaient éviter avoir une sorte de nom de fichier réel dans leur URL. Pour commencer, les noms de fichier sont généralement associés à une technologie spécifique, telle que .aspx pour la technologie ASP.NET de Microsoft. De nombreuses URL survivront à la technologie utilisée pour les héberger et les servir. Deuxièmement, beaucoup de sites veulent placer des mots-clés dans une URL (comme avoir / recette / brocoli /
dans l'URL d'une recette de brocoli). Avoir ces mots-clés dans l'URL est une forme d'optimisation du moteur de recherche (SEO) qui classera la ressource plus haut dans les résultats des moteurs de recherche. Les mots-clés descriptifs, et non les noms de fichier, sont importants pour les URL de nos jours.
Certaines ressources amèneront également le navigateur à télécharger des ressources supplémentaires. La page d'accueil de food.com comprendra des images, des fichiers JavaScript, des CSS et d'autres ressources qui, toutes combinées, présenteront la "page d'accueil" de food.com..
food.com page d'accueilMaintenant que nous connaissons les schémas d'URL, les hôtes et les chemins, examinons également une URL avec un numéro de port:
http://food.com:80/recipes/broccoli/
Le nombre 80 représente le numéro de port l'hôte utilise pour écouter les demandes HTTP. Le numéro de port par défaut pour HTTP est le port 80; vous voyez donc généralement ce numéro de port omis d'une URL. Vous devez uniquement spécifier un numéro de port si le serveur écoute sur un port autre que le port 80, ce qui se produit généralement uniquement dans les environnements de test, de débogage ou de développement. Regardons une autre URL.
http://www.bing.com/search?q=broccoli
Tout après ?
(le point d'interrogation) est connu comme le question. La requête, également appelée la chaîne de requête, contient des informations que le site Web de destination peut utiliser ou interpréter. Il n'y a pas de norme formelle pour l'apparence de la chaîne de requête car techniquement, c'est à l'application d'interpréter les valeurs trouvées, mais vous verrez la majorité des chaînes de requête utilisées pour transmettre des paires nom-valeur sous la forme. nom1 = valeur1 & nom2 = valeur2
.
Par exemple:
http://foo.com?first=Scott&last=Allen
Il y a deux paires nom-valeur dans cet exemple. La première paire porte le nom "premier" et la valeur "Scott". La seconde paire porte le nom "last" avec la valeur "Allen". Dans notre URL précédente (http://www.bing.com/search?q=broccoli
), le moteur de recherche Bing verra le nom "q" associé à la valeur "brocoli". Il s'avère que le moteur Bing recherche une valeur "q" à utiliser comme terme de recherche. Nous pouvons considérer l'URL comme l'URL de la ressource qui représente les résultats de la recherche Bing pour le brocoli..
Enfin, une autre URL:
http://server.com?recipe=broccoli#ingredients
La partie après le signe # est connue sous le nom de fragment. Le fragment est différent des autres éléments que nous avons examinés jusqu'à présent, car contrairement au chemin d'URL et à la chaîne de requête, le fragment n'est pas traité par le serveur. Le fragment est utilisé uniquement sur le client et identifie une section particulière d'une ressource. Plus précisément, le fragment est généralement utilisé pour identifier un élément HTML spécifique dans une page à l'aide de l'ID de l'élément..
Les navigateurs Web alignent généralement l'affichage initial d'une page Web de sorte que le haut de l'élément identifié par le fragment se trouve en haut de l'écran. A titre d'exemple, l'URL http://odetocode.com/Blogs/scott/archive/2011/11/29/programming-windows-8-the-sublime-to-the-strange.aspx#feedback
a la valeur de fragment "feedback". Si vous suivez l'URL, votre navigateur Web doit faire défiler la page pour afficher la section de commentaires d'un article de blog particulier sur mon blog. Votre navigateur a récupéré l'intégralité de la ressource (l'article du blog), mais a concentré votre attention sur un domaine spécifique, la section des commentaires. Vous pouvez imaginer le code HTML de l'article de blog ressemblant à ce qui suit (avec tout le contenu du texte omis):
……
Le client s'assure que l'élément avec l'ID "feedback" est en haut.
Si nous rassemblons tout ce que nous avons appris jusqu'à présent, nous savons qu'une adresse URL est divisée en plusieurs éléments:
: // : / ? #
Tous les développeurs de logiciels qui travaillent avec le Web doivent être conscients des problèmes d’encodage des caractères liés aux URL. Les documents officiels décrivant les URL déploient beaucoup d'efforts pour rendre les URL aussi utilisables et interopérables que possible. Une adresse URL doit être aussi simple à communiquer par courrier électronique qu’à imprimer sur un autocollant de pare-chocs et à apposer sur une Ford Windstar 2001. Pour cette raison, les normes Internet définissent caractères dangereux pour les URL. Par exemple, le caractère espace est considéré comme dangereux car des espaces peuvent apparaître ou disparaître par erreur lorsqu'une URL est imprimée (s'agit-il d'un espace ou de deux espaces sur votre carte de visite?).
Les autres caractères non sécurisés incluent le signe dièse (#), car il sert à délimiter un fragment, et le curseur (^), car il n'est pas toujours correctement transmis via tous les périphériques du réseau. En fait, la RFC 3986 (la "loi" pour les URL) définit les caractères sécurisés pour que les URL soient les caractères alphanumériques en US-ASCII, plus quelques caractères spéciaux comme les deux points (:) et la barre oblique (/)..
Heureusement, vous pouvez toujours transmettre des caractères non sécurisés dans une URL, mais tous les caractères non sécurisés doivent être codés en pourcentage (ou URL codé).. % 20
est l'encodage d'un caractère d'espacement (où 20 est la valeur hexadécimale du caractère d'espacement US-ASCII).
Par exemple, supposons que vous vouliez créer l'URL d'un fichier nommé "^ my resume.txt" sur someserver.com. L'URL codée légale ressemblerait à ceci:
http://someserver.com/%5Emy%20resume.txt
Les caractères ^ et espace ont été codés en pourcentage. La plupart des frameworks d'applications Web fournissent une API facilitant le codage d'URL. Côté serveur, vous devez exécuter vos URL créées de manière dynamique via une API de codage, au cas où l'un des caractères non sécurisés apparaît dans l'URL..
Jusqu'à présent, nous nous sommes concentrés sur les URL et simplifié tout le reste. Mais qu'est-ce que cela signifie quand nous entrons une URL dans le navigateur? Cela signifie généralement que nous voulons récupérer ou afficher certaines ressources. Il y a énormément de matériel à visualiser sur le Web, et nous verrons plus tard comment HTTP nous permet également de créer, supprimer et mettre à jour des ressources. Pour l'instant, nous allons rester concentrés sur la récupération.
Nous n'avons pas été très précis sur les types de ressources que nous voulons récupérer. Il existe des milliers de types de ressources sur les images Web, les documents hypertexte, les documents XML, la vidéo, l'audio, les applications exécutables, les documents Microsoft Word et d'innombrables autres..
Pour qu'un hôte serve correctement une ressource et pour qu'un client affiche correctement une ressource, les parties impliquées doivent être spécifiques et précises quant au type de la ressource. La ressource est-elle une image? La ressource est-elle un film? Nous ne voudrions pas que nos navigateurs Web tentent de restituer une image PNG en tant que texte, ni d'essayer d'interpréter l'hypertexte en tant qu'image..
Lorsqu'un hôte répond à une requête HTTP, il retourne une ressource et spécifie également la type de contenu (également appelé type de support) de la ressource. Nous verrons les détails de l'affichage du type de contenu dans un message HTTP au chapitre suivant..
Pour spécifier les types de contenu, HTTP s'appuie sur les normes MIME (Multipurpose Internet Mail Extensions). Bien que MIME ait été conçu à l'origine pour les communications par courrier électronique, HTTP utilise les normes MIME dans le même but, qui consiste à étiqueter le contenu de manière à ce que le client sache ce que le contenu contient..
Par exemple, lorsqu'un client demande une page Web HTML, l'hôte peut répondre à la requête HTTP avec un code HTML étiqueté "texte / html
". Le "texte
"partie est le type de média principal, et le"html
"est le sous-type de média. Lorsqu'il répond à la demande d'une image, l'hôte attribue à la ressource un libellé de type"image / jpeg
"pour les fichiers JPG"image / gif
"pour les fichiers GIF, ou"image / png
"pour les fichiers PNG. Ces types de contenu sont des types MIME standard et sont littéralement ce qui apparaîtra dans la réponse HTTP.
Vous pourriez penser qu'un navigateur s'appuierait sur l'extension de fichier pour déterminer le type de contenu d'une ressource entrante. Par exemple, si mon navigateur demande "frog.jpg", il doit traiter la ressource comme un fichier JPG, mais "frog.gif" comme un fichier GIF. Cependant, pour la plupart des navigateurs, l’extension de fichier est le dernier endroit où elle déterminera le type de contenu réel..
Les extensions de fichier peuvent être trompeuses et le simple fait de demander un fichier JPG ne signifie pas que le serveur doit répondre avec des données codées au format JPG. Microsoft documente Internet Explorer (IE) comme tout d’abord en regardant la balise de type de contenu spécifiée par l’hôte. Si l'hôte ne fournit pas de type de contenu, IE analysera alors les 200 premiers octets de la réponse en essayant de deviner le type de contenu. Enfin, si Internet Explorer ne trouve pas de type de contenu et ne peut pas deviner le type de contenu, il aura recours à l'extension de fichier utilisée dans la demande de la ressource. C’est une des raisons pour lesquelles l’étiquette de type de contenu est importante, mais c’est loin d’être la seule raison.
Bien que nous ayons tendance à penser que HTTP est utilisé pour servir des pages Web, il s'avère que la spécification HTTP décrit un protocole générique flexible permettant de déplacer des informations haute fidélité. Une partie du travail de déplacement de l'information consiste à s'assurer que toutes les parties impliquées savent interpréter l'information, raison pour laquelle les paramètres de type de support sont importants..
Cependant, les types de média ne sont pas réservés aux hôtes. Les clients peuvent jouer un rôle dans le type de média renvoyé par un hôte en prenant part à une négociation de type de contenu..
Une ressource identifiée par une seule URL peut avoir plusieurs représentations. Prenons, par exemple, la recette de brocoli mentionnée précédemment. La recette unique peut avoir des représentations dans différentes langues (anglais, français et allemand). La recette peut même avoir des représentations dans différents formats (HTML, PDF et texte brut). C'est la même ressource et la même recette, mais des représentations différentes.
La question évidente est: quelle représentation le serveur doit-il choisir? La réponse se trouve dans le mécanisme de négociation de contenu décrit par la spécification HTTP. Lorsqu'un client envoie une requête HTTP à une URL, il peut spécifier les types de média qu'il acceptera. Les types de média ne sont pas seulement destinés à l'hôte à baliser les ressources sortantes, mais également aux clients à spécifier le type de média qu'ils souhaitent utiliser..
Le client spécifie ce qu'il acceptera dans le message de requête sortant. Encore une fois, nous verrons les détails de ce message lors de la prochaine session, mais imaginons une demande à http://food.com/
en disant qu'il acceptera une représentation en langue allemande. C'est au serveur d'essayer de répondre à la demande. L’hôte peut envoyer une ressource textuelle encore en anglais, ce qui risque de décevoir un utilisateur germanophone. C’est pourquoi nous l’appelons négociation de contenu et non ultimatum de contenu..
Les navigateurs Web sont des logiciels sophistiqués pouvant traiter de nombreux types de représentations de ressources. La négociation de contenu est quelque chose qu'un utilisateur ne se soucierait probablement jamais, mais pour les développeurs de logiciels (en particulier les développeurs de services Web), la négociation de contenu fait partie des atouts de HTTP. Un morceau de code écrit en JavaScript peut faire une demande au serveur et demander une représentation JSON. Un morceau de code écrit en C ++ peut faire une demande au serveur et demander une représentation XML. Dans les deux cas, si l'hôte peut satisfaire la demande, les informations arriveront au client dans un format idéal pour l'analyse et la consommation..
À ce stade, nous sommes allés aussi loin que possible sans entrer dans les détails de la base d'un message HTTP. Nous avons appris sur les URL, leur codage et les types de contenu. Il est temps de voir à quoi ressemblent ces spécifications de type de contenu lors de leurs déplacements sur le réseau..