4. Request Methods (Méthodes de Requête)

4.1. Overview (Vue d'Ensemble)

Le jeton de méthode de requête est la source principale de la sémantique de requête; il indique le but pour lequel le client a fait cette requête et ce que le client attend 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 (Section 5) si ces sémantiques supplémentaires n'entrent pas en conflit avec la méthode. Par exemple, un client peut envoyer des champs d'en-tête de requête conditionnelle (Section 5.2) pour rendre l'action demandée conditionnelle à l'état actuel de la ressource cible ([RFC7232]).

method = token

HTTP a été initialement conçu pour être utilisable comme interface vers des systèmes d'objets distribués. La méthode de requête était envisagée comme appliquant une sémantique à une ressource cible de la même manière que l'invocation d'une méthode définie sur un objet identifié appliquerait une sémantique. Le jeton de méthode est sensible à la casse car il pourrait être utilisé comme passerelle vers des systèmes basés sur des objets avec des noms de méthode sensibles à la casse.

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 par elle-même si ces sémantiques sont implémentées ou autorisées.

Cette spécification définit un certain nombre de méthodes standardisées couramment utilisées dans HTTP, comme indiqué dans le tableau suivant. Par convention, les méthodes standardisées sont définies en lettres US-ASCII majuscules.

Method	Safe (Sûre)	Idempotent (Idempotente)	Description
GET	Yes	Yes	Transférer une représentation actuelle de la ressource cible.
HEAD	Yes	Yes	Identique à GET, mais transférer uniquement la ligne d'état et la section d'en-tête.
POST	No	No	Effectuer un traitement spécifique à la ressource sur la charge utile de la requête.
PUT	No	Yes	Remplacer toutes les représentations actuelles de la ressource cible par la charge utile de la requête.
DELETE	No	Yes	Supprimer toutes les représentations actuelles de la ressource cible.
CONNECT	No	No	Établir un tunnel vers le serveur identifié par la ressource cible.
OPTIONS	Yes	Yes	Décrire les options de communication pour la ressource cible.
TRACE	Yes	Yes	Effectuer un test de bouclage de message le long du chemin vers la ressource cible.

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

Des méthodes supplémentaires, hors du champ d'application de cette spécification, ont été standardisées pour une utilisation dans HTTP. Toutes ces méthodes devraient être enregistrées dans le "Hypertext Transfer Protocol (HTTP) Method Registry" maintenu par l'IANA, tel que défini dans la Section 8.1.

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

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

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

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 à aucun changement d'état sur le serveur d'origine résultant de 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 nuisible, 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 des journaux pourrait se remplir et faire planter le 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 distinguer les 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 distinguer les méthodes sûres et 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 de requête effectif 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 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 désactiver ou interdire cette action lorsqu'elle est accédée à l'aide d'une méthode de requête sûre. Ne pas le faire entraînera des effets secondaires malheureux lorsque les processus automatisés effectueront un GET sur chaque référence URI dans le but de maintenance des liens, de pré-chargement, de construction d'un index de recherche, etc.

4.2.2. Idempotent Methods (Méthodes Idempotentes)

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 sont distinguées car la requête peut être répétée automatiquement si une défaillance de communication se produit avant que le client ne puisse 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 la réception de toute réponse, 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.

4.2.3. Cacheable Methods (Méthodes Pouvant Être Mises en Cache)

Les méthodes de requête peuvent être définies comme "pouvant être mises en cache" pour indiquer que les réponses à celles-ci sont autorisées à être stockées pour une réutilisation future; pour des exigences spécifiques, voir [RFC7234]. En général, les méthodes sûres qui ne dépendent pas d'une réponse actuelle ou faisant autorité sont définies comme pouvant être mises en cache; cette spécification définit GET, HEAD et POST comme pouvant être mises en cache, bien que l'écrasante majorité des implémentations de cache ne prennent en charge que GET et HEAD.

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

4.3.1. GET

La méthode GET demande le transfert d'une représentation actuellement sélectionnée pour la ressource cible. GET est le mécanisme principal de récupération d'informations et le focus de presque toutes les optimisations de performances. Par conséquent, lorsque les gens parlent de récupérer des informations identifiables via HTTP, ils se réfèrent généralement à faire une requête GET.

Il est tentant de penser aux identificateurs de ressources comme des noms de chemin de système de fichiers distant et aux représentations comme étant une copie du contenu de tels fichiers. Ce serait faux. Les représentations retournées en réponse à GET ne sont pas nécessairement juste le contenu d'une ressource telle que stockée par le serveur d'origine. Au lieu de cela, elles sont sélectionnées (via la négociation de contenu) et générées à la volée, en fonction de la requête.

Une charge utile dans un message de requête GET n'a pas de sémantique définie; l'envoi d'un corps de charge utile sur une requête GET pourrait amener certaines implémentations existantes à rejeter la requête.

La réponse à une requête GET peut être mise en cache; un cache PEUT 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 [RFC7234]).

