Partie 3. Protocoles HTTP/HTTPS

Ce matériel fait partie de la série « Introduction au développement d'entreprise ». Articles précédents :

• sur le réseau ;
• sur l'architecture logicielle .

Bonjour! Aujourd'hui, nous comprendrons les protocoles HTTP et HTTPS. Mais d'abord, clarifions un point : nous parlons de protocoles de transfert de données sur le réseau au niveau de la couche application du modèle OSI. Comme vous vous en souvenez, nous avons discuté du modèle OSI dans l'un des articles précédents. Et si vous ne vous en souvenez pas, le voici .

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

C'est le nom donné à l'accord généralement accepté, grâce auquel les développeurs de différents services envoient des informations sous une forme unique. Par exemple, en utilisant Google Chrome, vous pouvez obtenir des informations à la fois de Facebook et de Twitter, car les développeurs les transmettent via le protocole HTTP standard et votre navigateur peut les traiter. Les règles uniformes sont également très pratiques pour les développeurs côté serveur eux-mêmes : il existe de nombreuses bibliothèques qui peuvent convertir les informations pour vous et les envoyer en utilisant le protocole requis. HTTP a été initialement conçu comme un protocole de transfert de pages HTML. Cela a été le cas pendant longtemps, mais aujourd'hui, les programmeurs transfèrent souvent à la fois des chaînes et des fichiers multimédias. Dans l’ensemble, ce protocole est polyvalent et flexible, et il est très simple à utiliser. Voyons maintenant comment procéder.

Structure HTTP

Il convient de noter d’emblée que le protocole HTTP se compose uniquement de texte. Eh bien, ce qui nous intéresse le plus, c'est la structure dans laquelle se trouve ce texte. Chaque message se compose de trois parties :

1. Ligne de départ : définit les données de service.
2. En-têtes - description des paramètres du message.
3. Corps du message (Corps) - données du message. Doit être séparé des titres par une ligne vide.

Grâce au protocole HTTP, vous pouvez envoyer une requête au serveur (requête) et recevoir une réponse du serveur (réponse). Les demandes et les réponses ont des paramètres légèrement différents.

À quoi ressemble une simple requête HTTP

GET / HTTP/1.1
Host: javarush.com
User-Agent: firefox/5.0 (Linux; Debian 5.0.8; en-US; rv:1.8.1.7)

La ligne de départ contient :

• GET - méthode de requête ;
• / — chemin de requête (chemin) ;
• HTTP/1.1 - version du protocole de transfert de données.

Suivez ensuite les rubriques :

• Hôte — l'hôte auquel la demande est adressée ;
• User-Agent est le client qui envoie la demande.

Il n'y a pas de corps de message. Dans une requête HTTP, seules la ligne de départ et l'en-tête Host sont requis. Voyons maintenant tout dans l'ordre. Une requête HTTP doit contenir une méthode. Il y en a neuf au total : 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 - 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 nécessaire, vous pouvez envoyer les paramètres via chemin dans ce format : https://cdn.javarush.com/images/article/155cea79-acfd-4968-9361-ad585e939b82/original.pngsend?name1=value1&name2=value2 Ici : javarush .com — hôte, /send — chemin de requête, ? — un séparateur indiquant que les paramètres de la demande suivent. A la fin, les paramètres sont répertoriés au format clé=valeur, séparés par une esperluette. POST - publie des informations sur le serveur. Une requête POST peut transférer diverses informations : des paramètres au format clé=valeur, du JSON, du code HTML, ou encore des fichiers. Toutes les informations sont transmises 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: javarush.com

{
  "Id": 12345,
  "User": "John"
}

La requête est envoyée à javarush.com/user/create/json, la version du protocole est HTTP/1.1. Accept spécifie le format de réponse que le client s'attend à recevoir, Content-Type spécifie le format dans lequel le corps du message est envoyé. Content-Length - le nombre de caractères dans le corps. Une requête HTTP peut contenir de nombreux en-têtes différents. Plus de détails peuvent être trouvés dans la spécification du protocole .

Réponses HTTP

Après avoir reçu la 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épart de la réponse contient la version du protocole (HTTP/1.1), le code d'état (200) et la description de l'état (OK). Les titres indiquent le type et la longueur du contenu. Le corps de la réponse contient le code HTML que le navigateur dessinera dans la page HTML.

Codes d'état de réponse

Tout est clair avec le corps du message et les en-têtes, mais cela vaut la peine de dire quelques mots sur les codes d'état. Les codes d'état de réponse sont toujours composés de trois chiffres et le premier chiffre du code indique la catégorie de la réponse :

• 1xx - informatif. La requête 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. Les étapes suivantes 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. Le serveur n'a pas pu traiter la demande, bien qu'elle ait été rédigée correctement ;

Les deuxième et troisième chiffres du code détaillent la réponse. 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, entraînant la création d'une nouvelle ressource ou de son instance ;
• 301 Déplacé de façon permanente - la ressource demandée a été déplacée de façon permanente et les demandes ultérieures doivent être effectuées à la nouvelle adresse ;
• 307 Redirection temporaire - la ressource a été déplacée temporairement. Pour l'instant, vous pouvez y accéder via la redirection automatique ;
• 403 Interdit - la demande est claire, 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é permettant de répondre à cette 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 la réponse, une description de l'état est également envoyée, ce qui permet de comprendre intuitivement ce que signifie un état particulier. Le protocole HTTP est très pratique : il fournit un grand nombre d'en-têtes, à l'aide desquels vous pouvez établir une communication flexible entre le client et le serveur. Tous les en-têtes de demande et de réponse, les méthodes de demande et les codes d'état de réponse ne peuvent pas être pris en compte dans un seul article. Si nécessaire, vous pouvez lire la spécification officielle du protocole , qui décrit toutes les nuances. Le protocole HTTP est généralement utilisé sur le port 80, donc lorsque vous voyez une adresse qui se termine sur le port 80, vous pouvez être sûr qu'elle doit être accessible via HTTP. Avec le développement de la technologie et la circulation active des données personnelles sur Internet, nous avons dû réfléchir à la manière d'assurer une protection supplémentaire aux informations que le client transmet au serveur. Le résultat fut le protocole HTTPS.

Quelle est la différence entre HTTPS et HTTP

HTTPS est syntaxiquement identique au protocole HTTP, c'est-à-dire qu'il utilise les mêmes lignes de départ et les mêmes en-têtes. Les seules différences sont un 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é de quoi il s'agit, jetez un œil à l'article sur le modèle OSI . La norme de cryptage moderne est TLS. Nous n'approfondirons pas ce sujet, mais n'oubliez pas que le cryptage a lieu avant que les informations n'atteignent la couche de transport . HTTPS crypte absolument toutes les informations, à l'exception de l'hôte et du port auxquels la requête est envoyée. Pour que le serveur utilise le protocole HTTPS au lieu de HTTP, nous n'avons pas besoin de modifier le code du serveur. Cette fonctionnalité est activée dans les conteneurs de servlets, dont nous parlerons dans les articles suivants. C'est tout pour aujourd'hui. Cependant, attendez. Pour détecter les requêtes HTTP, ouvrez Google Chrome, appuyez sur F12, 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. Bases de Maven Partie 5. Servlets. Écrire une application Web simple Partie 6. Conteneurs de servlets Partie 7. Présentation du modèle MVC (Model-View-Controller) Partie 8. Écrire une petite application Spring-boot