Share
HTTP est synonyme de protocole de transfert hypertexte. Il s'agit d'un protocole de couche d'application sans état pour la communication entre systèmes distribués et constitue le fondement du Web moderne. En tant que développeur Web, nous devons tous bien comprendre ce protocole..
Passons en revue ce protocole puissant du point de vue d'un développeur Web. Nous aborderons le sujet en deux parties. Dans cette première entrée, nous allons couvrir les bases et décrire les différents en-têtes de requête et de réponse. Dans l'article qui suit, nous passerons en revue des éléments spécifiques de HTTP, à savoir la mise en cache, le traitement de la connexion et l'authentification..
Bien que je mentionnerai quelques détails liés aux en-têtes, il est préférable de consulter plutôt le RFC (RFC 2616) pour une couverture détaillée. Je signalerai des parties spécifiques du RFC tout au long de l'article.
Si vous rencontrez des problèmes avec une erreur HTTP dans WordPress que vous souhaitez réparer, vous pouvez commander un correctif d'erreur Express Express sur Envato Studio..
HTTP permet la communication entre une variété d'hôtes et de clients et prend en charge un mélange de configurations réseau.
Pour rendre cela possible, il suppose très peu de choses sur un système particulier et ne conserve pas d’état entre différents échanges de messages..
Cela rend HTTP un apatride protocole. La communication s'effectue généralement via TCP / IP, mais tout transport fiable peut être utilisé. Le port par défaut pour TCP / IP est 80, mais d'autres ports peuvent aussi être utilisés.
Des en-têtes personnalisés peuvent également être créés et envoyés par le client..
La communication entre un hôte et un client se produit, via un paire requête / réponse. Le client initie un message de requête HTTP, qui est traité via un message de réponse HTTP en retour. Nous examinerons cette paire de messages fondamentale dans la section suivante.
La version actuelle du protocole est HTTP / 1.1, ce qui ajoute quelques fonctionnalités supplémentaires à la version 1.0 précédente. Le plus important d'entre eux, à mon avis, comprend connexions persistantes, codage de transfert en bloc et en-têtes de mise en cache à grain fin. Nous aborderons brièvement ces fonctionnalités dans cet article. une couverture approfondie sera fournie dans la deuxième partie.
Le message de requête est au cœur des communications Web et est envoyé via des URL (Uniform Resource Locator). Je suis sûr que vous connaissez déjà les URL, mais par souci d'exhaustivité, je vais l'inclure ici. Les URL ont une structure simple composée des composants suivants:
Le protocole est typiquement http, mais ça peut aussi être https pour des communications sécurisées. Le port par défaut est 80, mais on peut en définir explicitement, comme illustré dans l'image ci-dessus. Le chemin de la ressource est le chemin local à la ressource sur le serveur.
Il existe également des serveurs proxy de débogage Web, tels que Violoneux sur Windows et Charles Proxy pour OSX.
Les URL révèlent l'identité de l'hôte avec lequel nous souhaitons communiquer, mais l'action à exécuter sur l'hôte est spécifiée via les verbes HTTP. Bien sûr, un client souhaite que l'hôte exécute plusieurs actions. HTTP a formalisé sur quelques-uns qui capturent l'essentiel qui est universellement applicable pour tous les types d'applications.
Ces verbes de demande sont:
Les quatre verbes ci-dessus sont les plus populaires, et la plupart des outils et des frameworks exposent explicitement ces verbes de demande.. METTRE et EFFACER sont parfois considérées comme des versions spécialisées du POSTER verbe, et ils peuvent être conditionnés comme POSTER requêtes avec la charge utile contenant l'action exacte: créer, mettre à jour ou effacer.
Il existe certains verbes moins utilisés que HTTP prend également en charge:
Accentsconagua
Via champ d'en-tête. Cela peut être utilisé à des fins de diagnostic.Avec les URL et les verbes, le client peut initier des requêtes sur le serveur. En retour, le serveur répond avec des codes d'état et des données utiles. Le code d'état est important et indique au client comment interpréter la réponse du serveur. La spécification HTTP définit certaines plages de numéros pour des types de réponses spécifiques:
Tous les clients HTTP / 1.1 doivent accepter les
Transfert-Encodageentête.
Cette classe de codes a été introduite dans HTTP / 1.1 et est purement provisoire. Le serveur peut envoyer un Attendre: 100-continue message, indiquant au client de continuer à envoyer le reste de la demande ou d'ignorer s'il l'a déjà envoyée. Les clients HTTP / 1.0 sont supposés ignorer cet en-tête.
Cela indique au client que la demande a été traitée avec succès. Le code le plus courant est 200 OK. Pour un OBTENIR demande, le serveur envoie la ressource dans le corps du message. Il existe d'autres codes moins fréquemment utilisés:
404 indique que la ressource n'est pas valide et n'existe pas sur le serveur.
Cela nécessite que le client prenne des mesures supplémentaires. Le cas d'utilisation le plus courant consiste à accéder à une URL différente afin d'extraire la ressource..
Emplacement l'en-tête de réponse contient l'URL temporaire.ETag (Balise Enttity) des informations qui constituent un hachage du contenu. Le serveur compare cela avec son propre calcul ETag pour vérifier les modifications.Ces codes sont utilisés lorsque le serveur pense que le client est en cause, soit en demandant une ressource non valide, soit en effectuant une mauvaise requête. Le code le plus populaire dans cette classe est 404 introuvable, Je pense que tout le monde va s'identifier. 404 indique que la ressource n'est pas valide et n'existe pas sur le serveur. Les autres codes de cette classe comprennent:
Autorisation entête. Si le client a déjà inclus le Autorisation en-tête, alors les informations d'identification étaient fausses.Cette classe de codes est utilisée pour indiquer une défaillance du serveur lors du traitement de la demande. Le code d'erreur le plus couramment utilisé est 500 Erreur interne du serveur. Les autres dans cette classe sont:
Jusqu'à présent, nous avons vu que URL, verbes et codes d'état constituent les éléments fondamentaux d'une paire requête / réponse HTTP.
Regardons maintenant le contenu de ces messages. La spécification HTTP indique qu'un message de demande ou de réponse a la structure générique suivante:
message =* ( ) CRLF [ ] = Ligne de demande | Status-Line = Nom du champ ':' Valeur du champ
Il est obligatoire de placer une nouvelle ligne entre les en-têtes et le corps du message. Le message peut contenir un ou plusieurs en-têtes, qui sont en gros classés comme suit:
Le corps du message peut contenir les données complètes de l’entité ou peut être fragmenté si le codage en bloc (Transfer-Encoding: chunked) est utilisé. Tous les clients HTTP / 1.1 doivent accepter les Transfert-Encodage entête.
Il existe quelques en-têtes (en-têtes généraux) qui sont partagés par les messages de requête et de réponse:
general-header = Cache-Control | Connexion | Date | Pragma | Bande-annonce | Transfert-Encodage | Mise à niveau | Via | Attention
Nous avons déjà vu certains de ces en-têtes, en particulier Via et Transfert-Encodage. Nous couvrirons Cache-Control et Lien dans la deuxième partie.
Le code d'état est important et indique au client comment interpréter la réponse du serveur..
Via l'en-tête est utilisé dans un message TRACE et mis à jour par tous les serveurs proxy et passerelles intermittentsPragma est considéré comme un en-tête personnalisé et peut être utilisé pour inclure des en-têtes spécifiques à une implémentation. La directive pragma la plus couramment utilisée est Pragma: no-cache, qui est vraiment Cache-Control: pas de cache sous HTTP / 1.1. Ce sera couvert dans la partie 2 de l'article.Rendez-vous amoureux Le champ d'en-tête est utilisé pour horodatage du message de demande / réponseAméliorer est utilisé pour changer de protocole et permettre une transition en douceur vers un nouveau protocole.Transfert-Encodage est généralement utilisé pour casser la réponse en parties plus petites avec le Transfer-Encoding: chunked valeur. Ceci est un nouvel en-tête dans HTTP / 1.1 et permet la transmission en continu de la réponse au client au lieu d'une grosse charge utile.Les messages de demande et de réponse peuvent également inclure des en-têtes d’entité pour fournir des méta-informations sur le contenu (corps du message ou entité). Ces en-têtes incluent:
entity-header = Autoriser | Contenu-Encodage | Contenu-Langue | Longueur du contenu | Contenu-Lieu | Content-MD5 | Contenu-Range | Type de contenu | Expire | Dernière modification
La totalité de la Contenu- les en-têtes préfixés fournissent des informations sur la structure, le codage et la taille du corps du message. Certains de ces en-têtes doivent être présents si l'entité fait partie du message..
le Expire en-tête indique un horodatage de l'expiration de l'entité. Fait intéressant, un "n'expire jamais" l'entité est envoyée avec un horodatage d'un an dans le futur. le Dernière modification en-tête indique le dernier horodatage de modification pour l'entité.
Des en-têtes personnalisés peuvent également être créés et envoyés par le client. ils seront traités comme des en-têtes d'entité par le protocole HTTP.
Il s’agit en réalité d’un mécanisme d’extension, et certaines implémentations client-serveur peuvent choisir de communiquer spécifiquement sur ces en-têtes d’extension. Bien que HTTP prenne en charge les en-têtes personnalisés, il recherche en réalité les en-têtes de requête et de réponse, que nous couvrirons ensuite..
Le message de demande a la même structure générique que ci-dessus, à l'exception de la ligne de demande qui ressemble à:
Ligne de demande = Méthode URI du SP SP-Version HTTP CRLF Method = "OPTIONS" | "HEAD" | "GET" | "POST" | "PUT" | "SUPPRIMER" | "TRACE"
SP est le séparateur d'espaces entre les jetons. Version HTTP est spécifié comme "HTTP / 1.1" puis suivi d'une nouvelle ligne. Ainsi, un message de requête typique pourrait ressembler à:
GET / articles / http-basics HTTP / 1.1 Hôte: www.articles.com Connexion: keep-alive Cache-Control: pas de cache Pragma: pas de cache Accept: text / html, application / xhtml + xml, application / xml; q = 0,9, * / *; q = 0,8
Notez la ligne de demande suivie de plusieurs en-têtes de demande. le Hôte l'en-tête est obligatoire pour les clients HTTP / 1.1. OBTENIR les demandes n'ont pas de corps de message, mais POSTER les demandes peuvent contenir les données de poste dans le corps.
Les en-têtes de requête agissent en tant que modificateurs du message de requête. La liste complète des en-têtes de requête connus n'est pas trop longue et est fournie ci-dessous. Les en-têtes inconnus sont traités comme des champs d'en-tête d'entité.
request-header = Accepter | Accepter-Charset | Accepter-Encodage | Accepter la langue | Autorisation | Attendre | À partir de | Hôte | Si-match | If-Modified-Since | Si-aucun-match | Si-gamme | Si-non modifié-depuis | Max-Forwards | Autorisation de proxy | Gamme | Référant | TE | Agent utilisateur
le Acceptez les en-têtes préfixés indiquent les types de support, les langues et les jeux de caractères acceptables sur le client. De, Hôte, Référant et Agent utilisateur identifier les détails sur le client qui a initié la demande. le Si- les en-têtes préfixés sont utilisés pour rendre une demande plus conditionnelle, et le serveur renvoie la ressource uniquement si la condition est remplie. Sinon, il retourne un 304 non modifié. La condition peut être basée sur un horodatage ou un ETag (un hachage de l'entité).
Le format de réponse est similaire au message de demande, à l'exception de la ligne d'état et des en-têtes. La ligne d'état a la structure suivante:
Status-Line = Version HTTP SP-Status Code-CR de phrase de motif CRLF
HTTP / 1.1 Une ligne d'état typique pour une réponse réussie pourrait ressembler à ceci:
HTTP / 1.1 200 OK
Les en-têtes de réponse sont également assez limités et l'ensemble complet est donné ci-dessous:
response-header = Accept-Ranges | Âge | ETag | Lieu | Authentification par procuration | Réessayer après | Serveur | Vary | WWW-Authentifier
Âge est le temps en secondes depuis que le message a été généré sur le serveur.ETag est le hachage MD5 de l'entité et utilisé pour vérifier les modifications.Emplacement est utilisé lors de l'envoi d'une redirection et contient la nouvelle URL.Serveur identifie le serveur générant le message.Cela a fait l'objet de beaucoup de théories, donc je ne vous blâmerai pas pour les yeux assoupis. Dans les sections suivantes, nous aurons plus de pratique et nous passerons en revue les outils, les cadres et les bibliothèques..
Un certain nombre d'outils sont disponibles pour surveiller les communications HTTP. Ici, nous énumérons certains des outils les plus populaires.
Sans aucun doute, le Inspecteur Chrome / Webkit est un favori parmi les développeurs web:
Il existe également des serveurs proxy de débogage Web, tels que Violoneux sur Windows et Charles Proxy pour OSX. Mon collègue, Rey Bango, a écrit un excellent article sur ce sujet..
Pour la ligne de commande, nous avons des utilitaires comme curl, tcpdump et tshark pour surveiller le trafic HTTP.
Maintenant que nous avons examiné les messages de demande / réponse, il est temps que nous apprenions comment les bibliothèques et les frameworks l'exposent sous la forme d'une API. Nous allons utiliser ExpressJS pour le noeud, Rubis sur rails, et jQuery Ajax comme nos exemples.
Si vous construisez des serveurs Web dans NodeJS, il y a de fortes chances que vous ayez considéré ExpressJS. ExpressJS a été inspiré à l’origine par un framework Ruby Web, appelé Sinatra. Comme prévu, l’API est également influencée.
Comme nous traitons avec une infrastructure côté serveur, il existe deux tâches principales dans le traitement des messages HTTP:
Comprendre HTTP est crucial pour avoir une interface propre, simple et RESTful entre deux points finaux.
ExpressJS fournit une API simple pour faire exactement cela. Nous ne couvrirons pas les détails de l'API. Au lieu de cela, nous fournirons des liens vers la documentation détaillée sur les guides ExpressJS. Les méthodes de l'API s'expliquent d'elles-mêmes dans la plupart des cas. Un exemple de l'API liée à la demande est présenté ci-dessous:
Hôte champ d'en-tête.Sur le chemin du client, ExpressJS fournit l'API de réponse suivante:
Les messages de requête et de réponse sont essentiellement les mêmes, à l'exception de la première ligne et des en-têtes de message.
Dans Rails, les modules ActionController et ActionDispatch fournissent l’API permettant de gérer les messages de demande et de réponse..
ActionController fournit une API de haut niveau pour lire l'URL de la demande, afficher la sortie et rediriger vers un autre noeud final. Un point final (ou route) est traité comme une méthode d'action. La plupart des informations de contexte nécessaires dans une méthode d'action sont fournies via le demande, réponse et params objets.
ActionDispatch fournit un accès plus fin aux messages de demande / réponse, via la commande ActionDispatch :: Request et ActionDispatch :: Response Des classes. Il expose un ensemble de méthodes de requête pour vérifier le type de demande (obtenir?(), poster?(), tête?(), local?()). Les en-têtes de demande sont directement accessibles via le request.headers () méthode.
Du côté de la réponse, il fournit des méthodes pour définir biscuits(), emplacement = () et statut = (). Si vous vous sentez aventureux, vous pouvez également définir la corps = () et contourner le système de rendu Rails.
JQuery étant avant tout une bibliothèque côté client, son API Ajax fournit l’opposé d’un framework côté serveur. En d'autres termes, cela vous permet de lis messages de réponse et modifier demander des messages. jQuery expose une API simple via jQuery.ajax (paramètres):
En passant un réglages objet avec le avantEnvoyer callback, nous pouvons modifier les en-têtes de requête. Le rappel reçoit l’objet jqXHR (jQuery XMLHttpRequest) qui expose une méthode, appelée setRequestHeader () définir les en-têtes.
$ .ajax (url: 'http://www.articles.com/latest', tapez: 'GET', beforeSend: function (jqXHR) jqXHR.setRequestHeader ('Accepts-Language', 'en-US, en ');); jqXHR.getResponseHeader ().statusCode rappeler:$ .ajax (statusCode: 404: function () alert ("page introuvable");); Voilà qui résume notre tour rapide du protocole HTTP.
Nous avons examiné la structure des URL, les verbes et les codes de statut: les trois piliers de la communication HTTP.
Les messages de demande et de réponse sont généralement les mêmes, à l'exception de la première ligne et des en-têtes de message. Enfin, nous avons examiné comment modifier les en-têtes de demande et de réponse dans les frameworks Web et les bibliothèques..
Comprendre HTTP est crucial pour avoir une interface propre, simple et RESTful entre deux points de terminaison. À plus grande échelle, cela aide également lors de la conception de votre infrastructure réseau et offre une expérience inoubliable à vos utilisateurs finaux.
Dans la deuxième partie, nous examinerons la gestion des connexions, l’authentification et la mise en cache! À plus tard.
