Charges utiles des méthodes de requête HTTP

Question

Le site Entrée de Wikipédia sur HTTP énumère les méthodes de requête HTTP suivantes :

• TÊTE : Demande une réponse identique à celle qui correspondrait à une requête GET, mais sans le corps de la réponse.
• GET : Demande une représentation de la ressource spécifiée.
• POST : Soumet des données à traiter (par exemple, à partir d'un formulaire HTML) à la ressource identifiée. Les données sont incluses dans le corps de la requête.
• PUT : Télécharge une représentation de la ressource spécifiée.
• DELETE : Supprime la ressource spécifiée.
• TRACE : Renvoie la demande reçue, de sorte qu'un client puisse voir quelles modifications ou quels ajouts ont été effectués par les serveurs intermédiaires (le cas échéant).
• OPTIONS : Renvoie les méthodes HTTP que le serveur prend en charge pour l'URL spécifiée. Ceci peut être utilisé pour vérifier la fonctionnalité d'un serveur web en demandant '*' au lieu d'une ressource spécifique.
• CONNECT : Convertit la connexion de la requête en un tunnel TCP/IP transparent, généralement pour faciliter les communications cryptées par SSL (HTTPS) via un proxy HTTP non crypté.
• PATCH : Est utilisé pour appliquer des modifications partielles à une ressource.

J'aimerais savoir (en particulier en ce qui concerne les cinq premières méthodes) :

• lesquelles de ces méthodes sont capables (censées ?) de recevoir des charges utiles
  • des méthodes qui peuvent recevoir des charges utiles, comment les reçoivent-elles ?
    • via la chaîne de requête dans l'URL ?
    • via un corps codé en URL ?
    • via un corps brut / en morceaux ?
    • par une combinaison de ([toutes / certaines]) des éléments ci-dessus ?

J'apprécie tous les commentaires, si vous pouvez partager quelques lectures (de préférence légères), ce serait bien aussi !

Answer 1

Voici le résumé de RFC 7231 une version actualisée du lien @Darrel affiché :

• TETE - Pas de sémantique de corps définie.
• GET - Pas de sémantique de corps définie.
• PUT - Corps supporté.
• POST - Corps supporté.
• DELETE - Pas de sémantique de corps définie.
• TRACE - Corps no soutenu.
• OPTIONS - Corps supporté mais pas de sémantique sur l'utilisation (peut-être dans le futur).
• CONNECTER - Pas de sémantique définie pour le corps

Como @John également mentionné, toutes les méthodes de requête supportent les chaînes de requête dans l'URL (une exception notable pourrait être OPTIONS qui ne semble être utile [dans mes tests] que si l'URL est HOST/* ).

Je n'ai pas testé le CONNECTER y PATCH puisque je n'ai aucun intérêt dans ces méthodes.

Answer 2

RFC 7231 HTTP 1.1 Semantics and Content, est la source la plus récente et la plus fiable sur la sémantique des méthodes HTTP. Cette spécification indique qu'il n'y a pas de signification définie pour une charge utile qui peut être incluse dans un message GET, HEAD, OPTIONS ou CONNECT. La section 4.3.8 indique que le client ne doit pas envoyer de corps pour une requête TRACE. Donc, seul TRACE ne peut pas avoir de charge utile, mais GET, HEAD, OPTIONS, et CONNECT n'en auront probablement pas et le serveur n'est pas censé savoir comment le traiter si le client en envoie un (ce qui signifie qu'il peut l'ignorer).

Si vous croyez que quelque chose est ambigu, alors il y a une liste de diffusion où vous pouvez exprimer vos préoccupations.

Answer 3

Je suis sûr que ce n'est pas clair si les requêtes GET peuvent avoir des charges utiles ou non. Les requêtes GET affichent généralement des données de formulaire par le biais de la chaîne de requête, de même pour les requêtes HEAD. HEAD est essentiellement GET - sauf qu'il ne veut pas de corps de réponse.

(Note annexe : je dis que ce n'est pas clair parce qu'une requête GET pourrait techniquement passer à un autre protocole ; en fait, une version de websockets a fait exactement cela, et tandis que certains logiciels proxy fonctionnaient bien avec, d'autres se sont bloqués lors de la poignée de main).

Les POST ont généralement un corps. Rien ne vous empêche d'utiliser une chaîne de requête, mais le corps du POST contient généralement des données de formulaire dans un POST.

Pour plus d'informations (et plus détaillées), je consulterais les sites suivants HTTP/1.1 specs .