web-dev-qa-db-fra.com

Charge utile des méthodes de requête HTTP

Le entrée Wikipedia sur HTTP répertorie les méthodes de requête HTTP suivantes:

  • HEAD: Demande une réponse identique à celle qui correspondrait à une demande GET, mais sans le corps de la réponse.
  • GET: Demande une représentation de la ressource spécifiée.
  • POST: Soumet les données à traiter (par exemple, à partir d'un formulaire HTML) à la ressource identifiée. Les données sont incluses dans le corps de la demande.
  • 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, afin qu'un client puisse voir les éventuelles modifications ou ajouts effectués par les serveurs intermédiaires.
  • OPTIONS: Renvoie les méthodes HTTP prises en charge par le serveur pour l'URL spécifiée. Cela 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 demande en un tunnel TCP/IP transparent, généralement pour faciliter la communication cryptée SSL (HTTPS) via un proxy HTTP non crypté.
  • PATCH: Est utilisé pour appliquer des modifications partielles à une ressource.

Je suis intéressé à savoir (en particulier en ce qui concerne les cinq premières méthodes):

  • lesquelles de ces méthodes sont capables (supposées?) de recevoir des données utiles
    • des méthodes pouvant recevoir des données utiles, comment les reçoivent-elles?
      • via la chaîne de requête dans l'URL?
      • via un corps encodé en URL?
      • via un corps brut/coupé?
      • via une combinaison de (tous/certains) de ce qui précède?

J'apprécie toutes les contributions. Si vous pouviez partager quelques lectures (de préférence légères), ce serait très bien aussi!

httprestrequesthttp-methodpayload
66
Alix Axel

RFC 7231 , Sémantique et contenu HTTP 1.1, 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 pouvant ê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 demande TRACE. Ainsi, seul TRACE ne peut pas avoir de charge utile, mais GET, HEAD, OPTIONS et CONNECT ne le feront probablement pas et le serveur ne saura pas comment le gérer si le client en envoie une (ce qui signifie qu'il peut l'ignorer).

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

28
Darrel Miller

Voici le résumé de RFC 7231 , une version mise à jour du lien @ Darrel posté:

  • [~ # ~] head [~ # ~] - Aucune sémantique définie dans le corps.
  • [~ # ~] get [~ # ~] - Aucune sémantique de corps définie.
  • [~ # ~] mettez [~ # ~] - Corps pris en charge.
  • [~ # ~] post [~ # ~] - Corps pris en charge.
  • [~ # ~] delete [~ # ~] - Aucune sémantique de corps définie.
  • [~ # ~] trace [~ # ~] - Corps pas prise en charge.
  • [~ # ~] options [~ # ~] - Corps pris en charge, mais pas de sémantique d'utilisation (peut-être dans le futur).
  • [~ # ~] connecte [~ # ~] - Pas de sémantique de corps définie

Comme @ John est également mentionné, toutes les méthodes de requête prennent en charge 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 [~ # ~] et [~ # ~] patch [~ # ~] méthodes puisque je ne les intéresse pas.

83
Alix Axel

Je suis presque sûr que ce n'est pas clair si les requêtes GET peuvent avoir des charges utiles. Les requêtes GET publient généralement des données de formulaire via la chaîne de requête, de même pour les requêtes HEAD. HEAD - sauf si le groupe ne souhaite pas de corps de réponse.

(Remarque: je dis que ce n'est pas clair, car une requête GET pourrait techniquement passer à un autre protocole; en fait, une version de websockets l'a fait et, alors que certains logiciels de proxy fonctionnaient bien avec cela, d'autres étaient choqués par la poignée de main.)

POST a généralement un corps. Rien ne vous empêche d'utiliser une chaîne de requête, mais le corps POST contiendra généralement les données de formulaire dans un POST.

Pour plus d’informations (et plus détaillées), j’ai tapé sur le réel spécifications HTTP/1.1 .

3
John Chadwick