Preciso de um cabeçalho do tipo de conteúdo para solicitações HTTP GET?

Tanto quanto eu entendi, existem dois lugares onde definir o tipo de conteúdo:

1. O cliente define um tipo de conteúdo para o corpo que está enviando para o servidor (por exemplo, para postagem)
2. O servidor define um tipo de conteúdo para a resposta.

Isso significa que não preciso definir um tipo de conteúdo para todas as minhas solicitações get (lado do cliente). E se eu posso ou devo que tipo de conteúdo seria esse?

Também li em algumas postagens que o tipo de conteúdo do cliente especifica que tipo de conteúdo o cliente gostaria de receber. Então, talvez o meu ponto 1 não esteja certo?

De acordo com a seção 3.1.5.5 da RFC 7231 :

Um remetente que gera uma mensagem contendo um corpo de carga útil deve gerar um campo de cabeçalho de tipo de conteúdo nessa mensagem, a menos que o tipo de mídia pretendido da representação em anexo seja desconhecido para o remetente. Se um campo de cabeçalho Content-Type não estiver presente, o destinatário PODE assumir um tipo de mídia de "aplicativo / fluxo de octetos" ( [RFC2046], Seção 4.5.1 ) ou examinar os dados para determinar seu tipo.

Isso significa que o Content-Typecabeçalho HTTP deve ser definido apenas para PUTe POSTsolicitações.

As solicitações de obtenção não devem ter o tipo de conteúdo porque elas não possuem uma entidade de solicitação (ou seja, um corpo)

As solicitações GET podem ter cabeçalhos "Aceitar", que indicam quais tipos de conteúdo o cliente entende. O servidor pode usá-lo para decidir qual tipo de conteúdo enviar.

Eles são opcionais.

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

A resposta aceita está errada. A cotação está correta, a afirmação de que PUT e POST devem tê-la está incorreta. Não há exigência de que PUT ou POST realmente tenham conteúdo adicional. Também não existe uma proibição de que o GET realmente tenha conteúdo.

Os RFCs dizer exatamente o que eles querem dizer .. IFF seu lado (cliente ou servidor de origem) será o envio de conteúdo adicional, além dos cabeçalhos HTTP, ele deve especificar um cabeçalho Content-Type. Mas observe que é permitido omitir o Tipo de Conteúdo e ainda incluir conteúdo (por exemplo, usando um cabeçalho Comprimento do Conteúdo).

Resposta curta: Muito provavelmente, não, você não precisa um cabeçalho do tipo de conteúdo para solicitações HTTP GET. Mas as especificações também não parecem excluir um cabeçalho de tipo de conteúdo para HTTP GET.

Materiais de suporte:

1. "Tipo de conteúdo" faz parte dos metadados da representação (por exemplo, carga útil). Citado na seção 3.1 da RFC 7231 :

   3.1 Metadados de Representação

   Os campos do cabeçalho da representação fornecem metadados sobre a representação. Quando uma mensagem inclui um corpo de carga útil, os campos do cabeçalho da representação descrevem como interpretar os dados de representação incluídos no corpo da carga útil. ...

   Os seguintes campos de cabeçalho transmitem metadados de representação:

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

   Citado na seção 3.1.1.5 da RFC 7231 (a propósito, a resposta escolhida atual teve um erro de digitação no número da seção):

   O campo de cabeçalho "Tipo de conteúdo" indica o tipo de mídia da representação associada

2. Nesse sentido, um Content-Typecabeçalho não é realmente sobre uma solicitação HTTP GET (ou uma solicitação POST ou PUT, nesse caso). É sobre a carga útil dentro de qualquer solicitação. Portanto, se não houver carga útil, não será necessário Content-Type. Na prática, alguma implementação foi adiante e fez essa suposição compreensível. Citado no comentário de Adam :

   "Embora ... as especificações não digam que você não possa ter o Tipo de Conteúdo em um GET, o .Net parece aplicá-lo no seu HttpClient. Veja estas perguntas e respostas ."

3. No entanto, estritamente falando, as especificações em si não descartam a possibilidade de o HTTP GET conter uma carga útil. Citado na seção 4.3.1 da RFC 7231 :

   4.3.1 GET

   ...

   Uma carga útil dentro de uma mensagem de solicitação GET não possui semântica definida; o envio de um corpo de carga útil em uma solicitação GET pode fazer com que algumas implementações existentes rejeitem a solicitação.

   Portanto, se o seu HTTP GET incluir uma carga útil por qualquer motivo, um Content-Typecabeçalho provavelmente também será razoável.

O problema de não passar o tipo de conteúdo em uma mensagem GET é que, com certeza, o tipo de conteúdo é irrelevante porque o lado do servidor determina o conteúdo de qualquer maneira. O problema que encontrei é que agora existem muitos lugares que configuram seus serviços da web para serem inteligentes o suficiente para escolher o tipo de conteúdo que você passa e retornar a resposta no 'tipo' solicitado. Por exemplo. No momento, estamos enviando mensagens para um local com o padrão JSON, no entanto, eles configuraram o serviço da Web para que, se você passar um tipo de conteúdo de xml, eles retornem o xml em vez do padrão JSON. Que eu acho que daqui para frente é uma ótima idéia