4.3.2. HEAD

La méthode HEAD est identique à GET sauf que le serveur NE DOIT PAS envoyer de corps de message dans la réponse (c'est-à-dire que la réponse se termine à la fin de la section d'en-tête). Le serveur DEVRAIT envoyer les mêmes champs d'en-tête en réponse à une requête HEAD qu'il aurait envoyés si la requête avait été un GET, sauf que les champs d'en-tête de charge utile (Section 3.3) PEUVENT être omis. Cette méthode peut être utilisée pour obtenir des métadonnées sur la représentation sélectionnée sans transférer les données de représentation et est souvent utilisée pour tester les liens hypertexte pour la validité, l'accessibilité et la modification récente.

Une charge utile dans un message de requête HEAD n'a pas de sémantique définie; l'envoi d'un corps de charge utile sur une requête HEAD pourrait amener certaines implémentations existantes à rejeter la requête.

La réponse à une requête HEAD peut être mise en cache; un cache PEUT 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 [RFC7234]). Une réponse HEAD pourrait également avoir un effet sur les réponses GET précédemment mises en cache; voir Section 4.3.5 de [RFC7234].

4.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é pour les fonctions suivantes (entre autres):

• Fournir un bloc de données, tel que les champs entrés dans un formulaire HTML, à un processus de traitement de données;

• Publier un message sur un tableau d'affichage, un groupe de nouvelles, une liste de diffusion, un blog ou un groupe similaire d'articles;

• 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 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 en 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 à la suite du traitement réussi d'une requête POST, le serveur d'origine DEVRAIT envoyer une réponse 201 (Created) contenant un champ d'en-tête Location qui fournit un identificateur pour la ressource principale créée (Section 7.1.2) 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 peuvent être mises en cache que lorsqu'elles incluent des informations de fraîcheur explicites (voir Section 4.2.1 de [RFC7234]). Cependant, la mise en cache POST n'est pas largement implémentée. Pour les cas où un serveur d'origine souhaite que le client puisse mettre en cache le résultat d'un POST d'une manière qui peut être réutilisée par un GET ultérieur, le serveur d'origine PEUT envoyer une réponse 200 (OK) contenant le résultat et un champ d'en-tête Content-Location qui a la même valeur que l'URI de requête effectif du POST (Section 3.1.4.2).

Si le résultat du traitement d'un POST serait équivalent à une représentation d'une ressource existante, un serveur d'origine PEUT rediriger l'agent utilisateur vers cette ressource en envoyant une réponse 303 (See Other) avec l'identificateur de la ressource existante dans le champ Location. Cela a les avantages de fournir à l'agent utilisateur un identificateur de ressource et de transférer la représentation via une méthode plus adaptée à la mise en cache partagée, 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.

