web-dev-qa-db-fra.com

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

Autant que je sache, il existe 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 post).
  2. Le serveur définit un type de contenu pour la réponse.

Cela signifie-t-il que je n'ai pas ou ne devrais pas définir de type de contenu pour toutes mes demandes d'obtention (côté client)? Et si je peux ou devrais quel type de contenu serait-ce?

De plus, j'ai 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?

131
Martin Flucka

Selon le RFC 7231 section 3.1.5.5 :

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

Cela signifie que le Content-Type L'en-tête HTTP ne devrait être défini que pour les requêtes PUT et POST.

87
Epoc

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)

62
Dmitry Negoda

Les demandes GET peuvent avoir des en-têtes "Accepter", qui indiquent quels types de contenu sont compris par le client. Le serveur peut ensuite l'utiliser pour décider du type de contenu à renvoyer.

Ils sont facultatifs si.

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

32
Matthew Wilson

La réponse acceptée est fausse. La citation est correcte, l'affirmation que PUT et POST doit l'avoir est incorrecte. Il n'est pas nécessaire que PUT ou POST comporte en fait un contenu supplémentaire. Ni il existe une interdiction d'obtenir réellement du contenu.

Les RFC disent exactement ce qu’ils veulent dire. SI C’EST votre côté (client OR 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 il est permis d'omettre le type de contenu et d'inclure le contenu (par exemple, en utilisant un en-tête Content-Length).

23
user4157069