CodeGym /Blog Java /Random-FR /Partie 3. HTTP/HTTPS
John Squirrels
Niveau 41
San Francisco

Partie 3. HTTP/HTTPS

Publié dans le groupe Random-FR
Ce matériel fait partie de la série "Introduction au développement d'entreprise". Articles précédents : Partie 3. HTTP/HTTPS - 1Salut! Aujourd'hui, nous allons découvrir les protocoles HTTP et HTTPS. Mais d'abord, clarifions un point : nous parlons de protocoles d'envoi de données sur un réseau au niveau applicatif du modèle OSI. Vous vous souvenez peut-être que nous avons découvert le modèle OSI dans l'un des articles précédents. Si vous ne vous en souvenez pas, c'est ici .

Qu'est-ce qu'un protocole de communication de données ?

C'est ce que nous appelons l'ensemble convenu de règles qui permettent aux développeurs de différents services d'envoyer des informations dans un format que d'autres peuvent comprendre. Par exemple, vous pouvez utiliser Google Chrome pour obtenir des informations à la fois de Facebook et de Twitter, car les développeurs les envoient en utilisant le protocole HTTP standard, qui permet à votre navigateur de les traiter. Les règles uniformes sont très pratiques pour les personnes qui développent la partie serveur : il existe de nombreuses bibliothèques qui peuvent convertir les informations pour vous et les envoyer en utilisant le protocole approprié. HTTP a été initialement conçu comme un protocole d'envoi de pages HTML. C'est ainsi qu'il a été utilisé pendant longtemps, mais maintenant les programmeurs l'utilisent souvent pour envoyer à la fois des chaînes et des fichiers multimédias. En général, ce protocole est universellement accepté et polyvalent, et il est vraiment facile à utiliser. Et maintenant, nous allons étudier comment l'utiliser.

La structure de HTTP

Notons tout de suite que le protocole HTTP n'est composé que de texte. Ce qui nous intéresse le plus, c'est la structure de ce texte. Chaque message est composé de trois parties :
  1. Ligne de départ — Ceci définit certaines données de gestion interne.
  2. En-têtes — Ceux-ci décrivent les paramètres de message.
  3. Corps — Il s'agit du contenu du message. Le corps doit être séparé des en-têtes par une ligne vide.
Le protocole HTTP est utilisé pour envoyer des requêtes à un serveur et recevoir des réponses du serveur. Les paramètres des requêtes et des réponses sont légèrement différents.

Voici à quoi ressemble une requête HTTP simple :


GET / HTTP/1.1
Host: codegym.cc
User-Agent: firefox/5.0 (Linux; Debian 5.0.8; en-US; rv:1.8.1.7)
La ligne de départ indique :
  • GET — La méthode de la requête
  • / — Le chemin de la requête
  • HTTP/1.1 — La version du protocole
Viennent ensuite les en-têtes :
  • Hôte — L'hôte auquel la demande est adressée
  • User-Agent — Le client qui envoie la requête
Le corps du message est manquant. Dans une requête HTTP, seuls la ligne de début et l'en-tête "Host" sont requis. Maintenant, regardons tout une étape à la fois. Une requête HTTP doit contenir une méthode. Il y en a neuf : GET, POST, PUT, OPTIONS, HEAD, PATCH, DELETE, TRACE, CONNECT. Les plus courants sont GET et POST. Ces deux méthodes suffiront dans un premier temps. GET — Cette méthode demande du contenu au serveur. Par conséquent, les requêtes avec la méthode GET n'ont pas de corps de message. Mais si vous en avez besoin, vous pouvez passer des paramètres via le chemin (dans la ligne de départ) au format suivant :

https://cdn.codegym.cc/images/article/155cea79-acfd-4968-9361-ad585e939b82/original.pngsend?name1=value1&name2=value2
codegym.cc est l'hôte, /send est le chemin de la requête et ? est un séparateur qui indique que les paramètres de la requête suivent. À la fin, les paires clé-valeur (« clé=valeur ») sont répertoriées, séparées par une esperluette. POST — Cette méthode publie des informations sur le serveur. Une requête POST peut envoyer différents types d'informations : des paramètres sous forme de paires "clé=valeur", JSON, du code HTML ou même des fichiers. Toutes les informations sont envoyées dans le corps du message. Par exemple:

POST /user/create/json HTTP/1.1
Accept: application/json
Content-Type: application/json
Content-Length: 28
Host: codegym.cc

{
  "Id": 12345,
  "User": "John"
}
La demande est envoyée à codegym.cc/user/create/json, et la version du protocole est HTTP/1.1. "Accepter" indique le format de réponse que le client s'attend à recevoir. "Content-Type" indique le format du corps du message envoyé dans la requête. "Content-Length" est le nombre de caractères dans le corps. Une requête HTTP peut contenir de nombreux en-têtes différents. Pour plus d'informations, consultez la spécification du protocole .

