Ai-je besoin d'un en-tête de type de contenu pour les requêtes HTTP GET?

Pour autant que je sache, il y a deux endroits où 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 la publication)
2. Le serveur définit un type de contenu pour la réponse.

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

J'ai également lu dans quelques articles 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?

Selon la section 3.1.5.5 de la RFC 7231 :

Un expéditeur qui génère un message contenant un corps de charge utile DEVRAIT générer un champ d' en -tête Content-Type dans ce message à moins que le type de support prévu de la représentation incluse ne soit inconnu de l'expéditeur. Si un champ d'en-tête Content-Type n'est pas présent, le destinataire PEUT soit supposer un type de support de "application / octet-stream" ( [RFC2046], paragraphe 4.5.1 ) ou examiner les données pour déterminer son type.

Cela signifie que l' Content-Typeen-tête HTTP ne doit être défini que pour les requêtes PUTet POST.

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

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

Ils sont cependant facultatifs.

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

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'est pas nécessaire que PUT ou POST aient réellement du contenu supplémentaire. Il n'y a pas non plus d'interdiction pour GET d'avoir effectivement du contenu.

Les RFC disent exactement ce qu'ils signifient. IFF de votre côté (client OU serveur d'origine) enverra du contenu supplémentaire, au-delà des en-têtes HTTP, il DEVRAIT spécifier un en-tête Content-Type. Mais notez qu'il est permis d'omettre le Content-Type et d'inclure toujours du contenu (par exemple, en utilisant un en-tête Content-Length).

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

Matériel de support:

1. "Content-Type" fait partie des métadonnées de représentation (c.-à-d. Charge utile). Extrait de la section 3.1 de la RFC 7231 :

   3.1. Métadonnées de représentation

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

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

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

   Cité de la section 3.1.1.5 de la RFC 7231 (en passant, la réponse choisie actuelle avait 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, un en- Content-Typetête ne concerne pas vraiment une requête HTTP GET (ou une requête POST ou PUT, d'ailleurs). Il est de la charge utile dans un tel quelle que soit la demande. Donc, s'il n'y a pas de charge utile, il n'y en a pas besoin Content-Type. En pratique, une partie de la mise en œuvre s'est poursuivie et a fait cette hypothèse compréhensible. Cité du commentaire d' Adam :

   "Alors que ... la spécification ne dit pas que vous ne pouvez pas avoir de Content-Type sur un GET, .Net semble l'appliquer dans son HttpClient. Voir cette FAQ SO ."

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

   4.3.1 OBTENIR

   ...

   Une charge utile dans un message de demande GET n'a pas de sémantique définie; l'envoi d'un corps de charge utile sur une demande GET peut entraîner le rejet de la demande par certaines implémentations existantes.

   Donc, si votre HTTP GET inclut une charge utile pour une raison quelconque, un en- Content-Typetête est probablement également raisonnable.

Le problème de ne pas passer le type de contenu sur un message GET est que le type de contenu n'est pas pertinent car le côté serveur détermine de toute façon le contenu. Le problème que j'ai rencontré est qu'il existe maintenant de nombreux endroits qui configurent leurs services Web pour être suffisamment intelligents pour récupérer le type de contenu que vous passez et renvoyer la réponse dans le `` type '' que vous demandez. Par exemple. nous envoyons actuellement un message avec un emplacement par défaut JSON, cependant, ils ont configuré leur service Web de sorte que si vous transmettez un type de contenu de xml, ils renverront alors xml plutôt que leur JSON par défaut. Ce qui, à mon avis, est une excellente idée