Content-Type
Uso
La cabecera Content-Type indica al cliente (o al servidor, en el caso de los cuerpos de solicitud) el tipo de medio del contenido incluido. El tipo de medio determina cómo el destinatario analiza y representa el cuerpo. Sin esta cabecera, los clientes recurren al MIME sniffing, lo que introduce riesgos de seguridad y comportamientos inconsistentes.
Nota
Accept declara lo que el cliente quiere recibir. Content-Type declara lo que se está enviando. Accept aparece en las solicitudes. Content-Type aparece tanto en las solicitudes (cuando hay cuerpo) como en las respuestas. Las solicitudes GET normalmente no tienen cuerpo y no necesitan Content-Type. Las solicitudes POST y PUT con cuerpo requieren la cabecera.
Un tipo de medio se compone de un tipo de nivel superior y un subtipo separados por una barra, seguidos opcionalmente de parámetros. La cabecera de solicitud Accept funciona junto con Content-Type durante la negociación de contenido, permitiendo al cliente expresar sus tipos de medio preferidos antes de que el servidor seleccione uno.
Los servidores y los intermediarios a veces aplican Content-Encoding (como gzip o br) antes de la transmisión. La cabecera Content-Type siempre describe el tipo de medio original anterior a la codificación, no el formato codificado.
La cabecera MIME-Version se remonta al origen de los tipos MIME en el correo electrónico y aparece en algunos mensajes HTTP, aunque HTTP no exige esa cabecera para el procesamiento del tipo de medio.
media-type
El valor del tipo de medio sigue el formato type/subtype registrado en IANA. Entre los tipos habituales están text/html, application/json, image/png y application/octet-stream. IANA mantiene un registro completo.
charset
El parámetro charset especifica la codificación de caracteres de los tipos de medio basados en texto. UTF-8 es la codificación dominante en la Web.
Content-Type: text/html; charset=UTF-8boundary
El parámetro boundary es obligatorio para los tipos de medio multipart/*. La cadena boundary separa cada parte del cuerpo multiparte. El valor de boundary no debe aparecer dentro de ninguna de las partes del cuerpo.
Content-Type: multipart/form-data; boundary=----FormBoundaryEjemplo
Un servidor devuelve una página HTML con codificación UTF-8. El navegador usa el tipo de medio para representar el contenido como una página web y el charset para decodificar el texto correctamente.
Content-Type: text/html; charset=UTF-8Una API devuelve una respuesta JSON. El tipo de medio application/json indica al cliente que analice el cuerpo como JSON.
Content-Type: application/jsonUna respuesta de error de una API usa el tipo de medio application/problem+json para señalar una carga útil estructurada con los detalles del problema.
Content-Type: application/problem+jsonUna CDN convierte una página HTML a Markdown sobre la marcha cuando el cliente envía Accept: text/markdown. La respuesta lleva text/markdown como tipo de contenido, indicando que el cuerpo es Markdown y no HTML.
Content-Type: text/markdown; charset=utf-8Agentes de IA y Content-Type
Proveedores de CDN como Cloudflare devuelven Content-Type: text/markdown junto con una cabecera x-markdown-tokens que estima el número de tokens del documento convertido. Los agentes usan el tipo de contenido para seleccionar el analizador correcto y la estimación de tokens para gestionar el presupuesto de la ventana de contexto.
Una subida de archivos usa multipart/form-data con una cadena boundary que separa los campos del formulario y los datos del archivo dentro del cuerpo de la solicitud.
Content-Type: multipart/form-data; boundary=----WebKitFormBoundary7MA4YWxkTrZu0gWUn servidor entrega la descarga de un archivo binario. El tipo application/octet-stream señala datos binarios en bruto y suele combinarse con una cabecera Content-Disposition establecida en attachment.
Content-Type: application/octet-streamUna respuesta multipart/byteranges entrega varios rangos de bytes de un mismo recurso. Cada parte tiene su propia cabecera Content-Type y Content-Range.
Content-Type: multipart/byteranges; boundary=THIS_STRING_SEPARATESDiagnóstico
Los fallos de representación y los errores de análisis suelen tener su origen en una cabecera Content-Type ausente o incorrecta.
La falta del parámetro charset provoca texto ilegible. Los navegadores recurren a una codificación predeterminada (a menudo ISO-8859-1) cuando no se declara ningún charset. Los caracteres no ASCII aparecen como mojibake. Añada el parámetro charset de forma explícita: Content-Type: text/html; charset=UTF-8. En nginx:
charset utf-8;En Apache:
AddDefaultCharset UTF-8El navegador aplica MIME sniffing pese a un Content-Type correcto. Los navegadores a veces ignoran el tipo declarado y husmean el contenido del cuerpo para determinar el tipo. Este comportamiento crea vectores de ataque XSS cuando se sirve como HTML contenido subido por los usuarios. Añada la cabecera X-Content-Type-Options con el valor nosniff para bloquear el MIME sniffing:
X-Content-Type-Options: nosniffLa API devuelve text/html en lugar de application/json. Los clientes que analizan JSON procedente de una API reciben páginas de error HTML o respuestas predeterminadas del framework. Esto ocurre cuando un manejador de errores o un proxy inverso intercepta la respuesta y sustituye el cuerpo sin actualizar el Content-Type. Revise toda la cadena de respuesta: servidor de origen, framework de la aplicación, proxy inverso y CDN. En Express.js, llamar a res.json() establece la cabecera correcta automáticamente. En Django, devuelva JsonResponse en lugar de HttpResponse.
Una discrepancia en el boundary multiparte rompe las subidas de archivos. La cadena boundary declarada en la cabecera Content-Type debe coincidir con el delimitador usado en el cuerpo de la solicitud. Una discrepancia hace que el servidor no logre analizar el cuerpo multiparte. Inspeccione la solicitud en bruto en la pestaña Network de DevTools, en las secciones Headers y Payload. Evite establecer el boundary manualmente cuando use fetch() o XMLHttpRequest con objetos FormData. El navegador genera el boundary correcto automáticamente cuando se omite la cabecera Content-Type de la solicitud.
El Content-Type predeterminado del framework anula un valor establecido explícitamente. Algunos frameworks establecen Content-Type después de que se ejecute el código de la aplicación. El middleware de Express.js, Django o Spring Boot puede restablecer la cabecera. Revise el orden de ejecución del middleware. En Express.js, asegúrese de que res.type() o res.set(‘Content-Type’, …) se llame después de todo el middleware que modifique cabeceras.
Diagnóstico de problemas de Content-Type con DevTools. Abra la pestaña Network de DevTools del navegador, seleccione la solicitud e inspeccione la sección Response Headers para ver el valor de Content-Type. Compare el tipo declarado con el contenido real del cuerpo que se muestra en la pestaña Response o Preview. Use curl -I https://example.re/api/data para comprobar las cabeceras desde la línea de comandos sin interferencia del navegador.