Réponses HTTP

Après réception d'une requête, le serveur la traite et envoie une réponse au client :

HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Content-Length: 98

<html>
  <head>
    <title>An Example Page</title>
  </head>
  <body>
    <p>Hello World</p>
  </body>
</html>
La ligne de début de la réponse contient la version du protocole (HTTP/1.1), le code d'état (200) et la description de l'état (OK). Ses en-têtes incluent le type et la longueur du contenu. Le corps de la réponse contient du code HTML que le navigateur restitue sous la forme d'une page HTML.

Codes d'état de réponse

Tout est clair concernant le corps du message et les en-têtes, mais nous devons dire quelques mots sur les codes de statut. Les codes d'état de réponse sont toujours à trois chiffres. Le premier chiffre du code indique la catégorie de la réponse :
  • 1xx — Informationnel. La demande a été reçue. Le serveur est prêt à continuer.
  • 2xx — Réussi. La demande a été reçue, comprise et traitée.
  • 3xx — Redirection. Des actions supplémentaires doivent être effectuées pour traiter la demande.
  • 4xx — Erreur client. La demande contient des erreurs ou n'est pas conforme au protocole.
  • 5xx — Erreur de serveur. La demande a été composée correctement, mais le serveur n'a pas pu la traiter.
Les deuxième et troisième chiffres du code indiquent une réponse plus spécifique. Par exemple:
  • 200 OK — La demande a été reçue et traitée avec succès.
  • 201 Créé — La demande a été reçue et traitée avec succès, ce qui a entraîné la création d'une nouvelle ressource ou instance.
  • 301 Déplacé définitivement — La ressource demandée a été déplacée définitivement. Les demandes ultérieures doivent être faites en utilisant la nouvelle adresse.
  • 307 Redirection temporaire — La ressource a été temporairement déplacée. Pour l'instant, il est accessible par renvoi automatique.
  • 403 Interdit — La demande a été comprise, mais une autorisation est requise.
  • 404 Not Found — Le serveur n'a pas trouvé la ressource à cette adresse.
  • 501 Non implémenté — Le serveur ne prend pas en charge la fonctionnalité requise pour répondre à la demande.
  • 505 Version HTTP non prise en charge — Le serveur ne prend pas en charge la version spécifiée du protocole HTTP.
En plus du code d'état de réponse, une description d'état est également envoyée. Cela permet de clarifier la signification de chaque statut spécifique. Le protocole HTTP est très pratique : il fournit un grand nombre d'en-têtes, que vous pouvez utiliser pour organiser une communication très souple entre un client et un serveur. Un examen complet de tous les en-têtes de demande et de réponse, des méthodes de demande et des codes d'état de réponse serait trop pour un seul article. Si vous en avez besoin, vous pouvez lire la spécification officielle du protocole, qui décrit toutes les nuances. Il est habituel d'utiliser le protocole HTTP sur le port 80, donc lorsque vous voyez une URL qui se termine par le port 80, vous pouvez être sûr que vous devez utiliser HTTP pour y accéder. Au fur et à mesure que la technologie évoluait et que des données personnelles commençaient à être envoyées sur Internet, il est devenu nécessaire de réfléchir à la manière de fournir une protection supplémentaire aux informations que le client envoie au serveur. Le résultat de cette réflexion a été le protocole HTTPS.

La différence entre HTTPS et HTTP

En termes de syntaxe, HTTPS est identique au protocole HTTP. Autrement dit, il utilise les mêmes lignes de départ et en-têtes. Les seules différences sont le cryptage supplémentaire et le port par défaut (443) . HTTPS est chiffré entre HTTP et TCP, c'est-à-dire entre les couches application et transport. Si vous avez oublié ce que cela signifie, consultez l'article sur le modèle OSI . La norme de chiffrement actuelle est TLS. Nous n'aborderons pas trop ce sujet, mais rappelez-vous que le chiffrement a lieu avant que les informations n'atteignent la couche de transport.. En HTTPS, absolument toutes les informations sont cryptées, à l'exception de l'hôte et du port où la requête est envoyée. Basculer un serveur pour utiliser le protocole HTTPS au lieu de HTTP ne nécessite pas de modifier le code du serveur. Cette fonctionnalité est activée dans les conteneurs de servlet, dont nous parlerons dans les articles suivants. Et c'est tout pour aujourd'hui. En fait, attendez un instant. Pour mettre la main sur certaines requêtes HTTP, ouvrez Google Chrome, appuyez sur F12 et sélectionnez l'onglet "Réseau". Toutes les demandes et réponses envoyées/reçues par votre navigateur seront affichées ici. Partie 4. Les bases de Maven Partie 5. Les servlets et l'API Java Servlet. Écrire une application Web simple Partie 6. Conteneurs de servlet Partie 7. Présentation du modèle MVC (Model-View-Controller)
Commentaires
TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION