Cette affirmation est-elle correcte ? La méthode HTTP GET n'a jamais de corps de message.

Question

Cette affirmation est-elle correcte ? La méthode HTTP GET n'a toujours pas de corps de message. Je n'ai pas trouvé de partie de la RFC2616 qui dise explicitement cela.

Et si ce n'est pas vrai, dans quelles circonstances une requête Http GET peut-elle inclure un corps de message

Answer 1

Ni l'un ni l'autre restclient ni Console REST supporte cela mais curl le fait.

El Spécification originale HTTP 1.1 dit dans la section 4.3

Un corps de message NE DOIT PAS être inclus dans une demande si la spécification de la méthode de demande (section 5.1.1) ne permet pas d'envoyer un corps d'entité dans les demandes.

Section 5.1.1 nous redirige vers la section 9.x pour les différentes méthodes. Aucune d'entre elles n'interdit explicitement l'inclusion d'un corps de message. Cependant...

Section 5.2 dit

La ressource exacte identifiée par une demande Internet est déterminée en examinant à la fois le champ Request-URI et le champ d'en-tête Host.

y Section 9.3 dit

La méthode GET permet de récupérer les informations (sous la forme d'une entité) identifiées par le Request-URI.

Lesquels suggèrent que lors du traitement d'une requête GET, un serveur n'est pas requis pour examiner autre chose que le champ d'en-tête Request-URI et Host.

En résumé, la spécification HTTP ne vous empêche pas d'envoyer un corps de message avec GET, mais il y a suffisamment d'ambiguïté pour que je ne sois pas surpris si ce n'est pas pris en charge par tous les serveurs.

Answer 2

L'ancienne RFC2616 a été supprimée et remplacée par plusieurs RFC (7230-7237).

Nouveau RFC 7230 sur HTTP/1.1 dit clairement à propos du corps du message :

Le corps du message (s'il y en a un) d'un message HTTP est utilisé pour transmettre l'information suivante
le corps de la charge utile de cette demande ou réponse. Le corps du message est
identique au corps de la charge utile à moins qu'un codage de transfert ait été
appliqué, comme décrit à la section 3.3.1.

 message-body = *OCTET

Les règles concernant le moment où un corps de message est autorisé dans un message diffèrent. pour les demandes et les réponses.

La présence d'un corps de message dans une demande est signalée par une balise
Champ d'en-tête Content-Length ou Transfer-Encoding. Demande de message
le cadrage est indépendant de la sémantique de la méthode même si la méthode ne
ne définit pas l'utilisation d'un corps de message.

Donc nouvelle norme clairement répondre à la question initiale. Mais il existe d'anciens logiciels qui peuvent ignorer le corps du message dans la requête GET, vous devez donc être prudent et vérifier ce cas.

Answer 3

J'ai rencontré ce problème dans elasticsearch, où une requête GET avec un corps de message est utilisée pour tester les analyseurs. https://www.elastic.co/guide/en/elasticsearch/guide/master/analysis-intro.html

Il s'agit essentiellement d'une demande qui ne modifie rien du côté du serveur, mais qui nécessite la transmission d'un long message texte en entrée. Cela semble être une bonne utilisation de la requête GET avec un corps de message.

Answer 4

I pensez à la spécification vous permet d'ajouter un corps de message, donc la réponse à votre question devrait être Non (mais avec des réserves).

Vérifions d'abord la spécification (je cite le texte de l'article) RFC 7231 , RFC 7232 y RFC 7234 puisque la RFC 2616 à laquelle il est fait référence dans d'autres réponses a été rendue obsolète par celles-ci).

Extrait du RFC 7230 :

The presence of a message body in a request is signaled by a
Content-Length or Transfer-Encoding header field. Request message
framing is independent of method semantics, even if the method does
not define any use for a message body.

Notez que la partie "Un corps de message NE DOIT PAS être inclus dans une demande si la spécification de la méthode de demande (section 5.1.1) ne permet pas d'envoyer un corps d'entité dans les demandes." présent dans l'ancien RFC 2616 a été supprimé.

Également RFC 7231 dit ceci à ce sujet :

A payload within a GET request message has no defined semantics;
sending a payload body on a GET request might cause some existing
implementations to reject the request.

Donc, à mon avis, cela signifie que vous pouvez ajouter un corps de message à une requête GET (et cela devrait répondre à votre question initiale), mais vous devez être prudent. Le cas mentionné dans les spécifications n'est pas le seul dont vous devez être conscient, de nombreux outils, clients et serveurs ne s'attendent tout simplement pas à un corps de message et peuvent mal se comporter. Par exemple, dans Chrome, XMLHttpRequest laisse tomber le corps du message pour les GET.

Un autre problème est celui de la mise en cache. Selon le RFC 7234 .

The primary cache key consists of the request method and target URI   
[...]
If a request target is subject to content negotiation, its cache
entry might consist of multiple stored responses, each differentiated
by a secondary key for the values of the original request's selecting
header fields.

Cela signifie que des demandes ayant des corps différents mais la même url (et éventuellement des en-têtes sélectionnés), seront considérées comme ayant la même réponse par un cache, même si le corps du message a été précédemment transmis correctement au serveur.

En fin de compte, je pense que, dans la mesure du possible, vous devriez éviter d'utiliser des corps de message dans les GET, à moins que

• Vous contrôlez le client
• Vous contrôlez le serveur
• Vous connaissez les proxies potentiels, les caches qui pourraient vous gêner.
• Vous désactivez la mise en cache dans la réponse (il se peut en fait que vous puissiez (ab)utiliser les en-têtes pour pouvoir mettre en cache, mais je n'ai pas bien étudié l'idée).