Le protocole http

Quelques raccourcis :

Document en construction...

Le protocole http, pour Hypertext Transfer Protocol, est a priori fort simple. Reposant sur des commandes nommées verbes (p. ex. : , GET, POST), il vise à faciliter le transfert de fichiers entre un client et un serveur.

Idée de base

Le protocole http repose sur les fondations du couple TCP/IP, ce qui implique l'envoi de flux de données entre le client et le serveur.

Une trame http est composée d'un en-tête informatif et d'un corps contenant essentiellement le document transmis. L'en-tête d'une trame http indique quelques informations quant à la nature du document contenu dans le corps de la trame, incluant la taille en bytes de ce document. Le document peut être à peu près n'importe quoi, comme on peut le constater en furetant dans Internet.

De par sa simplicité, de par son ubiquité sur Internet, et parce qu'il sert essentiellement à transférer des documents, le protocole http sert fréquemment de support aux protocoles client/ serveur modernes. Ces protocoles profitent de l'ouverture reconnue à http et s'en servent comme protocole de transport en décrivant à la fois leurs requêtes et leurs réponses sous forme de documents XML ou JSON.

Caractéristique importante de http : il s'agit d'un protocole sans état (Stateless). C'est à la fois une des raisons de son succès et la source de divers maux de tête chez les gens développant des systèmes ou transactionnels reposant sur ce protocole. En effet, un protocole sans état ne présume pas que les homologues demeurent connectés l'un à l'autre entre deux échanges, et n'exige pas du code serveur qu'il maintienne une représentation de l'état de ses échanges avec son client. Cela implique qu'une trame http doit être pleinement autodescriptive. Le client est responsable de faire suivre, par exemple à travers les paramètres apposés à la fin de l'URL indiquant le lieu du serveur ou à partir de données sessions telles celles entreposées dans des témoins, la totalité des états pertinents à la description de l'état courant de ses échanges avec le serveur.

Le bon côté des protocoles sans état est qu'ils sont fortement échelonnables (il s'agit d'un néologisme mais c'est-ce que j'ai trouvé de mieux pour l'anglais Scalable). En effet, en laissant reposer le poids de la conservation des états transactionnels du côté client, les protocoles sans état permettent la conception de serveurs moins sujets à être écrasés en période de pointe par une masse trop importante de clients.

Les protocoles sans état facilitent aussi la mise en place de procédures pour remplacer dynamiquement un serveur déficient ou sujet à une période d'entretien : puisque chaque requête provenant d'un client est autonome et pleinement autodescriptive, il est possible de mettre en place un groupe de serveurs tels que les uns soient aussi qualifiés que les autres pour traiter n'importe quelle requête.

Verbes http

Une requête http débute par le type de commande, ou de méthode. Ces types de commandes sont mieux connus sous le nom de verbes.

Un verbe http est suivi d'une gamme de paramètres descriptifs (nom de domaine du serveur, version de http utilisée, document demandé dans le cas d'une requête GET, langue, etc.). Une réponse http débute par un code d'état, suivi d'un ensemble de données descriptives (langue, encodage, taille du corps du message, etc.).

Verbe http Rôle et sémantique
GET

Une requête GET permet à un client de demander à un serveur l'information correspondant à l'URI de la requête, URI susceptible d'être une URL suivie de paramètres. Cette information peut être un document existant ou généré par programmation.

L'en-tête d'une trame http pour une requête GET peut contenir de l'information ayant pour but de guider la réaction du serveur suite à l'analyse des paramètres (l'équivalent d'alternatives en fonction de la présence ou de l'absence de certains paramètres, par exemple).

D'un point de vue vitesse de réaction, les requêtes GET peuvent être placées en antémémoire dans le fureteur si certaines conditions sont respectées. D'un point de vue sécurité, le fait que les paramètres d'une requête GET apparaissent dans l'URI rend ce type de requête vulnérable à une interception par un tiers hostile.

Pour en savoir plus, mieux vaut consulter la documentation du protocole.

HEAD

Une requête HEAD est identique à une requête GET, mais signifie que le demandeur ne veut que l'en-tête de la réponse, pas le corps. C'est une manière allégée de s'enquérir d'informations de la part du serveur

POST

Une requête POST est le moyen privilégié de soumettre à un serveur des données potentiellement sensibles à partir d'un poste client. Les divers champs d'une requête POST sont imbriqués dans le contenu du message plutôt que dans l'URI de destination.

La plupart des clients n'entreposent pas les requêtes POST en antémémoire.

PUT

Une requête PUT vise à entreposer l'entité logée dans la requête à même l'URI. Ceci peut créer l'entité si elle n'existait pas au préalable, et la modifier si elle existait

DELETE

Une requête DELETE vise à détruire la ressource décrite par l'URI

TRACE

Une requête TRACE provoque un écho de la requête reçue par le serveur. Ceci permet en particulier de voir si des transformations ont été appliquées par des serveurs intermédiaires

OPTIONS

Une requête OPTIONS permet d'obtenir les verbes supportés pour une URI donnée

CONNECT

Une requête CONNECT permet de créer un tunnel TCP/IP, ce qui sert entre autres à établir une connexion https

PATCH

Une requête PATCH permet d'appliquer des modifications partielles à une ressource

Codes d'états

Le code d'état d'une requête http permet de comprendre le succès ou l'erreur de cette requête. Ces codes sont connus et documentés, du célèbre 404 (File not found) au 200 (Ok) en passant par plusieurs autres.

Les codes d'états sont groupés par familles, en fonction des rôles descriptifs qu'ils jouent :

Valeur Rôle Exemples
1xx

Code de nature nformative; la requête a été reçue et le processus se poursuit

101 Switching Protocols; le demandeur souhaite changer de protocole et le serveur a accepté)

2xx

Code de succès; la requête a été acceptée et comprise

200 OK

3xx

Code de redirection; d'autres actions sont requises pour compléter la requête

301 Moved Permanently; il faut envoyer les requêtes subséquentes à une nouvelle URI

4xx

Code d'erreur côté client; quelque chose cloche dans la demande

404 Not Found; le serveur ne trouve pas la ressource demandée

5xx

Code d'erreur côté serveur; la requête semble correcte mais le serveur a un ennui

503 Service Unavailable; le serveur est temporairement incapable de traiter la requête

La liste complète est disponible sur https://en.wikipedia.org/wiki/List_of_HTTP_status_codes

Lectures complémentaires

Quelques liens pour enrichir le propos.

À propos des verbes http :

À propos des codes d'états :

Programmer avec http :

À propos de http 2.0 :

Critiques :


Valid XHTML 1.0 Transitional

CSS Valide !