9. Méthodes (Methods)

9.1. Vue d'Ensemble (Overview)

Le jeton de méthode de requête est la source principale de la sémantique de la requête ; il indique le but pour lequel le client a fait cette requête et ce qui est attendu par le client comme résultat réussi.

La sémantique de la méthode de requête peut être davantage spécialisée par la sémantique de certains champs d'en-tête lorsqu'ils sont présents dans une requête, si cette sémantique supplémentaire n'entre pas en conflit avec la méthode. Par exemple, un client peut envoyer des champs d'en-tête de requête conditionnelle (Section 13.1) pour rendre l'action demandée conditionnelle à l'état actuel de la ressource cible.

HTTP est conçu pour être utilisable comme interface vers des systèmes d'objets distribués. La méthode de requête invoque une action à appliquer à une ressource cible de la même manière qu'une invocation de méthode distante peut être envoyée à un objet identifié.

method = token

Le jeton de méthode est sensible à la casse car il peut être utilisé comme passerelle vers des systèmes basés sur des objets avec des noms de méthode sensibles à la casse. Par convention, les méthodes standardisées sont définies en lettres ASCII majuscules US.

Contrairement aux objets distribués, les méthodes de requête standardisées dans HTTP ne sont pas spécifiques aux ressources, car les interfaces uniformes offrent une meilleure visibilité et réutilisabilité dans les systèmes basés sur le réseau [REST]. Une fois définie, une méthode standardisée devrait avoir la même sémantique lorsqu'elle est appliquée à n'importe quelle ressource, bien que chaque ressource détermine elle-même si cette sémantique est implémentée ou autorisée.

Cette spécification définit un certain nombre de méthodes standardisées couramment utilisées dans HTTP, comme indiqué dans le tableau suivant.

Nom de Méthode	Description	Section
GET	Transférer une représentation actuelle de la ressource cible.	9.3.1
HEAD	Identique à GET, mais ne pas transférer le contenu de la réponse.	9.3.2
POST	Effectuer un traitement spécifique à la ressource sur le contenu de la requête.	9.3.3
PUT	Remplacer toutes les représentations actuelles de la ressource cible par le contenu de la requête.	9.3.4
DELETE	Supprimer toutes les représentations actuelles de la ressource cible.	9.3.5
CONNECT	Établir un tunnel vers le serveur identifié par la ressource cible.	9.3.6
OPTIONS	Décrire les options de communication pour la ressource cible.	9.3.7
TRACE	Effectuer un test de bouclage de message le long du chemin vers la ressource cible.	9.3.8

Tous les serveurs à usage général DOIVENT (MUST) prendre en charge les méthodes GET et HEAD. Toutes les autres méthodes sont OPTIONNELLES (OPTIONAL).

L'ensemble des méthodes autorisées par une ressource cible peut être répertorié dans un champ d'en-tête Allow (Section 10.2.1). Cependant, l'ensemble des méthodes autorisées peut changer dynamiquement. Un serveur d'origine qui reçoit une méthode de requête non reconnue ou non implémentée DEVRAIT (SHOULD) répondre avec le code d'état 501 (Not Implemented). Un serveur d'origine qui reçoit une méthode de requête reconnue et implémentée, mais non autorisée pour la ressource cible, DEVRAIT (SHOULD) répondre avec le code d'état 405 (Method Not Allowed).

Des méthodes supplémentaires, en dehors du champ d'application de cette spécification, ont été spécifiées pour une utilisation dans HTTP. Toutes ces méthodes devraient être enregistrées dans le « Registre des Méthodes du Protocole de Transfert Hypertexte (HTTP) », comme décrit dans la Section 16.1.

9.2. Propriétés Communes des Méthodes (Common Method Properties)

9.2.1. Méthodes Sûres (Safe Methods)

Les méthodes de requête sont considérées comme « sûres » si leur sémantique définie est essentiellement en lecture seule ; c'est-à-dire que le client ne demande pas et ne s'attend pas à ce qu'un changement d'état se produise sur le serveur d'origine suite à l'application d'une méthode sûre à une ressource cible. De même, l'utilisation raisonnable d'une méthode sûre ne devrait pas causer de dommage, de perte de propriété ou de charge inhabituelle sur le serveur d'origine.

Cette définition des méthodes sûres n'empêche pas une implémentation d'inclure un comportement potentiellement dangereux, qui n'est pas entièrement en lecture seule, ou qui provoque des effets secondaires lors de l'invocation d'une méthode sûre. Ce qui est important, cependant, c'est que le client n'a pas demandé ce comportement supplémentaire et ne peut en être tenu responsable. Par exemple, la plupart des serveurs ajoutent des informations de requête aux fichiers journaux d'accès à la fin de chaque réponse, quelle que soit la méthode, et cela est considéré comme sûr même si le stockage du journal peut se remplir et provoquer la défaillance du serveur. De même, une requête sûre initiée en sélectionnant une publicité sur le Web aura souvent l'effet secondaire de facturer un compte publicitaire.

