¿Qué contiene una respuesta HTTP?
Cada vez que tu navegador carga una página o tu JavaScript llama a fetch(), un servidor envía de vuelta una respuesta HTTP. Ves el resultado — una página renderizada, algunos datos JSON, un mensaje de error — pero la respuesta en sí contiene más estructura de la que la mayoría de los desarrolladores consideran conscientemente. Comprender esa estructura te proporciona un modelo mental más claro al depurar en DevTools o al manejar respuestas en código.
Una respuesta HTTP tiene tres partes: una línea de estado, encabezados y un cuerpo opcional.
Puntos Clave
- Cada respuesta HTTP consta de tres partes: una línea de estado (o pseudo-encabezado
:statusen HTTP/2 y HTTP/3), encabezados y un cuerpo opcional. - Los códigos de estado se agrupan por su primer dígito — 2xx para éxito, 3xx para redirección, 4xx para errores del cliente y 5xx para errores del servidor.
- Los encabezados de respuesta controlan el almacenamiento en caché, seguridad, cookies e interpretación del contenido — le indican al navegador cómo manejar la carga útil, no solo qué es.
- No todos los encabezados de respuesta son accesibles para JavaScript del frontend en solicitudes de origen cruzado. Los servidores deben usar
Access-Control-Expose-Headerspara permitir el acceso más allá del conjunto seguro predeterminado.
La anatomía de una respuesta HTTP: Estado, Encabezados, Cuerpo
La línea de estado
En HTTP/1.1, la respuesta comienza con una única línea de estado:
HTTP/1.1 200 OKEsta línea contiene la versión del protocolo, un código de estado de tres dígitos y una frase de razón legible para humanos. La frase de razón es solo informativa — el código de estado es en lo que los navegadores y clientes realmente actúan.
Los códigos de estado HTTP se agrupan por su primer dígito:
| Rango | Significado |
|---|---|
| 1xx | Informativo (solicitud recibida, el procesamiento continúa) |
| 2xx | Éxito (200 OK, 201 Created, 204 No Content) |
| 3xx | Redirección (301 Moved Permanently, 304 Not Modified) |
| 4xx | Error del cliente (400 Bad Request, 401 Unauthorized, 404 Not Found) |
| 5xx | Error del servidor (500 Internal Server Error, 503 Service Unavailable) |
Una nota sobre HTTP/2 y HTTP/3: La línea de estado textual anterior es específica del formato de transmisión de HTTP/1.1. En HTTP/2 y HTTP/3, no existe una línea de estado. En su lugar, el estado se transmite a través de un pseudo-encabezado :status (por ejemplo, :status: 200). La semántica es idéntica — el código de estado significa lo mismo — pero la representación difiere. DevTools normaliza la representación, por lo que seguirás viendo el código de estado familiar independientemente de la versión del protocolo.
Encabezados de respuesta HTTP: Qué hacen realmente
Los encabezados de respuesta son metadatos. Le indican al navegador cómo manejar la respuesta, no qué es el contenido. Cada encabezado es un nombre insensible a mayúsculas seguido de dos puntos y un valor.
Estas son las categorías que encontrarás con más frecuencia:
Metadatos de contenido
Content-Type: application/json; charset=utf-8— indica al navegador en qué formato está el cuerpo y cómo decodificarlo.Content-Length: 1024— el tamaño del cuerpo en bytes.
Almacenamiento en caché
Cache-Control: max-age=3600, public— instruye al navegador y CDNs durante cuánto tiempo almacenar en caché la respuesta.ETag: "abc123"— una huella digital del recurso, utilizada para solicitudes condicionales. Si el recurso no ha cambiado, el servidor devuelve304 Not Modifieden lugar del cuerpo completo.
Seguridad
Content-Security-Policy— restringe desde qué fuentes el navegador puede cargar scripts, estilos y otros recursos.Strict-Transport-Security— indica al navegador que solo se conecte a través de HTTPS durante una duración especificada.
Cookies
Set-Cookie: session=xyz; HttpOnly; Secure— instruye al navegador a almacenar una cookie. Una sola respuesta puede incluir múltiples encabezadosSet-Cookie, uno por cookie.
Una restricción importante: no todos los encabezados de respuesta son accesibles para JavaScript del frontend. Por defecto, la API Fetch solo expone un pequeño conjunto de encabezados “seguros” de respuestas de origen cruzado. Los servidores deben listar explícitamente encabezados adicionales en Access-Control-Expose-Headers para que tu JavaScript pueda leerlos.
El cuerpo de la respuesta
El cuerpo es la carga útil real — HTML, JSON, una imagen, un archivo. No todas las respuestas tienen uno. Una respuesta 204 No Content o 304 Not Modified omite intencionalmente el cuerpo. En estos casos, el código de estado en sí es el mensaje.
El encabezado Content-Type indica al navegador cómo interpretar lo que llega en el cuerpo.
Discover how at OpenReplay.com.
Características menos comunes que vale la pena conocer
Las respuestas HTTP también pueden incluir respuestas informativas como 103 Early Hints, que permite a los servidores sugerir recursos para precargar antes de que llegue la respuesta principal. Los trailers — encabezados enviados después del cuerpo — existen en HTTP/1.1 (con codificación de transferencia fragmentada) y en HTTP/2 y HTTP/3 como encabezados finales, pero rara vez se encuentran en el trabajo frontend cotidiano. Vale la pena conocerlos, pero no los verás a menudo en DevTools.
Conclusión
Piensa en una respuesta HTTP como un sobre. El código de estado te indica si la entrega tuvo éxito. Los encabezados son instrucciones en el exterior — manejar con cuidado, refrigerar después de abrir, caduca en 24 horas. El cuerpo es lo que hay dentro. Cuando algo falla, verifica primero el código de estado, luego los encabezados — generalmente te dicen exactamente qué salió mal y qué hacer a continuación.
Preguntas Frecuentes
Content-Length especifica el tamaño exacto del cuerpo de la respuesta en bytes. Transfer-Encoding, típicamente configurado como chunked, significa que el cuerpo se envía en fragmentos sin un tamaño total predeterminado. En HTTP/1.1 una respuesta usa uno u otro. La codificación fragmentada es común para contenido generado dinámicamente donde el servidor no conoce el tamaño final de antemano.
Para solicitudes de origen cruzado, la API Fetch solo expone un conjunto limitado de encabezados de respuesta seguros para CORS por defecto. Estos incluyen Cache-Control, Content-Language, Content-Type, Expires, Last-Modified y Pragma. Para acceder a cualquier otro encabezado desde JavaScript, el servidor debe incluirlo en el encabezado de respuesta Access-Control-Expose-Headers.
Usa 204 No Content cuando el servidor procesa exitosamente una solicitud pero no tiene cuerpo que devolver. Esto es común para operaciones DELETE o envíos de formularios donde el cliente no necesita datos actualizados en respuesta. Un 200 OK es más apropiado cuando deseas enviar una carga útil de confirmación o un recurso actualizado de vuelta al cliente.
Abre DevTools con F12 o Ctrl+Shift+I, ve a la pestaña Network y haz clic en cualquier solicitud de la lista. El panel Headers muestra tanto los encabezados de solicitud como de respuesta. También puedes filtrar por tipo de solicitud y buscar nombres de encabezados específicos. La pestaña Response muestra el contenido del cuerpo sin procesar devuelto por el servidor.
Gain control over your UX
See how users are using your site as if you were sitting next to them, learn and iterate faster with OpenReplay. — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data. Check our GitHub repo and join the thousands of developers in our community.
