L’ensemble des méthodes communes pour HTTP/1.1 est défini ci-dessous. Bien que cet ensemble puisse être étendu, des méthodes supplémentaires ne peuvent être supposées partager la même sémantique pour des clients et serveurs ayant des extensions distinctes.
Le champ d’en-tête de demande Host (paragraphe 14.23) DOIT accompagner toutes les demandes HTTP/1.1.
9.1 Méthodes sûres et idempotentes
9.1.1 Méthodes sûres
Les développeurs devraient avoir conscience que le logiciel représente l’utilisateur dans ses interactions sur l’Internet, et ils devraient veiller à permettre à l’usager d’être au courant de toute action qui pourrait avoir une signification inattendue pour lui-même ou pour les autres.
En particulier, il a été établi une convention par laquelle les méthodes GET et HEAD NE DEVRAIENT PAS signifier d’entreprendre une autre action que la restauration. Ces méthodes devraient être considérées comme
"sûres". Ceci permet aux agents d’utilisateur de représenter d’autres méthodes, telles que POST, PUT et DELETE, d’une façon particulière, de sorte que l’usager soit au courant du fait qu’il est possible qu’une action non sûre soit demandée.
Naturellement, il n’est pas possible de garantir que le serveur ne génère pas des effets collatéraux suite à l’exécution d’une demande GET ; en fait, certaines ressources dynamiques considèrent cela comme une caractéristique. La distinction important ici est que l’usager n’a pas demandé les effets collatéraux, et ne peut donc en être tenu pour responsable.
9.1.2 Méthodes idempotentes
Les méthodes peuvent aussi avoir la propriété d’"idempotence" en ce que (à part les questions d’erreur ou d’expiration) les effets collatéraux de N > 0 demandes sont les mêmes que pour une seule demande. Les méthodes GET, HEAD, PUT et DELETE partagent cette propriété. Aussi, les méthodes OPTIONS et TRACE NE DEVRAIENT PAS avoir d’effets collatéraux, et sont dont par nature idempotentes.
Cependant, il est possible qu’une séquence de plusieurs demandes soit non idempotente, même si toutes les méthodes exécutées dans cette séquence sont idempotentes. (Une séquence est idempotente si une seule exécution de la séquence entière donne toujours un résultat qui n’est pas changé par une réexécution de tout, ou partie, de cette séquence.) Par exemple, une séquence est non idempotente si son résultat dépend d’une valeur qui est modifiée ultérieurement dans la même séquence.
Une séquence qui n’a jamais d’effets collatéraux est idempotente, par définition (pourvu qu’aucune opération concurrente ne soit exécutée sur le même ensemble de ressources).
9.2 OPTIONS
La méthode OPTIONS représente une demande d’informations sur les options de communication disponibles sur la chaîne des demandes/réponses identifiées par l’URI de demande. Cette méthode permet au client de déterminer les options et/ou exigences associées à une ressource, ou les capacités d’un serveur, sans impliquer une action de ressource ou sans initier de restitution de ressource.
Les réponses à cette méthode ne peuvent pas être mises en antémémoire.
Si la demande OPTIONS inclut un corps d’entité (comme indiqué par la présence de Content-Length ou Transfer-Encoding) le type de support DOIT être indiqué par un champ Content-Type. Bien que la présente spécification ne définisse pas l’utilisation d’un tel corps, des extensions futures à HTTP pourraient utiliser les corps OPTIONS pour faire des questions plus précises au serveur. Un serveur qui ne prend pas en charge une telle extension PEUT éliminer le corps de la demande.
Si l’URI de demande est un astérisque ("*") la demande OPTIONS est destinée à s’appliquer au serveur en général plutôt qu’à une ressource spécifique. Comme les options de communication d’un serveur dépendent normalement de la ressource, la demande "*" n’est utile que comme type de méthode "ping" ou "no-op" ; elle ne fait rien de plus que permettre au client de tester les capacités du serveur. Par exemple, cela peut être utilisé pour tester la conformité d’un mandataire à HTTP/1.1 (ou son manque de conformité).
Si l’URI de demande n’est pas un astérisque, la demande OPTIONS ne s’applique qu’aux options qui sont disponibles lors de la communication avec cette ressource.
Une réponse 200 DEVRAIT inclure tous les champs d’en-tête qui indiquent des caractéristiques facultatives mises en œuvre par le serveur et applicables à cette ressource (par exemple, Allow), incluant éventuellement des extensions non définies par la présente spécification. Le corps de réponse, s’il en est, DEVRAIT aussi inclure des informations sur les options de communication. Le format d’un tel corps n’est pas défini par la présente spécification, mais pourrait être défini par des extensions futures à HTTP. La négociation de contenu PEUT être utilisée pour choisir le format de réponse approprié. Si aucun corps de réponse n’est inclus, la réponse DOIT inclure un champ Content-Length d’une valeur de champ de "0".
Le champ d’en-tête de demande Max-Forwards PEUT être utilisé pour cibler un mandataire spécifique dans la chaîne de demande. Lorsqu’un mandataire reçoit une demande OPTIONS sur un URI absolu pour lequel la transmission de la demande est permise, le mandataire DOIT vérifier qu’il y a un champ Max-Forwards. Si la valeur du champ Max-Forwards est zéro ("0"), le mandataire NE DOIT PAS transmettre le message ; au lieu de cela, le mandataire DEVRAIT répondre par ses propres options de communication. Si la valeur du champ Max-Forwards est un entier supérieur à zéro, le mandataire DOIT décrémenter la valeur du champ lorsqu’il transmet la demande. Si aucun champ Max-Forwards n’est présent dans la demande, la demande transmise NE DOIT PAS alors inclure de champ Max-Forwards.
9.3 GET
La méthode GET signifie la restitution de toute information (sous forme d’une entité) qui est identifiée par l’URI de demande. Si l’URI de demande se réfère à un processus de production de données, ce sont les données produites qui devront être retournées comme entité dans la réponse et non le texte source du processus, sauf si ce texte se trouve être le résultat du processus.
La sémantique de la méthode GET se change en un "GET conditionnel" si le message de demande inclut un champ d’en-tête If-Modified-Since, If-Unmodified-Since, If-Match, If-None-Match, ou If-Range. Une méthode GET conditionnelle demande que l’entité ne soit transférée que dans les circonstances décrites par le ou les champs d’en-tête conditionnels. La méthode GET conditionnelle est destinée à réduire les utilisations non indispensables du réseau en permettant aux entités en antémémoire d’être rafraîchies sans requérir plusieurs demandes ou sans transférer des données déjà détenues par le client.
La sémantique de la méthode GET se change en "GET partiel" si le message de demande inclut un champ d’en-tête Range. Un GET partiel demande que seule une partie de l’entité soit transférée, comme décrit au paragraphe 14.35. La méthode GET partiel est destinée à réduire l’utilisation non indispensable du réseau en permettant que les entités partiellement restituées soient complétées sans transférer des données déjà détenues par le client.
La réponse à une demande GET peut être mise en antémémoire si et seulement si elle satisfait aux exigences de mise en antémémoire pour HTTP décrites dans la section 13.
Voir au paragraphe 15.1.3 les considérations de sécurité lorsque elle est utilisée pour les formes.
9.4 HEAD
La méthode HEAD est identique à GET sauf que le serveur NE DOIT PAS retourner un corps de message dans la réponse. Les méta-informations contenues dans les en-têtes HTTP en réponse à une demande HEAD DEVRAIENT être identiques aux informations envoyées en réponse à une demande GET. Cette méthode peut être utilisée pour obtenir des méta-informations sur l'entité impliquée par la demande sans transférer le corps de l'entité lui-même. Cette méthode est souvent utilisée pour tester la validité, l'accessibilité et les modifications récentes, des liens hypertextes.
La réponse à une demande HEAD PEUT être mise en antémémoire dans le sens où les informations contenues dans la réponse PEUVENT être utilisées pour mettre à jour une entité précédemment mise en antémémoire depuis cette ressource. Si la nouvelle valeur de champ indique que l'entité d'antémémoire diffère de l'entité en cours (comme il devrait être indiqué par un changement dans Content-Length, Content-MD5, ETag ou Last-Modified) l'antémémoire DOIT alors traiter l'entrée d'antémémoire comme périmée.
9.5 POST
La méthode POST est utilisée pour demander que le serveur d’origine accepte l'entité incluse dans la demande comme un nouveau subordonné de la ressource identifiée par l'URI de demande dans la ligne de demande.
POST est conçu pour permettre à une méthode uniforme de couvrir les fonctions suivantes : – Annotation des ressources existantes ;
– Postage d'un message dans un bulletin, des nouvelles de groupe, une liste de diffusion, ou groupe d'articles similaires ;
– Fournir un bloc de données, tel que le résultat de la soumission d'un formulaire, à un processus de traitement de données ;
– Étendre une base de données à travers une opération d'ajout.
La fonction réelle effectuée par la méthode POST est déterminée par le serveur et dépend habituellement de l'URI de demande. L'entité postée est subordonnée à cet URI de la même façon qu'un fichier est subordonné à un répertoire qui le contient, qu'un article est subordonné à un groupe de nouvelles auquel il est aposté, ou qu'un enregistrement est subordonné à une base de données.
L'action effectuée par la méthode POST pourrait ne pas résulter en une ressource qui peut être identifiée par un URI. Dans ce cas, 200 (OK) ou 204 (Pas de contenu) est l'état de réponse approprié, selon que la réponse inclut ou non une entité décrivant le résultat.
Si une ressource a été créée sur le serveur d’origine, la réponse DEVRAIT être 201 (Créé) et contenir une entité qui décrive l'état de la demande et se réfère à la nouvelle ressource, et un en-tête de localisation (voir au paragraphe 14.30).
Les réponses à cette méthode ne peuvent pas être mises en antémémoire, sauf si la réponse inclut les champs d’en-tête Cache-Control ou Expires appropriés. Cependant, la réponse 303 (Voir autres) peut être utilisée pour diriger l'agent d’utilisateur sur la restitution d'une ressource mettable en antémémoire.
Les demandes POST DOIVENT obéir aux exigences de transmission de message établies au paragraphe 8.2.
Voir au paragraphe 15.1.3 les considérations sur la sécurité.
9.6 PUT
La méthode PUT demande que l'entité incluse soit mémorisée sous l'URI de demande. Si l'URI de demande se réfère à une ressource déjà existante, l'entité incluse DEVRAIT être considérée comme une version modifiée de celle qui réside sur le serveur d’origine. Si l'URI de demande ne pointe pas sur une ressource existante, et si l'URI est capable d'être défini comme nouvelle ressource par l'agent d’utilisateur demandeur, le serveur d’origine peut créer la ressource avec cet URI. Si une nouvelle ressource est créée, le serveur d’origine DOIT informer l'agent d’utilisateur via la réponse 201 (Créé). Si une ressource existante est modifiée, les codes de réponse 200 (OK) ou 204 (Pas de contenu) DEVRAIENT être envoyés pour indiquer l'achèvement réussi de la demande. Si la ressource n'a pas pu être créée ou modifiée par l'URI de demande, une réponse d'erreur appropriée DEVRAIT être donnée, reflétant la nature du problème. Le receveur de l'entité NE DOIT PAS ignorer un en-tête Content-* (par exemple Content-Range) qu'il ne comprend ou ne met pas en œuvre et DOIT retourner une réponse 501 (Non mis en œuvre) dans de tels cas.
Si la demande passe à travers une antémémoire et si l'URI de demande identifie une ou plusieurs entités actuellement en antémémoire , ces entrées DEVRAIENT être traitées comme périmées. Il n'est pas possible de mettre les réponses à cette méthode en antémémoire.
La différence fondamentale entre les demandes POST et PUT est réfléchie par les significations différentes des URI de demande. L'URI dans une demande POST identifie la ressource qui va traiter l'entité incluse. Cette ressource pourrait être un processus acceptant les données, une passerelle vers un autre protocole, ou une entité distincte qui accepte les annotations. À l'inverse, l'URI dans une demande PUT identifie l'entité incluse dans la demande -- l'agent d’utilisateur sait quel URI est prévu et le serveur NE DOIT PAS essayer d'appliquer la demande à une autre ressource. Si le serveur désire que la demande soit appliquée à un URI différent, il DOIT envoyer une réponse 301 (Déplacement permanent) ; l'agent d’utilisateur PEUT alors prendre sa propre décision pour savoir s'il doit ou non rediriger la demande.
Une seule ressource PEUT être identifiée par de nombreux URI différents. Par exemple, un article peut avoir un
URI pour identifier "la version en cours" qui est différent de l'URI identifiant chaque version particulière. Dans ce cas, une demande PUT sur un URI général pourrait résulter en ce que plusieurs autres URI soient définis par le serveur d’origine.
HTTP/1.1 ne définit pas comment une méthode PUT affecte l'état d'un serveur d’origine.
Les demandes PUT DOIVENT obéir aux exigences de transmission de message établies au paragraphe 8.2.
Sauf spécification contraire pour un en-tête d'entité particulier, les en-têtes d'entité dans la demande PUT DEVRAIENT être appliqués aux ressources créées ou modifiées par le PUT.
9.7 DELETE
La méthode DELETE demande que le serveur d’origine supprime la ressource identifiée par l'URI de demande.
Cette méthode PEUT être outrepassée par une intervention humaine (ou autre moyen) sur le serveur d’origine.
Le client ne peut pas avoir la garantie que l'opération a été effectuée, même si le code d'état retourné par le serveur d’origine indique que l'action a été menée à bien. Cependant, le serveur NE DEVRAIT indiquer le succès que si, au moment où la réponse est donnée, il a l'intention de supprimer la ressource ou de la déplacer dans une localisation inaccessible.
Une réponse de succès DEVRAIT être 200 (OK) si la réponse inclut une entité décrivant l'état, 202 (Accepté) si l'action n'a pas encore été représentée, ou 204 (Pas de contenu) si l'action a été exécutée mais si la réponse n'incluait pas d'entité.
Si la demande passe à travers une antémémoire et que l'URI de demande identifie une ou plusieurs entités actuellement en antémémoire, ces entrées DEVRAIENT être traitées comme périmées. Les réponses à cette méthode ne sont pas susceptibles d'être mises en antémémoire
9.8 TRACE
La méthode TRACE est utilisée pour invoquer un bouclage distant, de couche application du message de demande. Le receveur final de la demande DEVRAIT refléter le message reçu en retour par le client comme corps d'entité d'une réponse 200 (OK). Le receveur final est le serveur d’origine ou le premier mandataire ou passerelle à recevoir une valeur Max-Forwards de zéro (0) dans la demande (voir au paragraphe 14.31). Une demande TRACE NE DOIT PAS inclure une entité.
TRACE permet au client de voir ce qui va être reçu de l'autre côté de la chaîne de demande et d'utiliser ces données pour tester ou diagnostiquer les informations. La valeur du champ d’en-tête Via (paragraphe 14.45) est d'un intérêt particulier, car elle agit comme une trace de la chaîne de demande. L'utilisation du champ d'en-tête Max-Forwards permet au client de limiter la longueur de la chaîne de demande, ce qui est utile pour tester une chaîne de mandataires qui transmettent des messages dans une boucle infinie.
Si la demande est valide, la réponse DEVRAIT contenir le message de demande entier dans le corps d'entité, avec un Content-Type de "message/http". Les réponses à cette méthode NE DOIVENT PAS être mises en antémémoire.
9.9 CONNECT
La présente spécification réserve le nom de méthode CONNECT à l'utilisation avec un mandataire qui peut passer de façon dynamique à la fonction de tunnel (par exemple, tunnelage SSL [44]).