Parmi les méthodes de requête définies par cette spécification, les méthodes GET, HEAD, OPTIONS et TRACE sont définies comme étant sûres.

Le but de la distinction entre méthodes sûres et non sûres est de permettre aux processus de récupération automatisés (araignées) et à l'optimisation des performances du cache (pré-chargement) de fonctionner sans crainte de causer des dommages. De plus, cela permet à un agent utilisateur d'appliquer des contraintes appropriées sur l'utilisation automatisée de méthodes non sûres lors du traitement de contenu potentiellement non fiable.

Un agent utilisateur DEVRAIT (SHOULD) distinguer les méthodes sûres des méthodes non sûres lors de la présentation d'actions potentielles à un utilisateur, de sorte que l'utilisateur puisse être informé d'une action non sûre avant qu'elle ne soit demandée.

Lorsqu'une ressource est construite de telle sorte que les paramètres dans l'URI cible ont pour effet de sélectionner une action, il est de la responsabilité du propriétaire de la ressource de s'assurer que l'action est cohérente avec la sémantique de la méthode de requête. Par exemple, il est courant pour les logiciels d'édition de contenu basés sur le Web d'utiliser des actions dans les paramètres de requête, telles que « page?do=delete ». Si le but d'une telle ressource est d'effectuer une action non sûre, alors le propriétaire de la ressource DOIT (MUST) désactiver ou interdire cette action lorsqu'elle est accédée en utilisant une méthode de requête sûre. Ne pas le faire entraînera des effets secondaires malheureux lorsque les processus automatisés effectuent un GET sur chaque référence URI dans le but de maintenir les liens, de pré-charger, de construire un index de recherche, etc.

9.2.2. Méthodes Idempotentes (Idempotent Methods)

Une méthode de requête est considérée comme « idempotente » si l'effet prévu sur le serveur de plusieurs requêtes identiques avec cette méthode est le même que l'effet d'une seule telle requête. Parmi les méthodes de requête définies par cette spécification, PUT, DELETE et les méthodes de requête sûres sont idempotentes.

Comme la définition de sûr, la propriété idempotente ne s'applique qu'à ce qui a été demandé par l'utilisateur ; un serveur est libre d'enregistrer chaque requête séparément, de conserver un historique de contrôle de révision, ou d'implémenter d'autres effets secondaires non idempotents pour chaque requête idempotente.

Les méthodes idempotentes se distinguent car la requête peut être répétée automatiquement si une défaillance de communication se produit avant que le client ne soit capable de lire la réponse du serveur. Par exemple, si un client envoie une requête PUT et que la connexion sous-jacente est fermée avant qu'une réponse ne soit reçue, alors le client peut établir une nouvelle connexion et réessayer la requête idempotente. Il sait que répéter la requête aura le même effet prévu, même si la requête originale a réussi, bien que la réponse puisse différer.

Un client NE DEVRAIT PAS (SHOULD NOT) réessayer automatiquement une requête avec une méthode non idempotente à moins qu'il n'ait un moyen de savoir que la sémantique de la requête est en fait idempotente, quelle que soit la méthode, ou un moyen de détecter que la requête originale n'a jamais été appliquée.

Par exemple, un agent utilisateur peut répéter automatiquement une requête POST s'il sait (par conception ou configuration) que la requête est sûre pour cette ressource. De même, un agent utilisateur conçu spécifiquement pour fonctionner sur un référentiel de contrôle de version pourrait être capable de récupérer d'états de défaillance partielle en vérifiant la (les) révision(s) de la ressource cible après une connexion échouée, en annulant ou en corrigeant les modifications qui ont été partiellement appliquées, puis en réessayant automatiquement les requêtes qui ont échoué.

Certains clients adoptent une approche plus risquée et tentent de deviner quand une nouvelle tentative automatique est possible. Par exemple, un client pourrait réessayer automatiquement une requête POST si la connexion de transport sous-jacente s'est fermée avant qu'une partie de la réponse ne soit reçue, particulièrement si une connexion persistante inactive a été utilisée.

Un proxy NE DOIT PAS (MUST NOT) réessayer automatiquement les requêtes non idempotentes. Un client NE DEVRAIT PAS (SHOULD NOT) réessayer automatiquement une nouvelle tentative automatique échouée.

9.2.3. Méthodes et Mise en Cache (Methods and Caching)