4.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 la charge utile 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 sera 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 la réception de tout GET ultérieur. Une réponse réussie implique seulement que l'intention de l'agent utilisateur a été réalisée 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 en crée une avec succès, alors le serveur d'origine DOIT 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 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 vérifier que la représentation PUT est cohérente avec toutes les contraintes que le serveur a pour la ressource cible qui ne peuvent pas être ou ne sont pas modifiées par le PUT. Ceci est particulièrement important lorsque le serveur d'origine utilise des informations de configuration internes liées à l'URI pour définir les valeurs des métadonnées de représentation sur les réponses GET. Lorsqu'une représentation PUT est incohérente avec la ressource cible, le serveur d'origine DEVRAIT 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 avoir toujours un Content-Type de "text/html" et que la représentation étant 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 la sauvegarder 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", incluant peut-être 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, dans quelque sens que ce soit, au-delà de l'interface fournie via HTTP. Il ne définit pas comment l'état de la ressource est "stocké", ni comment un tel stockage pourrait changer à la suite d'un changement dans l'état de la ressource, ni comment le serveur d'origine traduit l'état de la ressource en représentations. De manière générale, tous les détails d'implémentation derrière l'interface de ressource sont intentionnellement cachés par le serveur.

Un serveur d'origine NE DOIT PAS envoyer un champ d'en-tête validateur (Section 7.2), 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é sauvegardées sans aucune transformation appliquée au corps (c'est-à-dire que les nouvelles données de représentation de la ressource sont identiques aux données de représentation reçues 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 que le corps de représentation qu'il a en mémoire reste actuel à la suite du PUT, n'ayant donc pas besoin d'être récupéré à nouveau depuis le serveur d'origine, et que les nouveaux validateurs reçus dans la réponse peuvent être utilisés pour de futures requêtes conditionnelles afin de prévenir les écrasements accidentels (Section 5.2).

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 souhaité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 ê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 l'appliquer à une ressource différente, comme lorsque la ressource a été déplacée vers un URI différent, alors le serveur d'origine DOIT envoyer une réponse 3xx (Redirection) appropriée; l'agent utilisateur PEUT alors prendre sa propre décision quant à rediriger ou non 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 distinct des URI identifiant chaque version particulière (différentes ressources qui à un moment donné partageaient le même état que la ressource de version actuelle). Une requête PUT réussie sur l'URI "de la version actuelle" pourrait donc créer une nouvelle ressource de version en plus de changer l'état de la ressource cible, et pourrait également provoquer l'ajout de liens entre les ressources liées.

Un serveur d'origine qui autorise PUT sur une ressource cible donnée DOIT envoyer une réponse 400 (Bad Request) à une requête PUT qui contient un champ d'en-tête Content-Range (Section 4.2 de [RFC7233]), car la charge utile est susceptible d'être du contenu partiel qui a été PUT par erreur comme une représentation complète. 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 large, 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 à la méthode PUT ne peuvent pas être mises en cache. Si une requête PUT réussie passe par un cache qui a une ou plusieurs réponses stockées pour l'URI de requête effectif, ces réponses stockées seront invalidées (voir Section 4.4 de [RFC7234]).

4.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 pourraient ou non être détruites par le serveur d'origine, et le stockage associé pourrait 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 (qui sont au-delà de la portée de cette spécification). De même, d'autres aspects d'implémentation d'une ressource pourraient devoir être désactivés ou archivés en conséquence d'un DELETE, tels que des connexions de base de données ou de passerelle. En général, il est supposé que le serveur d'origine n'autorisera DELETE que sur les ressources pour lesquelles il a 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 en se basant sur l'hypothèse que l'espace URI du serveur a été conçu pour correspondre à un dépôt de versions.

Si une méthode DELETE est appliquée avec succès, le serveur d'origine DEVRAIT envoyer un code d'état 202 (Accepted) si l'action réussira probablement mais n'a pas encore été mise en œuvre, un code d'état 204 (No Content) si l'action a été mise en œuvre et qu'aucune information supplémentaire ne doit être fournie, ou un code d'état 200 (OK) si l'action a été mise en œuvre et que le message de réponse inclut une représentation décrivant l'état.

Une charge utile dans un message de requête DELETE n'a pas de sémantique définie; l'envoi d'un corps de charge utile sur une requête DELETE pourrait amener certaines implémentations existantes à rejeter la requête.

Les réponses à la méthode DELETE ne peuvent pas être mises en cache. Si une requête DELETE passe par un cache qui a une ou plusieurs réponses stockées pour l'URI de requête effectif, ces réponses stockées seront invalidées (voir Section 4.4 de [RFC7234]).

4.3.6. CONNECT

La méthode CONNECT demande que le destinataire établisse un tunnel vers le serveur d'origine de destination identifié par la cible de requête et, en cas de succès, restreigne ensuite son comportement à la transmission aveugle de paquets, 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 proxies, qui peut ensuite être sécurisée en utilisant TLS (Transport Layer Security, [RFC5246]).

CONNECT est destiné uniquement à être utilisé dans les requêtes vers un proxy. Un serveur d'origine qui reçoit une requête CONNECT pour lui-même PEUT répondre avec un code d'état 2xx (Successful) pour indiquer qu'une connexion est établie. Cependant, la plupart des serveurs d'origine n'implémentent pas CONNECT.

Un client envoyant une requête CONNECT DOIT envoyer la forme d'autorité de la cible de requête (Section 5.3 de [RFC7230]); c'est-à-dire que la cible de requête se compose uniquement du nom d'hôte et du numéro de port de la destination du tunnel, séparés par un deux-points. Par exemple,

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

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

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

L'authentification proxy pourrait être utilisée pour établir l'autorité de créer un tunnel. Par exemple,

CONNECT server.example.com:80 HTTP/1.1
Host: server.example.com:80
Proxy-Authorization: basic aGVsbG86d29ybGQ=

Il existe des risques importants dans l'établissement d'un tunnel vers des serveurs arbitraires, en particulier lorsque la destination est un port TCP bien connu ou réservé qui n'est pas destiné au trafic Web. Par exemple, un CONNECT vers "example.com:25" suggérerait que le proxy se connecte au port réservé pour le trafic SMTP; s'il est autorisé, cela pourrait tromper le proxy pour qu'il relaie du courrier indésirable. Les proxies qui prennent en charge CONNECT DEVRAIENT restreindre son utilisation à un ensemble limité de ports connus ou une liste configurable de cibles de requête sûres.

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

Une charge utile dans un message de requête CONNECT n'a pas de sémantique définie; l'envoi d'un corps de charge utile sur une requête CONNECT pourrait amener certaines implémentations existantes à rejeter la requête.

Les réponses à la méthode CONNECT ne peuvent pas être mises en cache.

4.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 à un intermédiaire intervenant. Cette méthode permet à un client de déterminer les options et/ou les 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 cible de requête (Section 5.3 de [RFC7230]) 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é HTTP/1.1 d'un proxy (ou son absence).

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

Un serveur générant une réponse réussie à OPTIONS DEVRAIT 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. La charge utile de 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 serveur DOIT générer un champ Content-Length avec une valeur de "0" si aucun corps de charge utile ne doit être envoyé dans la réponse.

Un client PEUT 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ête (voir Section 5.1.2). Un proxy NE DOIT PAS générer un champ d'en-tête Max-Forwards lors de la transmission 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 un corps de charge utile DOIT 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 une telle charge utile, de futures extensions à HTTP pourraient utiliser le corps OPTIONS pour effectuer des requêtes plus détaillées sur la ressource cible.

Les réponses à la méthode OPTIONS ne peuvent pas être mises en cache.

4.3.8. TRACE

La méthode TRACE demande un bouclage distant au niveau application du message de requête. Le destinataire final de la requête DEVRAIT refléter le message reçu, à l'exclusion de certains champs décrits ci-dessous, au client en tant que corps de message d'une réponse 200 (OK) avec un Content-Type de "message/http" (Section 8.3.1 de [RFC7230]). 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 5.1.2).

Un client NE DOIT PAS 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 insensé pour un agent utilisateur d'envoyer des informations d'identification utilisateur stockées [RFC7235] ou des cookies [RFC6265] dans une requête TRACE. Le destinataire final de la requête DEVRAIT exclure tous les champs d'en-tête de requête susceptibles de contenir des données sensibles lorsque ce destinataire génère le corps de réponse.

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

Un client NE DOIT PAS envoyer de corps de message dans une requête TRACE.

Les réponses à la méthode TRACE ne peuvent pas être mises en cache.

---