Solicitudes y respuestas HTTP: cómo leerlas

1. El intercambio HTTP

Al terminar podrás abrir el panel de red del navegador, elegir una transacción y explicar quién la inició, qué pidió el cliente, qué decidió el servidor y qué parte del resultado es observación o inferencia. HTTP define una interfaz uniforme: el cliente expresa una intención mediante una solicitud y el servidor devuelve una o más respuestas, con una única respuesta final.

Piensa en cinco piezas: método, recurso objetivo, campos, contenido opcional y respuesta. La semántica se mantiene entre HTTP/1.1, HTTP/2 y HTTP/3, pero cambia su representación en el transporte. El formato textual que usamos para aprender corresponde a HTTP/1.1. HTTP/2 y HTTP/3 transmiten campos y datos en tramas, por lo que el navegador puede mostrar una reconstrucción legible y no los bytes exactos del cable.

2. Lee la solicitud de arriba abajo

En HTTP/1.1, la primera línea contiene método, objetivo y versión. Después aparecen los campos de cabecera, una línea vacía y, cuando el método y la operación lo requieren, contenido. La URL ayuda a construir el objetivo, pero no cuenta toda la solicitud.

1. Método: GET pide transferir una representación actual del recurso.
2. Objetivo: la ruta identifica el recurso y la query aporta parámetros. El fragmento que empieza por # se procesa en el cliente y no se envía en la solicitud HTTP.
3. Autoridad: Host permite distinguir el sitio de destino. En HTTP/2 se representa normalmente como :authority.
4. Preferencias: Accept y Accept-Language ayudan a seleccionar una representación, pero no garantizan que el servidor pueda ofrecerla.
5. Contenido: es opcional y su significado depende del método. Content-Type describe lo que se envía; Accept describe lo que el cliente prefiere recibir.

3. La respuesta combina resultado y representación

La respuesta empieza con un código de estado, continúa con campos y puede terminar con contenido. El código resume el resultado HTTP, mientras que los campos añaden contexto y el cuerpo puede contener el recurso, el resultado de una acción o una explicación del error.

200 indica éxito para esa operación, no que el contenido sea correcto para el negocio.Content-Type explica cómo interpretar los bytes. Cache-Control define condiciones de reutilización. Algunas respuestas no llevan contenido por definición: las respuestas a HEAD, los estados 204 y 304, y todas las respuestas informativas 1xx.

4. Método y estado se interpretan juntos

El método comunica intención. GET y HEAD son seguros porque no solicitan cambiar el estado del recurso. PUT y DELETE son idempotentes: repetir una solicitud idéntica debe perseguir el mismo efecto previsto, aunque cada intento pueda generar logs o respuestas distintas.POST pide procesamiento específico del recurso y no es idempotente por definición.

5. Captura una transacción en el navegador

Abre las herramientas de desarrollo, entra en Network o Red y recarga esta guía. Selecciona la fila cuyo tipo sea document. Si hay demasiadas entradas, filtra porDoc. No actives Disable cache en la primera captura: interesa observar el comportamiento normal antes de modificarlo.

1. En Headers, registra método, URL, protocolo y estado.
2. Separa Request Headers de Response Headers. Localiza Accept, Content-Type y reglas de caché si existen.
3. Abre Response o Preview y describe qué representación llegó, sin copiar datos sensibles.
4. Revisa Timing. Anota la medición, pero no atribuyas una espera al servidor con una sola captura.
5. Recarga una segunda vez y compara estado, tamaño transferido, caché y cadena de redirecciones.

6. Verifica el mismo modelo con curl

Este ejercicio fuerza HTTP/1.1 para que la salida se parezca al formato textual estudiado y descarta el cuerpo. No modifica el destino. En Linux y macOS usa curl; en Windows PowerShell invocacurl.exe para evitar ambigüedad con alias de versiones antiguas.

En la salida verbose, > marca datos enviados, < datos recibidos y *mensajes internos de curl. Esos prefijos no forman parte de HTTP. Si el navegador negocia HTTP/2 o HTTP/3, método, destino, campos y estado conservan su significado aunque la representación sobre el transporte cambie.

7. Diagnostica sin saltar a la causa

• □Puedo identificar cliente, intermediarios posibles y servidor de origen
• □Distingo URL, método, campos y contenido de la solicitud
• □Interpreto el estado junto con el método y los campos de respuesta
• □Sé cuándo una respuesta no debe incluir contenido
• □Separo una medición observable de una explicación todavía no confirmada
• □He saneado cookies, tokens y datos personales antes de guardar o compartir evidencia

Glosario