II. Les Requêtes HTTP▲
Dès que le client est connecté au serveur, il envoie sa requête.
C'est en ce sens que l'échange est initié par le client.
Nous allons voir les spécificités des requêtes HTTP.
II-A. La ligne d'Introduction▲
Comme précisé auparavant, le seul point qui change catégoriquement entre requête et réponse HTTP, c'est cette Ligne d'Introduction. Voici la forme qu'elle a pour une requête :
{Méthode}{SP}{Page}{SP}{Version}
Le séparateur SP correspond à l'espace.
La Méthode▲
- GET
- HEAD
- POST
- PUT
- DELETE
- OPTIONS
- TRACE
- CONNECT
On parle aussi parfois de type de requêtes.
Les Méthodes autres que GET et POST sont propres à la version 1.1 de HTTP.
Ces méthodes seront détaillées un peu plus loin.
La Page▲
Le spécificateur Page désigne le chemin vers la ressource chargée de traiter, ou de correspondre à la requête à partir de la racine du site.
Il doit commencer par un slash (/) et la chaîne doit être URL-Encodée.
- Les paramètres d'URL (paramètres GET)
- L'identificateur de fragment (fragment identifier)
Les paramètres d'URL sont indiqués avec cette syntaxe :
{Nom}{EQ}{Valeur}
Le Nom et la Valeur sont URL-Encodés.
Forcément, il n'y a pas d'espace.
Le séparateur EQ correspond au caractère égal.
Chaque paramètre est séparé du suivant par un esperluette.
La chaîne ainsi formée est placée à la suite du chemin, le tout étant séparé par un point d'interrogation.
Le fragment identifier permet de désigner une partie précise du document.
Il n'a pour le moment que peu (voire pas) de signification pour le serveur, car il est surtout utile au client.
Par exemple, c'est lui qui est utilisé pour désigner une ancre dans un document HTML.
Le langage XPointer est prévu pour être notamment utilisé dans le fragment identifier.
Il doit également être URL-Encodé. Il est ajouté à la suite des paramètres d'URL (ou du chemin s'il n'y a pas de paramètre d'URL) et il en est séparé par un dièse.
La Version▲
- HTTP/1.0 pour la version 1.0
- HTTP/1.1 pour la version 1.1
Les Méthodes▲
Nous allons maintenant voir un peu plus en détail les 4 méthodes proposées par la version 1.1 du protocole HTTP. Les informations sur les méthodes GET et POST sont également valables pour la version 1.0.
- GET
Cette méthode est la plus courante, il s'agit normalement d'une simple requête de téléchargement d'un document. Deux requêtes GET portant sur le même document devraient retourner des réponses sémantiquement identiques (certaines en-têtes pouvant influer sur le comportement du serveur, les réponses peuvent ne pas être totalement identiques).
Aucune donnée à traiter ne peut être envoyée au serveur par cette méthode. Il est par contre possible d'ajouter les paramètres d'URL (aussi nommés paramètres GET). Le corps de la requête DOIT être vide, et le document spécifié dans la requête (la Page) est celui qui doit être retourné. - HEAD
Cette méthode est similaire et presque équivalente à la méthode GET. C'est en fait la réponse finale du serveur qui est tronquée.
La réponse à une requête HEAD est la réponse à la requête GET qui lui est similaire, sauf que le corps de la réponse HTTP n'est pas transmis. Cela permet souvent d'économiser beaucoup de bande passante. - POST
La Méthode POST est la méthode de base pour demander un traitement d'informations au serveur. Ces requêtes sont censées mettre en jeu des mécanismes propres au serveur et provoquant des communications avec d'autres modules, voire d'autres serveurs, pour effectuer le traitement des dites données. De ce fait, il est tout à fait probable que deux requêtes POST identiques reçoivent des réponses différentes ou même sémantiquement opposées.
Les données à traiter sont spécifiées dans le corps de la requête.
Le document désigné par la requête via la page est la ressource qui doit traiter les données et générer la réponse. - PUT et DELETE
Ces méthodes sont censées permettre l'upload (le chargement sur le serveur) ou la suppression d'un document sans passer par un serveur FTP ou autre. Bien évidemment, cela peut provoquer des remplacements de fichiers, et donc de très grosses failles de sécurités sur un serveur. De ce fait, la plupart des serveur Webs requierent une configuration spéciale indiquant une ressource ou un document chargé de traiter ces requêtes.
Le document désigné par la requête est celui qui doit être remplacé (ou créé), et le contenu du document est dans le corps de la requête.
En théorie, les paramètres d'URL et le fragment identifier devraient être interdits ou ignorés par le serveur. En pratique, ils sont généralement transmis à la ressource chargée de traiter la requête. - OPTIONS et TRACE
Ces méthodes permettent au client de demander certaines informations sur le serveur.
Tous les serveurs ne les implémentent pas forcément. - CONNECT
Cette méthode est censée être utilisée pour demander une utilisation du serveur en tant que proxy.
Tous les serveurs ne les implémentent pas forcément.
II-B. Les en-têtes de requête▲
Nous allons ici présenter certaines en-têtes utilisées dans les requêtes HTTP. Elles ne sont pas forcément spécifiques aux requêtes, mais ont une signification particulière dans le cadre d'une requête.
- Host
Cette en-tête est la seule obligatoire pour les requêtes HTTP/1.1, c'est elle qui permet d'héberger plusieurs sites Web sur un même serveur.
Sa valeur est le domaine du site Web. Elle est généralement spécifiée juste après la Ligne d'Introduction. - User-Agent
Cette en-tête permet d'indiquer la signature du programme effectuant la requête. C'est une chaîne de caractères qui permet d'identifier le programme. En général, il s'agit du nom complet du programme et de sa version. - Content-type et Content-length
Ces deux en-têtes ne peuvent être spécifiées que dans le cadre d'une requête POST ou PUT. Elles indiquent respectivement le type MIME et la taille en octets du corps de la requête. Si elles ne sont pas spécifiées, c'est le serveur qui est seul responsable de leur éventuelle valeur par défaut. - Cookie
Cette en-tête permet au client de fournir un cookie au serveur.
Sa valeur est simplement le nom et la valeur du cookie, séparés par un égal. - D'autres en-têtes
De nombreuses autres en-têtes ont été prévues dans le protocole HTTP. Elles servent par exemple à préciser la gestion du cache, la langue ou le format préféré pour la réponse, l'authentification du client, etc. Les Requests For Comments (RFC) du protocole HTTP vous fourniront toutes les en-têtes [pour ses versions 1.0 et 1.1]. Toute en-tête non reconnue par le serveur doit théoriquement être ignorée.
II-C. Le corps de la requête▲
Le corps de la requête doit être vide pour les requêtes GET, HEAD, DELETE, CONNECT, TRACE et OPTIONS (dans le dernier cas, il est laissé éventuellement rempli pour de futures versions du protocole HTTP).
Dans le cas des requêtes POST et PUT, il correspond aux données à traiter.
Il n'y a pas de caractères réservés ou interdits dans le corps de la requête au niveau du protocole HTTP.
Cependant, les données doivent être conformes au format attendu par la ressource responsable de leur traitement.