RFC du protocole HTTP : Définition des méthodes

L'ensemble des méthodes courantes d'HTTP/1.0 est défini ci-dessous. Bien que cet ensemble puisse être complété, il est précisé ici que des méthodes additionnelles implémentées par des clients ou serveurs distincts ne peuvent partager la même sémantique que si leur fonction est identique.

8.1 GET

La méthode GET signifie "récupérer" le contenu quel qu'il soit de la ressource (sous forme d'une entité) identifiée par l'URI-visée. Si l'URI-visée identifie un processus générant dynamiquement des données, ce sont les données produites qui sont renvoyées dans l'entité au lieu du source de l'exécutable appelé, sauf si ce texte lui-même est la sortie du processus.

La sémantique de la méthode GET introduit une notion conditionnelle si la requête inclue le champ d'en-tête If-Modified-Since. Une méthode GET conditionnelle ne récupère la ressource que si celle-ci a été modifiée depuis la date associée au champ If-Modified-Since, comme indiqué en Section 10.9. La méthode GET conditionnelle est utilisée pour réduire la charge du réseau en permettant à des ressources en cache d'être rafraîchies sans multiplier les requêtes ou transférer des données inutiles.

8.2 HEAD

La méthode HEAD est identique à la méthode GET, sauf qu'elle ne demande pas la transmission du corps d'entité de la ressource en retour. Seule les métainformations constituant l'en-tête HTTP de la ressource sont envoyées. Cette méthode permet de ne demander que les informations concernant la ressource (au sens d'HTTP). Elle est utilisée à des fins de tests d'hyperliens, vérification d'existence ou d'actualité d'une ressource.

Il n'existe pas de méthode HEAD conditionnelle comme pour la méthode GET. Si un champ d'en-tête If-Modified-Since est présent dans une requête HEAD, il devra être ignoré.

8.3 POST

La méthode POST est utilisée pour indiquer au serveur de soumettre l'entité contenue dans le message à la ressource identifiée par l'URI-visée. POST est destinée à fournir un moyen uniforme pour les opérations suivantes:

• Annotation de ressources existantes;
• Envoi d'un message vers une édition en ligne, un groupe de nouvelles, une liste d'adresse, ou listes similaires;
• Fournir un bloc de données, par exemple, un résultat de formulaire [3], à un processus de gestion de données;
• Ajout d'éléments à une base de données.

La fonction effective de la méthode POST est définie par le serveur et dépend de l'URI désignée. L'entité "postée" est subordonnée à cette URI dans le même sens qu'un fichier est subordonné au répertoire qui le contient, un article est subordonné au groupe de nouvelles à qui il a été posté, ou un enregistrement à une base de données.

La résolution d'une méthode POST ne signifie pas forcément la création d'une entité sur le serveur origine, ni une possibilité d'accès futur à ces informations. En d'autres termes, le résultat d'un POST n'est pas nécessairement une ressource associable à une URI. Dans ce cas, une réponse de code 200 (OK) ou 204 (pas de contenu) est la réponse la plus appropriée, suivant que la réponse contient ou non une entité pour décrire le résultat.

Si une ressource a été créée sur le serveur origine, la réponse sera du type 201 (créé) et contiendra l'entité (de préférence du type "text/html") qui décrira les informations sur la requête et contiendra une référence sur la nouvelle ressource.

Un champ Content-Length valide est demandé dans toute requête POST HTTP/1.0. Un serveur HTTP/1.0 répondra par un message 400 (requête incorrecte) s'il ne peut déterminer la longueur du contenu du message.

Les applications ne peuvent enregistrer en cache les réponses à des requêtes POST dans la mesure où il n'est absolument pas certain qu'une réponse ultérieure émise dans les mêmes conditions produise le même résultat.