Pour qu'un cache puisse stocker et utiliser une réponse, la méthode associée doit explicitement autoriser la mise en cache et détailler dans quelles conditions une réponse peut être utilisée pour satisfaire des requêtes ultérieures ; une définition de méthode qui ne le fait pas ne peut pas être mise en cache. Pour les exigences supplémentaires, voir [CACHING].

Cette spécification définit la sémantique de mise en cache pour GET, HEAD et POST, bien que l'écrasante majorité des implémentations de cache ne prennent en charge que GET et HEAD.

9.3. Définitions des Méthodes (Method Definitions)

9.3.1. GET

La méthode GET demande le transfert d'une représentation actuellement sélectionnée pour la ressource cible. Une réponse réussie reflète la qualité de « similitude » identifiée par l'URI cible (Section 1.2.2 de [URI]). Par conséquent, la récupération d'informations identifiables via HTTP est généralement effectuée en faisant une requête GET sur un identifiant associé au potentiel de fournir ces informations dans une réponse 200 (OK).

GET est le mécanisme principal de récupération d'informations et le centre de presque toutes les optimisations de performances. Les applications qui génèrent un URI pour chaque ressource importante peuvent bénéficier de ces optimisations tout en permettant leur réutilisation par d'autres applications, créant un effet de réseau qui favorise l'expansion ultérieure du Web.

Il est tentant de considérer les identifiants de ressources comme des noms de chemins de système de fichiers distants et les représentations comme étant une copie du contenu de ces fichiers. En fait, c'est ainsi que de nombreuses ressources sont implémentées (voir Section 17.3 pour les considérations de sécurité connexes). Cependant, il n'y a pas de telles limitations en pratique.

L'interface HTTP d'une ressource est tout aussi susceptible d'être implémentée comme un arbre d'objets de contenu, une vue programmatique de divers enregistrements de base de données, ou une passerelle vers d'autres systèmes d'information. Même lorsque le mécanisme de mappage URI est lié à un système de fichiers, un serveur d'origine peut être configuré pour exécuter le fichier avec la requête comme entrée et envoyer la sortie comme représentation, plutôt que de transférer directement le fichier. Quoi qu'il en soit, seul le serveur d'origine a besoin de savoir comment chacun de ses identifiants de ressources correspond à une implémentation et comment cette implémentation parvient à sélectionner et à envoyer une représentation actuelle de la ressource cible.

Un client peut modifier la sémantique de GET pour en faire une « requête de plage », ne demandant le transfert que de certaines parties de la représentation sélectionnée, en envoyant un champ d'en-tête Range dans la requête (Section 14.2).

Bien que le tramage du message de requête soit indépendant de la méthode utilisée, le contenu reçu dans une requête GET n'a pas de sémantique généralement définie, ne peut pas modifier la signification ou la cible de la requête, et peut conduire certaines implémentations à rejeter la requête et à fermer la connexion en raison de son potentiel en tant qu'attaque de contrebande de requêtes (Section 11.2 de [HTTP/1.1]). Un client NE DEVRAIT PAS (SHOULD NOT) générer de contenu dans une requête GET à moins qu'elle ne soit faite directement à un serveur d'origine qui a précédemment indiqué, dans la bande ou hors bande, qu'une telle requête a un but et sera adéquatement prise en charge. Un serveur d'origine NE DEVRAIT PAS (SHOULD NOT) s'appuyer sur des accords privés pour recevoir du contenu, car les participants à la communication HTTP ne sont souvent pas conscients des intermédiaires sur la chaîne de requêtes.

La réponse à une requête GET est cacheable ; un cache PEUT (MAY) l'utiliser pour satisfaire les requêtes GET et HEAD ultérieures, sauf indication contraire du champ d'en-tête Cache-Control (Section 5.2 de [CACHING]).

Lorsque la récupération d'informations est effectuée avec un mécanisme qui construit un URI cible à partir d'informations fournies par l'utilisateur, telles que les champs de requête d'un formulaire utilisant GET, des données potentiellement sensibles pourraient être fournies qui ne seraient pas appropriées pour la divulgation dans un URI (voir Section 17.9). Dans certains cas, les données peuvent être filtrées ou transformées de sorte qu'elles ne révèlent pas de telles informations. Dans d'autres cas, en particulier lorsqu'il n'y a aucun avantage à mettre en cache une réponse, l'utilisation de la méthode POST (Section 9.3.3) au lieu de GET peut transmettre ces informations dans le contenu de la requête plutôt que dans l'URI cible.

9.3.2. HEAD

La méthode HEAD est identique à GET, sauf que le serveur NE DOIT PAS (MUST NOT) envoyer de contenu dans la réponse. HEAD est utilisée pour obtenir des métadonnées sur la représentation sélectionnée sans transférer ses données de représentation, souvent dans le but de tester des liens hypertextes ou de trouver des modifications récentes.

