Available inFrenchEnglishGermanHindiPortugueseRussianSpanish
HTTP et REST pour entretiens backend
Expliquez pourquoi un code de statut, un en-tête ou un attribut de cookie se comporte ainsi, et retrouvez la faute dans un échange cassé. Pour des développeurs backend qui ont livré des API REST sans jamais avoir dû les expliquer à l'oral. Quatre-vingt-huit cartes suivent une requête : le message, les méthodes, les statuts, le cache, les cookies et CORS, les arbitrages de REST, HTTP/2 et 3, puis les jetons de connexion ; les classes de vulnérabilités relèvent du paquet OWASP.
L'emplacement B porte le seul champ d'en-tête que toute requête HTTP/1.1 doit transporter. Nommez-le et dites à quoi il sert.
Host. Il nomme l'autorité visée par la requête, ce qui permet à une seule adresse de servir des dizaines de sites.
— La cible de la requête omet l'autorité : autre chose doit la fournir.
Source
RFC 9110 §7.2 : un client DOIT envoyer un champ Host dans une requête HTTP/1.1, et un serveur DOIT rejeter par 400 une requête qui en manque. L'hébergement mutualisé tient tout entier à ce champ. HTTP/2 et HTTP/3 le remplacent par le pseudo-en-tête :authority, qui porte exactement la même information. Un mot sur le vocabulaire, valable pour tout le paquet : on dit « en-tête » en français, mais le nom du champ ne se traduit jamais. Ce que vous tapez, dans le code comme sur le fil, c'est Host.