¿Necesito un encabezado de tipo de contenido para las solicitudes HTTP GET?

Según tengo entendido, hay dos lugares donde configurar el tipo de contenido:

1. El cliente establece un tipo de contenido para el cuerpo que está enviando al servidor (por ejemplo, para publicación)
2. El servidor establece un tipo de contenido para la respuesta.

¿Significa esto que no tengo que establecer un tipo de contenido para todas mis solicitudes de obtención (del lado del cliente)? ¿Y si puedo o debo qué tipo de contenido sería ese?

También leí en algunas publicaciones que el tipo de contenido del cliente especifica qué tipo de contenido le gustaría recibir. ¿Entonces quizás mi punto 1 no es correcto?

De acuerdo con el RFC 7231 sección 3.1.5.5 :

Un remitente que genera un mensaje que contiene un cuerpo de carga DEBE generar un campo de encabezado de tipo de contenido en ese mensaje a menos que el remitente desconozca el tipo de medio deseado de la representación adjunta. Si no hay un campo de encabezado de tipo de contenido, el destinatario PUEDE asumir un tipo de medio de "aplicación / flujo de octetos" ( [RFC2046], sección 4.5.1 ) o examinar los datos para determinar su tipo.

Significa que el Content-Typeencabezado HTTP debe establecerse solo para PUTy POSTsolicitudes.

Las solicitudes de obtención no deben tener tipo de contenido porque no tienen entidad de solicitud (es decir, un cuerpo)

Las solicitudes GET pueden tener encabezados "Aceptar", que indican qué tipos de contenido comprende el cliente. El servidor puede usar eso para decidir qué tipo de contenido devolver.

Sin embargo, son opcionales.

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

La respuesta aceptada es incorrecta. La cita es correcta, la afirmación de que PUT y POST deben tenerla es incorrecta. No hay ningún requisito de que PUT o POST tenga contenido adicional. Tampoco hay una prohibición contra GET que realmente tenga contenido.

Los RFC dicen exactamente lo que quieren decir .. IFF su lado (cliente o servidor de origen) va a enviar contenido adicional, más allá de las cabeceras HTTP, es conveniente especificar una cabecera Content-Type. Pero tenga en cuenta que es permisible omitir el tipo de contenido y aún incluir contenido (por ejemplo, usando un encabezado Content-Length).

Respuesta corta: Lo más probable es que no, no necesite un encabezado de tipo de contenido para las solicitudes HTTP GET. Pero las especificaciones tampoco parecen descartar un encabezado de tipo de contenido para HTTP GET.

Materiales de apoyo:

1. "Content-Type" es parte de los metadatos de representación (es decir, carga útil). Citado de RFC 7231 sección 3.1 :

   3.1. Metadatos de representación

   Los campos de encabezado de representación proporcionan metadatos sobre la representación. Cuando un mensaje incluye un cuerpo de carga útil, los campos del encabezado de representación describen cómo interpretar los datos de representación incluidos en el cuerpo de la carga útil. ...

   Los siguientes campos de encabezado transmiten metadatos de representación:

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

   Citado de RFC 7231 sección 3.1.1.5 (por cierto, la respuesta elegida actual tenía un error tipográfico en el número de sección):

   El campo de encabezado "Tipo de contenido" indica el tipo de medio de la representación asociada

2. En ese sentido, un Content-Typeencabezado no se trata realmente de una solicitud HTTP GET (o una solicitud POST o PUT, para el caso). Se trata de la carga útil en el interior Tal lo solicite. Entonces, si no habrá carga útil, no es necesario Content-Type. En la práctica, alguna implementación siguió adelante e hizo esa suposición comprensible. Citado del comentario de Adam :

   "Si bien ... la especificación no dice que no puede tener Content-Type en un GET, .Net parece imponerlo en su HttpClient. Vea esto SO q & a ".

3. Sin embargo, estrictamente hablando, las especificaciones en sí no descartan la posibilidad de que HTTP GET contenga una carga útil. Citado de RFC 7231 sección 4.3.1 :

   4.3.1 OBTENER

   ...

   Una carga útil dentro de un mensaje de solicitud GET no tiene semántica definida; el envío de un cuerpo de carga útil en una solicitud GET puede causar que algunas implementaciones existentes rechacen la solicitud.

   Entonces, si su HTTP GET incluye una carga útil por cualquier razón, un Content-Typeencabezado probablemente también sea razonable.

El problema con no pasar el tipo de contenido en un mensaje GET es que el tipo de contenido es irrelevante porque el lado del servidor determina el contenido de todos modos. El problema que he encontrado es que ahora hay muchos lugares que configuran sus servicios web para ser lo suficientemente inteligentes como para recoger el tipo de contenido que pasa y devolver la respuesta en el 'tipo' que solicita. P.ej. actualmente estamos enviando mensajes con un lugar que está predeterminado en JSON, sin embargo, han configurado su servicio web para que si pasa un tipo de contenido de xml, devolverán xml en lugar de su valor predeterminado JSON. Lo cual creo que en el futuro es una gran idea