Le serveur DEVRAIT (SHOULD) envoyer les mêmes champs d'en-tête en réponse à une requête HEAD qu'il aurait envoyés en réponse à une requête GET. Cependant, un serveur PEUT (MAY) omettre les champs d'en-tête pour lesquels une valeur n'est déterminée que lors de la génération du contenu. Par exemple, certains serveurs mettent en mémoire tampon une réponse dynamique à GET jusqu'à ce qu'une quantité minimale de données soit générée afin de pouvoir délimiter plus efficacement les petites réponses ou prendre des décisions tardives concernant la sélection du contenu. Une telle réponse à GET pourrait contenir des champs Content-Length et Vary, par exemple, qui ne sont pas générés dans une réponse HEAD. Ces petites incohérences sont considérées comme préférables à la génération et à l'élimination du contenu pour une requête HEAD, car HEAD est généralement demandée dans un souci d'efficacité.

Bien que le tramage du message de requête soit indépendant de la méthode utilisée, le contenu reçu dans une requête HEAD n'a pas de sémantique généralement définie, ne peut pas modifier la signification ou la cible de la requête, et peut conduire certaines implémentations à rejeter la requête et à fermer la connexion en raison de son potentiel en tant qu'attaque de contrebande de requêtes (Section 11.2 de [HTTP/1.1]). Un client NE DEVRAIT PAS (SHOULD NOT) générer de contenu dans une requête HEAD à moins qu'elle ne soit faite directement à un serveur d'origine qui a précédemment indiqué, dans la bande ou hors bande, qu'une telle requête a un but et sera adéquatement prise en charge. Un serveur d'origine NE DEVRAIT PAS (SHOULD NOT) s'appuyer sur des accords privés pour recevoir du contenu, car les participants à la communication HTTP ne sont souvent pas conscients des intermédiaires sur la chaîne de requêtes.

La réponse à une requête HEAD est cacheable ; un cache PEUT (MAY) l'utiliser pour satisfaire les requêtes HEAD ultérieures, sauf indication contraire du champ d'en-tête Cache-Control (Section 5.2 de [CACHING]). Une réponse HEAD peut également avoir un effet sur les réponses précédemment mises en cache pour GET ; voir Section 4.3.5 de [CACHING].

9.3.3. POST

La méthode POST demande que la ressource cible traite la représentation incluse dans la requête selon la sémantique spécifique de la ressource. Par exemple, POST est utilisée pour les fonctions suivantes (entre autres) :

• Fournir un bloc de données, tel que les champs saisis dans un formulaire HTML, à un processus de traitement de données ;
• Publier un message sur un tableau d'affichage, un groupe de discussion, une liste de diffusion, un blog ou un groupe d'articles similaire ;
• Créer une nouvelle ressource qui n'a pas encore été identifiée par le serveur d'origine ; et
• Ajouter des données aux représentations existantes d'une ressource.

Un serveur d'origine indique la sémantique de la réponse en choisissant un code d'état approprié en fonction du résultat du traitement de la requête POST ; presque tous les codes d'état définis par cette spécification peuvent être reçus dans une réponse à POST (les exceptions étant 206 (Partial Content), 304 (Not Modified) et 416 (Range Not Satisfiable)).

Si une ou plusieurs ressources ont été créées sur le serveur d'origine suite au traitement réussi d'une requête POST, le serveur d'origine DEVRAIT (SHOULD) envoyer une réponse 201 (Created) contenant un champ d'en-tête Location (Section 10.2.2) qui fournit un identifiant pour la ressource principale créée et une représentation qui décrit l'état de la requête tout en faisant référence à la ou aux nouvelles ressources.

Les réponses aux requêtes POST ne sont cacheables que lorsqu'elles incluent des informations de fraîcheur explicites (voir Section 4.2.1 de [CACHING]) et un champ d'en-tête Content-Location (Section 8.7) qui a la même valeur que l'URI cible du POST. Une réponse POST mise en cache peut être réutilisée pour satisfaire une requête GET ou HEAD ultérieure. En revanche, une requête POST ne peut pas être satisfaite par une réponse POST mise en cache car POST est potentiellement non sûre ; voir Section 4 de [CACHING].

Si le résultat du traitement d'un POST serait équivalent à une représentation d'une ressource existante, un serveur d'origine PEUT (MAY) rediriger l'agent utilisateur vers cette ressource en envoyant une réponse 303 (See Other) avec l'identifiant de la ressource existante dans le champ Location. Cela a l'avantage de fournir à l'agent utilisateur un identifiant de ressource et de transférer la représentation via une méthode plus adaptée au cache partagé, bien qu'au coût d'une requête supplémentaire si l'agent utilisateur n'a pas déjà la représentation en cache.

