Share
Dans ce chapitre, nous examinerons les messages échangés dans une transaction HTTP. Nous étudierons les types de message, les en-têtes HTTP et les codes d'état. Comprendre le contenu d'un message HTTP est d'une importance capitale pour les développeurs qui travaillent sur le Web. Non seulement vous construirez de meilleures applications en répondant avec les bons types de messages, mais vous pourrez également détecter les problèmes et les problèmes de débogage lorsque les applications Web ne fonctionnent pas..
Imaginez que vous vous dirigiez vers un étranger dans un aéroport et que vous demandiez: "Savez-vous quelle heure il est?" Pour que l’étranger réponde avec l’heure exacte, quelques éléments doivent être en place. Tout d’abord, l’étranger doit comprendre votre question, car s’il ne connaît pas l’anglais, il risque de ne pas pouvoir y répondre. Deuxièmement, l’étranger devra avoir accès à une montre ou à un autre dispositif de chronométrage..
Cette analogie avec l'aéroport est similaire au fonctionnement de HTTP. Vous, le client, avez besoin d'une ressource provenant d'une autre partie (la ressource étant des informations sur l'heure). Vous faites donc une demande à l'autre partie en utilisant une langue et un vocabulaire que vous espérez comprendre. Si l'autre partie comprend votre demande et dispose de la ressource, elle peut répondre. S'il comprend la demande mais ne dispose pas de la ressource, il peut toujours répondre et vous dire qu'il ne le sait pas. Si l'autre partie ne comprend pas ce que vous dites, vous risquez de ne recevoir aucune réponse..
HTTP est un protocole de requête et de réponse. Un client envoie un Requête HTTP à un serveur en utilisant un message soigneusement formaté que le serveur comprendra. Un serveur répond en envoyant un message Réponse HTTP que le client comprendra. La demande et la réponse sont deux différents types de message qui sont échangés dans un transaction HTTP unique. Les normes HTTP définissent le contenu de ces messages de demande et de réponse afin que tous ceux qui parlent "HTTP" se comprennent et puissent échanger des ressources (ou lorsqu'une ressource n'existe pas, un serveur peut toujours répondre et vous en informer)..
Un navigateur Web sait comment envoyer une requête HTTP en ouvrant une connexion réseau à un serveur et en envoyant un message HTTP sous forme de texte. La demande n'a rien de magique, il s'agit simplement d'une commande en texte ASCII brut et formatée conformément à la spécification HTTP. Toute application pouvant envoyer des données sur un réseau peut émettre une requête HTTP. Vous pouvez même faire une demande manuelle en utilisant une application telle que Telnet à partir de la ligne de commande. Une session Telnet normale se connecte via le port 23, mais comme nous l’avons vu dans le premier chapitre, le port réseau par défaut pour HTTP est le port 80..
La figure suivante est une capture d'écran d'une session Telnet qui se connecte à odetocode.com sur le port 80, envoie une requête HTTP et reçoit une réponse HTTP..
Faire une requête HTTP La session Telnet commence en tapant:
telnet www.odetocode.com 80
Notez que le client Telnet n'est pas installé par défaut sous Windows 7, Windows Server 2008 R2, Windows Vista ou Windows Server 2008. Vous pouvez installer le client en suivant la procédure indiquée à l'adresse http://technet.microsoft.com/en. -us / bibliothèque / cc771275 (v = ws.10) .aspx.
Cette commande indique au système d'exploitation de lancer l'application Telnet et à l'application Telnet de se connecter à www.odetocode.com sur le port 80..
Une fois que Telnet est connecté, nous pouvons taper un message de requête HTTP. La première ligne est créée en tapant le texte suivant puis en appuyant sur Entrer:
GET / HTTP / 1.1
Ces informations indiqueront au serveur que nous souhaitons récupérer la ressource située dans "/" (c’est-à-dire la ressource racine ou la page d’accueil), et nous utiliserons les fonctionnalités HTTP 1.1. La prochaine ligne que nous tapons est:
hôte: www.odetocode.com
Ces informations sur l'hôte sont des informations obligatoires dans un message de requête HTTP 1.1. La raison technique est d’aider les serveurs prenant en charge plusieurs sites Web, c’est-à-dire que www.odetocode.com et www.odetofood.com pourraient être hébergés sur le même serveur, et les informations sur l’hôte contenues dans le message aideront le serveur Web à diriger le demande à l'application Web appropriée.
Après avoir tapé les deux lignes précédentes, nous pouvons appuyer sur Entrer deux fois pour envoyer le message au serveur. Ce que vous voyez ensuite dans la fenêtre Telnet est la réponse HTTP du serveur Web. Nous entrerons dans plus de détails plus tard, mais la réponse indique que la ressource que nous voulons (la page d'accueil par défaut de www.odetocode.com) a été déplacée. Il a déménagé à l'emplacement odetocode.com. Il appartient maintenant au client d’analyser ce message de réponse et d’envoyer une demande à odetocode.com au lieu de www.odetocode.com s’il souhaite récupérer la page d’accueil. Tout navigateur Web ira automatiquement au nouvel emplacement.
Ces types de "redirections" sont courants et dans ce scénario, la raison est de s'assurer que toutes les demandes de ressources provenant d'OdeToCode passent par odetocode.com et non par www.odetocode.com (il s'agit d'une optimisation de moteur de recherche appelée canonisation d'URL)..
Maintenant que nous avons vu une requête et une réponse HTTP brute, analysons des éléments spécifiques..
le OBTENIR Le mot tapé dans la session Telnet est l’un des principaux Méthodes HTTP. Chaque message de requête doit inclure l’une des méthodes HTTP et celle-ci indique au serveur ce que la requête veut faire. Un HTTP OBTENIR veut obtenir, récupérer et récupérer une ressource. Vous pourriez OBTENIR une image (GET /logo.png), ou OBTENIR un fichier PDF, (GET /documents/report.pdf), ou toute autre ressource récupérable que le serveur pourrait contenir. Une liste des opérateurs HTTP courants est présentée dans le tableau suivant..
| Méthode | La description |
| OBTENIR | Récupérer une ressource |
| METTRE | Stocker une ressource |
| EFFACER | Supprimer une ressource |
| POSTER | Mettre à jour une ressource |
| TÊTE | Récupérer les en-têtes d'une ressource |
Parmi ces cinq méthodes, deux seulement sont les principaux outils de travail du Web: OBTENIR et POSTER. Un navigateur Web émet un OBTENIR demande quand il veut récupérer une ressource, comme une page, une image, une vidéo ou un document. OBTENIR les demandes sont le type de demande le plus courant.
Un navigateur Web envoie une POSTER demande quand il a des données à envoyer au serveur. Par exemple, en cliquant sur "Ajouter au panier" sur un site comme amazon.com, POSTER informations à Amazon sur ce que nous voulons acheter. POSTER les demandes sont généralement générées par un sur une page Web, comme le formulaire que vous remplissez éléments pour les informations d'adresse et de carte de crédit.
Il y a une partie de la spécification HTTP qui parle des méthodes HTTP "sûres". Méthodes sûres, comme son nom l'indique, ne faites rien de "dangereux" comme détruire une ressource, soumettre une transaction par carte de crédit ou annuler un compte. le OBTENIR La méthode est l'une des méthodes sûres, car elle doit uniquement extraire une ressource et ne pas en modifier l'état. Envoi d'un OBTENIR demande d'une image JPG ne change pas l'image, elle récupère uniquement l'image pour l'affichage. En bref, il ne devrait jamais y avoir d’effet secondaire à une OBTENIR demande.
Un HTTP POSTER n'est pas une méthode sûre. UNE POSTER modifie généralement quelque chose sur le serveur: il met à jour un compte, soumet une commande ou effectue une autre opération spéciale. Les navigateurs Web traitent généralement OBTENIR et POSTER différemment puisque OBTENIR est en sécurité et POSTER est dangereux. Vous pouvez actualiser une page Web récupérée par un OBTENIR request-le navigateur Web rééditera le dernier OBTENIR demander et rendre tout ce que le serveur renvoie. Cependant, si la page que nous regardons dans un navigateur est la réponse d’un HTTP POSTER demande, le navigateur nous avertira si nous essayons d’actualiser la page. Peut-être que vous avez vu ces types d'avertissements dans votre navigateur Web.
Actualiser une demande POST En raison de tels avertissements, de nombreuses applications Web essaient toujours de laisser le client visualiser le résultat d'un événement. OBTENIR demande. Après qu'un utilisateur clique sur un bouton pour POSTER informations à un serveur (comme pour passer une commande), le serveur traitera les informations et répondra par une redirection HTTP (comme la redirection affichée dans la fenêtre Telnet) en indiquant au navigateur: OBTENIR une autre ressource. Le navigateur émettra le OBTENIR demande, le serveur répondra par une ressource "merci pour la commande", puis l'utilisateur pourra actualiser ou imprimer la page en toute sécurité autant de fois qu'il le voudra. Ceci est un modèle de conception Web commun connu sous le nom POSTER/Réorienter/OBTENIR modèle.
Maintenant que nous en savons un peu plus sur POSTER et OBTENIR, Parlons de quelques scénarios courants et voyons quand utiliser les différentes méthodes.
Supposons que vous avez une page et que vous souhaitiez que l'utilisateur clique sur un lien pour afficher le premier article de cette série. Dans ce cas, un simple hyperlien suffit.
Partie I
Lorsqu'un utilisateur clique sur le lien hypertexte dans un navigateur, celui-ci émet une OBTENIR demande à l'URL spécifiée dans le href attribut de la balise d'ancrage. La demande ressemblerait à ceci:
GET http://odetocode.com/Articles/741.aspx Hôte HTTP / 1.1: odetocode.com
Imaginez maintenant que vous avez une page sur laquelle l'utilisateur doit renseigner des informations pour créer un compte. Remplir les informations nécessite balises, et nous imbriquons ces entrées dans un marquer et indiquer au navigateur où envoyer les informations.
Lorsque l'utilisateur clique sur le bouton d'envoi, le navigateur se rend compte que le bouton se trouve dans un formulaire. Le formulaire indique au navigateur que la méthode HTTP à utiliser est POSTER, et le chemin de POSTER est / compte / créer. La requête HTTP actuelle du navigateur ressemble à ceci:.
POST http: // localhost: 1060 / account / create HTTP / 1.1 Hôte: server.com firstName = Scott & lastName = Allen
Notez que les entrées de formulaire sont incluses dans le message HTTP. Cela ressemble beaucoup à la façon dont les paramètres apparaissent dans une URL, comme nous l'avons vu dans l'article précédent. C'est à l'application Web qui reçoit cette demande d'analyser ces valeurs et de créer le compte d'utilisateur. L'application peut alors répondre de différentes manières, mais il existe trois réponses communes:
Accentsconagua
POSTER demande, ce qui peut entraîner des problèmes s’il rafraîchit la page, mais peut essayer de les enregistrer une seconde fois.!OBTENIR demande d'une page indiquant à l'utilisateur que le compte a été créé.Un troisième scénario est un scénario de recherche. Dans un scénario de recherche, vous avez besoin d’un pour que l'utilisateur entre un terme de recherche. Cela pourrait ressembler à ce qui suit.
Notez que la méthode sur ce formulaire est OBTENIR, ne pas POSTER. En effet, la recherche est une opération de récupération en toute sécurité, contrairement à la création d'un compte ou à la réservation d'un vol à destination de la Belgique. Le navigateur va collecter les entrées dans le formulaire et émettre un OBTENIR demande au serveur:
Obtenez http: // localhost: 1060 / search? Term = love HTTP / 1.1 Hôte: searchengine.com
Notez qu'au lieu de placer les valeurs d'entrée dans le corps du message, les entrées vont dans la partie chaîne de requête de l'URL. Le navigateur envoie un OBTENIR demande / recherche? terme = amour. Puisque le terme de recherche est dans l'URL, l'utilisateur peut marquer l'URL en signet ou copier le lien et l'envoyer par courrier électronique. L'utilisateur peut également actualiser la page autant de fois qu'il le souhaite, encore une fois parce que le OBTENIR l'opération pour les résultats de la recherche est une opération sûre qui ne détruira ni ne modifiera les données.
Nous avons beaucoup parlé des ressources en tant que ressources physiques sur le système de fichiers d'un serveur. Très souvent, des ressources telles que des fichiers PDF, des fichiers vidéo, des fichiers image et des fichiers de script faire existent sous forme de fichiers physiques sur le serveur. Cependant, les URL pointant dans de nombreuses applications Web modernes ne pointent pas vraiment vers les fichiers. Des technologies telles que ASP.NET et Ruby on Rails vont intercepter la demande d'une ressource et y répondre comme bon leur semble. Ils peuvent lire un fichier depuis une base de données et renvoyer le contenu de la réponse HTTP pour lui donner l’impression que la ressource existait réellement sur le serveur lui-même..
Un bon exemple est le POSTER exemple, nous avons utilisé plus tôt qui a abouti à une demande de / compte / créer. Il y a des chances qu'il n'y ait pas de fichier réel nommé "créer" dans un répertoire "compte". Au lieu de cela, quelque chose sur le serveur Web récupère cette demande, lit et valide les informations utilisateur et crée un enregistrement dans la base de données. le / compte / créer la ressource est virtuelle et n'existe pas. Cependant, plus une ressource virtuelle est perçue comme une ressource réelle, plus l'architecture et la conception de votre application seront conformes aux atouts du protocole HTTP..
Jusqu'à présent, nous avons vu une requête HTTP brute et parlé des deux méthodes HTTP les plus populaires.-OBTENIR et POSTER. Mais comme l'a montré la sortie Telnet, un message de requête HTTP ne se limite pas à la méthode HTTP. Un message de requête HTTP complet comprend les parties suivantes:
[méthode] [URL] [version] [en-têtes] [corps]
Le message est toujours en texte ASCII et la ligne de départ contient toujours la méthode, l'URL et la version HTTP (le plus souvent 1.1, qui existe depuis 1999). La dernière section, la section body, peut contenir des données telles que les paramètres de connexion au compte que nous avons vus précédemment. Lors du téléchargement d'un fichier, la section du corps peut être assez grande.
La section du milieu, la section où nous avons vu Hôte: odetocode.com, contient un ou plusieurs En-têtes HTTP (rappelez-vous, dans HTTP 1.1 hôte est un en-tête obligatoire). Les en-têtes contiennent des informations utiles pouvant aider un serveur à traiter une requête. Par exemple, dans le dernier article, nous avons parlé de la représentation des ressources et de la façon dont le client et le serveur peuvent négocier la meilleure représentation d'une ressource (négociation de contenu). Si le client veut voir une ressource en français, par exemple, il peut inclure une entrée d’en-tête (le Accepter la langue en-tête) demandant du contenu en français.
GET http://odetocode.com/Articles/741.aspx Hôte HTTP / 1.1: odetocode.com Accept-Language: fr-FR
Il existe de nombreux en-têtes définis par la spécification HTTP. Certains en-têtes sont des en-têtes généraux pouvant apparaître dans une requête ou un message de réponse. Un exemple est le Rendez-vous amoureux entête. Le client ou le serveur peut inclure un Rendez-vous amoureux en-tête indiquant quand il a créé le message.
GET http://odetocode.com/Articles/741.aspx HTTP / 1.1 Hôte: odetocode.com Accepter-Langue: fr-FR Date: vendredi, 9 août 2002 à 21h12 GMT
Tout sauf l'en-tête de l'hôte est facultatif, mais lorsqu'un en-tête apparaît, il doit obéir aux normes. Par exemple, la spécification HTTP indique que la valeur de l'en-tête de date doit être au format RFC822 pour les dates..
Certains des en-têtes de demande les plus populaires apparaissent dans le tableau suivant..
| Entête | La description |
| Référant | Lorsque l'utilisateur clique sur un lien, le client peut envoyer l'URL de la page de renvoi dans cet en-tête.. |
| Agent utilisateur | Informations sur l'agent utilisateur (le logiciel) à l'origine de la demande. De nombreuses applications utilisent les informations contenues dans cet en-tête, le cas échéant, pour déterminer le navigateur à l'origine de la demande (Internet Explorer 6 par rapport à Internet Explorer 9 par rapport à Chrome, etc.).. |
| Acceptez | Décrit les types de média que l'agent utilisateur est prêt à accepter. Cet en-tête est utilisé pour la négociation de contenu. |
| Accepter la langue | Décrit les langues préférées de l'agent d'utilisateur.. |
| Biscuit | Contient des informations sur les cookies, que nous examinerons dans un chapitre ultérieur. Les informations sur les cookies aident généralement un serveur à suivre ou à identifier un utilisateur. |
| Si-Modifié-Depuis | Contiendra une date à laquelle l'agent utilisateur a récupéré (et mis en cache) la ressource pour la dernière fois. Le serveur doit seulement renvoyer la totalité de la ressource si elle a été modifiée depuis ce moment.. |
Une requête HTTP complète pourrait ressembler à ceci.
GET http://odetocode.com/ HTTP / 1.1 Hôte: odetocode.com Connexion: Keep-Alive Agent utilisateur: Mozilla / 5.0 (Windows NT 6.1; WOW64) Chrome / 16.0.912.75 Safari / 535.7 Accepter: text / html, application / xhtml + xml, application / xml; q = 0,9, * / *; q = 0,8 Référent: http://www.google.com/url?&q=odetocode Accept-Encoding: gzip, deflate, sdch Accept-Language : en-US, en; q = 0,8 Jeu de caractères acceptés: ISO-8859-1, utf-8; q = 0,7, *; q = 0,3
Comme vous pouvez le constater, certains en-têtes contiennent plusieurs valeurs, comme le Acceptez entête. le Acceptez header répertorie les types MIME qu’il aime voir, y compris HTML, XHTML, XML et enfin * / * (ce qui signifie que je préfère le HTML, mais vous pouvez m'envoyer n'importe quoi (* / *) et je vais essayer de le comprendre. en dehors).
Notez également l'apparition de "q"dans certains en-têtes. Le q la valeur est toujours un nombre de 0 à 1 et représente le valeur de qualité ou "degré de préférence relatif" pour une valeur particulière. La valeur par défaut est 1,0 et les chiffres les plus élevés indiquent une préférence plus élevée..
Une réponse HTTP a une structure similaire à une requête HTTP. Les sections d'une réponse sont:
[version] [statut] [raison] [en-têtes] [corps]
La réponse HTTP complète à la dernière demande complète que nous avons répertoriée pourrait ressembler à ceci (la plupart du code HTML ayant été omis pour des raisons de brièveté).
HTTP / 1.1 200 OK Cache-Control: privé Content-Type: text / html; charset = utf-8 Serveur: Microsoft-IIS / 7.0 X-AspNet-Version: 2.0.50727 X-Powered-By: ASP.NET Date: sam., 14 janv. 2012 04:00:08 GMT Connexion: close Content-Length: 17151.Articles, codes et ressources relatifs à NET … contenu…
La ligne d’ouverture d’une demande commence par la version HTTP, puis le code d’état très important et le motif.
Le code d'état est un numéro défini par la spécification HTTP et tous les numéros appartiennent à l'une des cinq catégories..
| Intervalle | Catégorie |
| 100-199 | Informatif |
| 200-299 | Réussi |
| 300-399 | La redirection |
| 400-499 | Erreur du client |
| 500-599 | erreur du serveur |
Bien que nous ne détaillions pas tous les codes d’état HTTP possibles, le tableau suivant détaille les codes les plus courants..
| Code | Raison | La description |
| 200 | D'accord | Le code de statut que tout le monde veut voir. Un code 200 dans la réponse signifie que tout a fonctionné! |
| 301 | Déplacé de façon permanente | La ressource a été déplacée vers l'URL spécifiée dans le Emplacement en-tête et le client n'a plus jamais besoin de vérifier cette URL.Nous en avons vu un exemple plus tôt lorsque nous avons utilisé Telnet et que le serveur nous a redirigés de www.odetocode.com vers odetocode.com afin de donner aux moteurs de recherche une URL canonique.. |
| 302 | Déplacé temporairement | La ressource a été déplacée vers l'URL spécifiée dans le Emplacement entête. À l'avenir, le client peut toujours demander l'URL car il s'agit d'un déplacement temporaire..Ce type de code de réponse est généralement utilisé après une POSTER opération de déplacement d'un client vers une ressource qu'il peut récupérer avec OBTENIR (la POSTER/Réorienter/OBTENIR motif dont nous avons parlé plus tôt). |
| 304 | Non modifié | C'est le serveur qui informe le client que la ressource n'a pas changé depuis la dernière fois où le client l'a récupérée, afin qu'il puisse simplement utiliser une copie mise en cache localement.. |
| 400 | Mauvaise Demande | Le serveur n'a pas pu comprendre la demande. La requête a probablement utilisé une syntaxe incorrecte. |
| 403 | Interdit | Le serveur a refusé l'accès à la ressource. |
| 404 | Pas trouvé | Un code populaire signifiant que la ressource n'a pas été trouvée. |
| 500 | Erreur Interne du Serveur | Le serveur a rencontré une erreur lors du traitement de la demande. Cela arrive souvent à cause d'erreurs de programmation dans une application Web. |
| 503 | Service indisponible | Le serveur ne traitera pas actuellement la demande. Ce code d'état peut apparaître lorsqu'un serveur limite les demandes parce qu'il est soumis à une charge importante.. |
Les codes d’état de réponse constituent une partie extrêmement importante du message HTTP car ils indiquent au client ce qui s’est passé (ou, dans le cas de redirections, où aller ensuite).
N'oubliez pas que le code d'état HTTP est un code indiquant ce qui se passe au niveau HTTP. Cela ne reflète pas nécessairement ce qui s'est passé dans votre application. Par exemple, imaginons qu'un utilisateur envoie un formulaire de connexion au serveur sans remplir le champ Nom. Si votre application nécessite un nom de famille, la création d'un compte pour l'utilisateur échouera. Cela ne signifie pas que vous devez renvoyer un code d'erreur HTTP indiquant un échec. Vous voulez probablement que le contraire se produise: vous voulez renvoyer du contenu au client avec un code d'état 200 (OK). Le contenu indiquera à l'utilisateur qu'un nom de famille n'a pas été fourni. Du point de vue de l'application, la demande était un échec, mais du point de vue HTTP, la demande a été traitée avec succès. Ceci est normal dans les applications web.
Une réponse comprend des informations d’en-tête qui fournissent aux métadonnées d’un client qu’il peut utiliser pour traiter la réponse. Par exemple, le type de contenu sera spécifié en tant que type MIME, comme nous en avons parlé dans le dernier article. Dans la réponse suivante, nous pouvons voir que le type de contenu est HTML et que le jeu de caractères utilisé pour coder le type est UTF-8. Les en-têtes peuvent également contenir des informations sur le serveur, telles que le nom du logiciel et la version..
HTTP / 1.1 200 OK Cache-Control: privé Content-Type: text / html; charset = utf-8 Serveur: Microsoft-IIS / 7.0 X-AspNet-Version: 2.0.50727 X-Powered-By: ASP.NET Date: sam., 14 janv. 2012 04:00:08 GMT Connexion: close Content-Length: 17151.Articles, codes et ressources relatifs à NET … contenu…
Les en-têtes de réponse qui apparaissent dépendent souvent du type de réponse. Par exemple, une réponse de redirection doit inclure un Emplacement en-tête qui indique au client où aller ensuite.
Plusieurs en-têtes sont consacrés à la mise en cache et à l'optimisation des performances.. ETag, Expire, et Dernière modification tous fournissent des informations sur la possibilité de mise en cache d'une réponse. Un ETag est un identifiant qui changera lorsque la ressource sous-jacente change, pour comparer ETags est un moyen efficace de savoir s’il faut rafraîchir quelque chose. Un Expire en-tête indique à un client combien de temps mettre en cache une ressource particulière. Nous reviendrons et examinerons la mise en cache plus en détail plus tard.
Dans ce chapitre, nous avons appris que les messages HTTP venaient toujours par paires. Il y a d'abord la demande, puis la réponse. Les informations contenues dans ces messages sont toutes sous forme de texte lisible et vous pouvez utiliser de nombreux outils pour inspecter les requêtes HTTP effectuées sur votre ordinateur. Fiddler est un de ces outils si vous utilisez Windows (http://fiddler2.com). Il est facile à utiliser et vous pouvez voir les demandes HTTP brutes en cours, y compris tous les en-têtes..
Les messages visent tous à s'assurer que les deux parties à une transaction comprennent ce qu'elles reçoivent. La première ligne d'un message HTTP est toujours explicite quant à son intention. Dans un message de demande, l'URL et la méthode HTTP apparaissent en premier pour identifier ce qui doit arriver à une ressource particulière. Dans une réponse, le code d'état indiquera comment la demande a été traitée. Nous avons également des en-têtes se déplaçant dans les deux sens qui fournissent encore plus d’informations sur la demande et la réponse. Dans le chapitre suivant, nous en apprendrons un peu plus sur la manière dont ces messages circulent sur le réseau..
