Ai-je besoin d'un en-tête content-type pour les demandes HTTP GET ?

Question

D'après ce que j'ai compris, il y a deux endroits où l'on peut définir le type de contenu :

1. Le client définit un type de contenu pour le corps qu'il envoie au serveur (par exemple pour post)
2. Le serveur définit un type de contenu pour la réponse.

Cela signifie-t-il que je ne dois pas ou ne devrais pas définir un type de contenu pour toutes mes requêtes get (côté client) ? Et si je peux ou dois définir ce type de contenu, quel serait-il ?

J'ai également lu dans quelques messages que le type de contenu du client spécifie le type de contenu que le client souhaite recevoir. Alors peut-être que mon point 1 n'est pas correct ?

Answer 1

Según el RFC 7231 section 3.1.5.5 :

Un expéditeur qui génère un message contenant un corps de données utiles. DEVRAIT générer un champ d'en-tête Content-Type dans ce message, sauf si le type de média prévu pour la représentation jointe est inconnu de l'expéditeur. Si en l'absence d'un champ d'en-tête Content-Type, le destinataire PEUT soit supposer que le type de média est "application/octet-stream" ( [RFC2046], Section 4.5.1 ) ou examiner les données pour déterminer leur type.

Cela signifie que le Content-Type L'en-tête HTTP doit être défini uniquement pour PUT y POST demandes.

Answer 2

Les requêtes Get ne doivent pas avoir de content-type car elles n'ont pas d'entité de requête (c'est-à-dire un corps).

Answer 3

Les requêtes GET peuvent avoir des en-têtes "Accept", qui indiquent les types de contenu que le client accepte. Le serveur peut alors utiliser ces informations pour décider du type de contenu à renvoyer.

Ils sont cependant facultatifs.

http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.1

Answer 4

La réponse acceptée est fausse. La citation est correcte, l'affirmation selon laquelle PUT et POST doivent l'avoir est incorrecte. Il n'y a aucune exigence que PUT ou POST ait réellement un contenu supplémentaire. Il n'y a pas non plus d'interdiction à ce que GET ait effectivement du contenu.

Les RFC disent exactement ce qu'ils veulent dire IFF votre côté (client OU serveur d'origine) enverra du contenu supplémentaire, au-delà des en-têtes HTTP, il DEVRA spécifier un en-tête Content-Type. Notez toutefois qu'il est possible d'omettre l'en-tête Content-Type tout en incluant du contenu (par exemple, en utilisant un en-tête Content-Length).

Answer 5

Réponse courte : Très probablement, non vous n'ont pas besoin un en-tête content-type pour les requêtes HTTP GET. Mais les spécifications ne semblent pas non plus exclure un en-tête content-type pour les requêtes HTTP GET.

Matériel d'appui :

1. Le "Content-Type" fait partie des métadonnées de représentation (c'est-à-dire de la charge utile). Citation de RFC 7231 section 3.1 :

   3.1. Métadonnées de représentation

   Les champs d'en-tête de la représentation fournissent des métadonnées sur les éléments suivants représentation. Lorsqu'un message comprend un corps de charge utile, le champ d'en-tête champs d'en-tête de la représentation décrivent comment interpréter la données de représentation contenues dans le corps de données utiles. ...

   Les champs d'en-tête suivants transmettent des métadonnées de représentation :

   +-------------------+-----------------+
   | Header Field Name | Defined in...   |
   +-------------------+-----------------+
   | Content-Type      | Section 3.1.1.5 |
   | ...               | ...             |

   Citation tirée de RFC 7231 section 3.1.1.5 (à propos, la réponse choisie actuellement comportait une faute de frappe dans le numéro de section) :

   Le champ d'en-tête "Content-Type" indique le type de média de la représentation associée

2. En ce sens, une Content-Type ne concerne pas vraiment une demande HTTP GET (ou une demande POST ou PUT, d'ailleurs). Il s'agit de la charge utile contenue dans une telle quoi que ce soit demande. Donc, s'il n'y a pas de charge utile, il n'y a pas besoin de Content-Type . Dans la pratique, certaines mises en œuvre sont allées de l'avant et ont fait cette hypothèse compréhensible. Cité par Commentaire d'Adam :

   " Bien que ... la spécification ne dise pas que vous ne pouvez pas avoir Content-Type sur un GET, .Net semble le faire respecter dans son HttpClient. Voir ce q&a SO ."

3. Toutefois, à proprement parler, les spécifications elles-mêmes n'excluent pas la possibilité que le HTTP GET contienne une charge utile. Cité par RFC 7231 section 4.3.1 :

   4.3.1 GET

   ...

   Une charge utile dans un message de demande GET n'a pas de sémantique définie ; L'envoi d'un corps de données utiles lors d'une requête GET peut provoquer des problèmes dans certaines certaines implémentations existantes de rejeter la demande.

   Donc, si votre HTTP GET inclut une charge utile pour une raison ou une autre, une Content-Type La tête est probablement raisonnable, elle aussi.