9.3.4. PUT

La méthode PUT demande que l'état de la ressource cible soit créé ou remplacé par l'état défini par la représentation incluse dans le contenu du message de requête. Un PUT réussi d'une représentation donnée suggérerait qu'un GET ultérieur sur cette même ressource cible entraînera l'envoi d'une représentation équivalente dans une réponse 200 (OK). Cependant, il n'y a aucune garantie qu'un tel changement d'état soit observable, car la ressource cible pourrait être manipulée par d'autres agents utilisateurs en parallèle, ou pourrait être soumise à un traitement dynamique par le serveur d'origine, avant qu'un GET ultérieur ne soit reçu. Une réponse réussie implique seulement que l'intention de l'agent utilisateur a été atteinte au moment de son traitement par le serveur d'origine.

Si la ressource cible n'a pas de représentation actuelle et que le PUT la crée avec succès, alors le serveur d'origine DOIT (MUST) informer l'agent utilisateur en envoyant une réponse 201 (Created). Si la ressource cible a une représentation actuelle et que cette représentation est modifiée avec succès conformément à l'état de la représentation incluse, alors le serveur d'origine DOIT (MUST) envoyer soit une réponse 200 (OK) soit une réponse 204 (No Content) pour indiquer l'achèvement réussi de la requête.

Un serveur d'origine DEVRAIT (SHOULD) vérifier que la représentation PUT est cohérente avec ses contraintes configurées pour la ressource cible. Par exemple, si un serveur d'origine détermine les métadonnées de représentation d'une ressource en fonction de l'URI, alors le serveur d'origine doit s'assurer que le contenu reçu dans une requête PUT réussie est cohérent avec ces métadonnées. Lorsqu'une représentation PUT est incohérente avec la ressource cible, le serveur d'origine DEVRAIT (SHOULD) soit les rendre cohérents en transformant la représentation ou en modifiant la configuration de la ressource, soit répondre avec un message d'erreur approprié contenant suffisamment d'informations pour expliquer pourquoi la représentation est inappropriée. Les codes d'état 409 (Conflict) ou 415 (Unsupported Media Type) sont suggérés, ce dernier étant spécifique aux contraintes sur les valeurs Content-Type.

Par exemple, si la ressource cible est configurée pour toujours avoir un Content-Type de « text/html » et que la représentation en cours de PUT a un Content-Type de « image/jpeg », le serveur d'origine devrait faire l'un des éléments suivants :

a. reconfigurer la ressource cible pour refléter le nouveau type de média ; b. transformer la représentation PUT dans un format cohérent avec celui de la ressource avant de l'enregistrer comme nouvel état de ressource ; ou, c. rejeter la requête avec une réponse 415 (Unsupported Media Type) indiquant que la ressource cible est limitée à « text/html », en incluant éventuellement un lien vers une ressource différente qui serait une cible appropriée pour la nouvelle représentation.

HTTP ne définit pas exactement comment une méthode PUT affecte l'état d'un serveur d'origine au-delà de ce qui peut être exprimé par l'intention de la requête de l'agent utilisateur et la sémantique de la réponse du serveur d'origine. Il ne définit pas ce qu'une ressource pourrait être, en quelque sens que ce soit de ce mot, au-delà de l'interface fournie via HTTP. Il ne définit pas comment l'état de la ressource est « stocké », ni comment ce stockage pourrait changer suite à un changement d'état de la ressource, ni comment le serveur d'origine traduit l'état de la ressource en représentations. En général, tous les détails d'implémentation derrière l'interface de ressource sont intentionnellement cachés par le serveur.

Cela s'étend à la façon dont le serveur d'origine décide d'associer un identifiant à une ressource. Le serveur d'origine est seul responsable du mappage d'un URI cible à une ressource et donc seul responsable de la création, modification ou destruction de cette ressource. Il n'y a pas de relation requise entre la forme d'un URI cible et tout état interne géré par le serveur d'origine, rendant les URI opaques pour tout client qui n'est pas au courant des détails d'implémentation du serveur.

Un serveur d'origine NE DOIT PAS (MUST NOT) envoyer un champ validateur (Section 8.8), tel qu'un champ ETag ou Last-Modified, dans une réponse réussie à PUT à moins que les données de représentation de la requête n'aient été enregistrées sans aucune transformation appliquée au contenu (c'est-à-dire que les nouvelles données de représentation de la ressource sont identiques au contenu reçu dans la requête PUT) et que la valeur du champ validateur reflète la nouvelle représentation. Cette exigence permet à un agent utilisateur de savoir quand la représentation qu'il a envoyée (et conservée en mémoire) est le résultat du PUT, et donc qu'il n'a pas besoin de la récupérer à nouveau du serveur d'origine. Le(s) nouveau(x) validateur(s) reçu(s) dans la réponse peut(peuvent) être utilisé(s) pour de futures requêtes conditionnelles afin d'éviter les écrasements accidentels (Section 13.1).

La différence fondamentale entre les méthodes POST et PUT est mise en évidence par l'intention différente pour la représentation incluse. La ressource cible dans une requête POST est destinée à gérer la représentation incluse selon la sémantique propre de la ressource, alors que la représentation incluse dans une requête PUT est définie comme remplaçant l'état de la ressource cible. Par conséquent, l'intention de PUT est idempotente et visible pour les intermédiaires, même si l'effet exact n'est connu que par le serveur d'origine.

L'interprétation correcte d'une requête PUT présume que l'agent utilisateur sait quelle ressource cible est désirée. Un service qui sélectionne un URI approprié au nom du client, après avoir reçu une requête de changement d'état, DEVRAIT (SHOULD) être implémenté en utilisant la méthode POST plutôt que PUT. Si le serveur d'origine ne fera pas le changement d'état PUT demandé à la ressource cible et souhaite plutôt qu'il soit appliqué à une ressource différente, comme lorsque la ressource a été déplacée vers un URI différent, alors le serveur d'origine DOIT (MUST) envoyer une réponse 3xx (Redirection) appropriée ; l'agent utilisateur PEUT (MAY) alors prendre sa propre décision quant à savoir s'il faut ou non rediriger la requête.

Une requête PUT appliquée à la ressource cible peut avoir des effets secondaires sur d'autres ressources. Par exemple, un article pourrait avoir un URI pour identifier « la version actuelle » (une ressource) qui est séparé des URI identifiant chaque version particulière (ressources différentes qui à un moment donné ont partagé le même état que la ressource de version actuelle). Un PUT réussi sur l'URI « version actuelle » pourrait donc créer une nouvelle ressource de version en plus de changer l'état de la ressource cible, et pourrait également causer l'ajout de liens entre les ressources connexes.

Un serveur d'origine qui autorise PUT sur une ressource cible donnée DOIT (MUST) envoyer une réponse 400 (Bad Request) à une requête PUT qui contient un champ d'en-tête Content-Range (Section 14.4), car le contenu pourrait ne pas être complet. Les mises à jour de contenu partiel sont possibles en ciblant une ressource séparément identifiée avec un état qui chevauche une partie de la ressource plus grande, ou en utilisant une méthode différente qui a été spécifiquement définie pour les mises à jour partielles (par exemple, la méthode PATCH définie dans [RFC5789]).

Les réponses aux requêtes PUT ne sont pas cacheables. Si une requête PUT réussie passe par un cache qui a une ou plusieurs réponses stockées pour l'URI cible, ces réponses stockées seront invalidées (voir Section 4.4 de [CACHING]).

9.3.5. DELETE

La méthode DELETE demande que le serveur d'origine supprime l'association entre la ressource cible et sa fonctionnalité actuelle. En effet, cette méthode est similaire à la commande rm dans UNIX : elle exprime une opération de suppression sur le mappage URI du serveur d'origine plutôt qu'une attente que les informations précédemment associées soient supprimées.

Si la ressource cible a une ou plusieurs représentations actuelles, elles peuvent ou non être détruites par le serveur d'origine, et le stockage associé peut ou non être récupéré, dépendant entièrement de la nature de la ressource et de son implémentation par le serveur d'origine (ce qui est en dehors du champ d'application de cette spécification). De même, d'autres aspects d'implémentation d'une ressource pourraient nécessiter d'être désactivés ou archivés suite à un DELETE, tels que des connexions de base de données ou de passerelle. En général, on suppose que le serveur d'origine n'autorisera DELETE que sur les ressources pour lesquelles il dispose d'un mécanisme prescrit pour accomplir la suppression.

Relativement peu de ressources autorisent la méthode DELETE — son utilisation principale est pour les environnements d'authoring à distance, où l'utilisateur a une certaine direction concernant son effet. Par exemple, une ressource qui a été précédemment créée à l'aide d'une requête PUT, ou identifiée via le champ d'en-tête Location après une réponse 201 (Created) à une requête POST, pourrait autoriser une requête DELETE correspondante pour annuler ces actions. De même, les implémentations d'agents utilisateurs personnalisées qui implémentent une fonction d'authoring, telles que les clients de contrôle de révision utilisant HTTP pour les opérations à distance, pourraient utiliser DELETE sur la base d'une hypothèse que l'espace URI du serveur a été conçu pour correspondre à un référentiel de versions.

Si une méthode DELETE est appliquée avec succès, le serveur d'origine DEVRAIT (SHOULD) envoyer :

• un code d'état 202 (Accepted) si l'action réussira probablement mais n'a pas encore été effectuée,
• un code d'état 204 (No Content) si l'action a été effectuée et qu'aucune information supplémentaire ne doit être fournie, ou
• un code d'état 200 (OK) si l'action a été effectuée et que le message de réponse inclut une représentation décrivant l'état.

Bien que le tramage du message de requête soit indépendant de la méthode utilisée, le contenu reçu dans une requête DELETE n'a pas de sémantique généralement définie, ne peut pas modifier la signification ou la cible de la requête, et peut conduire certaines implémentations à rejeter la requête et à fermer la connexion en raison de son potentiel en tant qu'attaque de contrebande de requêtes (Section 11.2 de [HTTP/1.1]). Un client NE DEVRAIT PAS (SHOULD NOT) générer de contenu dans une requête DELETE à moins qu'elle ne soit faite directement à un serveur d'origine qui a précédemment indiqué, dans la bande ou hors bande, qu'une telle requête a un but et sera adéquatement prise en charge. Un serveur d'origine NE DEVRAIT PAS (SHOULD NOT) s'appuyer sur des accords privés pour recevoir du contenu, car les participants à la communication HTTP ne sont souvent pas conscients des intermédiaires sur la chaîne de requêtes.

Les réponses aux requêtes DELETE ne sont pas cacheables. Si une requête DELETE réussie passe par un cache qui a une ou plusieurs réponses stockées pour l'URI cible, ces réponses stockées seront invalidées (voir Section 4.4 de [CACHING]).

9.3.6. CONNECT

La méthode CONNECT demande au destinataire d'établir un tunnel vers le serveur d'origine de destination identifié par la request-target et, en cas de succès, de restreindre par la suite son comportement au transfert aveugle de données, dans les deux directions, jusqu'à ce que le tunnel soit fermé. Les tunnels sont couramment utilisés pour créer une connexion virtuelle de bout en bout, à travers un ou plusieurs proxys, qui peut ensuite être sécurisée à l'aide de TLS (Transport Layer Security, [TLS13]).

CONNECT est destiné uniquement à être utilisé dans les requêtes vers un proxy. Un client envoyant une requête CONNECT DOIT (MUST) envoyer la forme d'autorité de request-target (Section 7.1) ; c'est-à-dire que la request-target se compose uniquement du nom d'hôte et du numéro de port de la destination du tunnel, séparés par deux-points. Par exemple :

CONNECT server.example.com:80 HTTP/1.1
Host: server.example.com

Le proxy destinataire peut établir un tunnel soit en se connectant directement au serveur identifié par la request-target, soit, s'il est configuré pour utiliser un autre proxy, en transférant la requête CONNECT au proxy entrant suivant. Toute réponse 2xx (Successful) indique que l'expéditeur (et tous les proxys entrants) passera en mode tunnel immédiatement après la section d'en-tête de réponse ; les données reçues après cette réponse proviennent du serveur identifié par la request-target. Toute réponse autre qu'une réponse réussie indique que le tunnel n'a pas encore été formé.

Un tunnel est fermé lorsqu'un intermédiaire de tunnel détecte que l'un ou l'autre côté a fermé sa connexion : l'intermédiaire DOIT (MUST) tenter d'envoyer toutes les données en suspens provenant du côté fermé vers l'autre côté, fermer les deux connexions, puis éliminer toutes les données restantes non livrées.

Un serveur d'origine PEUT (MAY) accepter une requête CONNECT et participer comme une extrémité du tunnel s'il choisit de le faire, vraisemblablement pour de bonnes raisons liées à la sécurité du réseau ou à la politique de pare-feu. Dans ce cas, le serveur d'origine peut terminer la connexion (si elle a été reçue directement du client), traiter l'ensemble du message de requête comme les données à transférer aveuglément, et transférer ces données au service d'écoute identifié. Alternativement, le serveur d'origine peut traiter le message de requête comme s'il était destiné à être appliqué à sa propre configuration, ce qui contournerait les restrictions de pare-feu sur le trafic sortant (en supposant que les deux paires client/serveur source et destination sont contrôlées par le même administrateur système). Dans les deux cas, le serveur d'origine PEUT (MAY) appliquer des contrôles d'accès basés sur le message de requête pour un tel CONNECT, car cela pourrait avoir un impact sur la sécurité ou le fonctionnement s'il est transféré aveuglément.

Un serveur NE DOIT PAS (MUST NOT) envoyer de champs d'en-tête Transfer-Encoding ou Content-Length dans une réponse 2xx (Successful) à CONNECT. Un client DOIT (MUST) ignorer tout champ d'en-tête Content-Length ou Transfer-Encoding reçu dans une réponse réussie à CONNECT.

Un message de requête CONNECT n'a pas de contenu. L'interprétation des données envoyées après une requête CONNECT est spécifique à la version de HTTP utilisée. Voir Section 9.3.6 de [HTTP/1.1] pour plus de détails sur CONNECT dans HTTP/1.1.

Les réponses aux requêtes CONNECT ne sont pas cacheables.

9.3.7. OPTIONS

La méthode OPTIONS demande des informations sur les options de communication disponibles pour la ressource cible, soit au serveur d'origine soit chez un intermédiaire intervenant. Cette méthode permet à un 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.

Une requête OPTIONS avec un astérisque (« * ») comme request-target (Section 7.1) s'applique au serveur en général plutôt qu'à une ressource spécifique. Étant donné que les options de communication d'un serveur dépendent généralement de la ressource, la requête « * » n'est utile que comme type de méthode « ping » ou « no-op » ; elle ne fait rien au-delà de permettre au client de tester les capacités du serveur. Par exemple, cela peut être utilisé pour tester la conformité (ou l'absence de conformité) d'un proxy à HTTP/1.1.

Si la request-target n'est pas un astérisque, la requête OPTIONS s'applique aux options qui sont disponibles lors de la communication avec la ressource cible.

Un serveur générant une réponse réussie à OPTIONS DEVRAIT (SHOULD) envoyer tous les champs d'en-tête qui pourraient indiquer des fonctionnalités optionnelles implémentées par le serveur et applicables à la ressource cible (par exemple, Allow), y compris les extensions potentielles non définies par cette spécification. Le contenu de la réponse, le cas échéant, pourrait également décrire les options de communication dans une représentation lisible par machine ou par l'homme. Un format standard pour une telle représentation n'est pas défini par cette spécification, mais pourrait être défini par de futures extensions à HTTP.

Un client PEUT (MAY) envoyer un champ d'en-tête Max-Forwards dans une requête OPTIONS pour cibler un destinataire spécifique dans la chaîne de requêtes (voir Section 7.6.2). Un proxy NE DOIT PAS (MUST NOT) générer un champ d'en-tête Max-Forwards lors du transfert d'une requête à moins que cette requête n'ait été reçue avec un champ Max-Forwards.

Un client qui génère une requête OPTIONS contenant du contenu DOIT (MUST) envoyer un champ d'en-tête Content-Type valide décrivant le type de média de représentation. Bien que cette spécification ne définisse aucune utilisation pour un tel contenu, de futures extensions à HTTP pourraient utiliser le contenu OPTIONS pour faire des requêtes plus détaillées sur la ressource cible.

Les réponses aux requêtes OPTIONS ne sont pas cacheables.

9.3.8. TRACE

La méthode TRACE demande un bouclage à distance, au niveau de l'application, du message de requête. Le destinataire final de la requête DEVRAIT (SHOULD) refléter le message reçu, à l'exclusion de certains champs décrits ci-dessous, au client en tant que contenu d'une réponse 200 (OK) dont le Content-Type est « message/http » (Section 8.3.1 de [HTTP/1.1]). Le destinataire final est soit le serveur d'origine, soit le premier serveur à recevoir une valeur Max-Forwards de zéro (0) dans la requête (Section 7.6.2).

Un client NE DOIT PAS (MUST NOT) générer de champs d'en-tête dans une requête TRACE contenant des données sensibles qui pourraient être divulguées par la réponse. Par exemple, il serait imprudent pour un agent utilisateur d'envoyer des informations d'identification utilisateur stockées [HTTP-AUTH] ou des cookies [COOKIE] dans une requête TRACE. Le destinataire final de la requête DEVRAIT (SHOULD) exclure tout champ d'en-tête de requête susceptible de contenir des données sensibles lorsque ce destinataire génère le contenu de la réponse.

TRACE permet au client de voir ce qui est reçu à l'autre extrémité de la chaîne de requêtes et d'utiliser ces données pour des informations de test ou de diagnostic. La valeur du champ d'en-tête Via (Section 7.6.3) est d'un intérêt particulier, car elle agit comme une trace de la chaîne de requêtes. L'utilisation du champ d'en-tête Max-Forwards permet au client de limiter la longueur de la chaîne de requêtes, ce qui est utile pour tester une chaîne de proxys transférant des messages dans une boucle infinie.

Un client NE DOIT PAS (MUST NOT) envoyer de contenu dans une requête TRACE.

Les réponses aux requêtes TRACE ne sont pas cacheables.