HTTP

Antes de pedir nada hay que saber nombrarlo. Una URI es un identificador de recurso: una cadena que designa una cosa de forma inequívoca. Es el concepto general, y de él cuelgan dos formas concretas que se confunden a menudo.

Una URN sigue identificando el mismo recurso aunque este cambie de servidor, precisamente porque no menciona ninguno. Su formato es urn seguido del espacio de nombres y del identificador dentro de ese espacio, como en urn:isbn:9788412345678, donde isbn es la temática y el resto el valor.

https://www.llegandoalcorte.com/estudio/sistemas/internet-http-y-tls?nivel=1#tls

  https           esquema (protocolo)
  www.llegando…   autoridad (nombre de máquina y, si hiciera falta, puerto)
  /estudio/…      ruta del recurso dentro del servidor
  nivel=1         cadena de consulta, tras el signo de interrogación
  tls             fragmento, tras la almohadilla: no viaja al servidor

Toda URL es una URI y toda URN es una URI, pero no al revés. La diferencia está en el verbo: la URL localiza, la URN identifica.

HTTP es el protocolo de la capa de aplicación con el que un cliente pide recursos a un servidor. Funciona con un modelo de petición y respuesta: el cliente envía una petición, el servidor devuelve exactamente una respuesta, y ahí se acaba el intercambio. Hasta HTTP/1.1 los mensajes eran texto legible, igual que en SMTP, POP3 o FTP.

Se apoya en TCP, en el puerto 80 cuando va en claro y en el 443 cuando va sobre TLS. Antes de que salga la primera petición hacen falta dos pasos que no son de HTTP: resolver el nombre del servidor a una dirección IP, que es cosa del servicio de nombres, y establecer la conexión de transporte, que es cosa de TCP. Los dos tienen su tema propio en este bloque.

La decisión de diseño que más consecuencias tiene es que HTTP no tiene estado. El servidor atiende cada petición como si fuese la primera que ve: no recuerda quién preguntó hace un segundo ni qué le contestó. Se pensó así para servir documentos enlazados entre sí, no para sostener aplicaciones con usuarios identificados, y por eso hizo falta añadir por encima un mecanismo que devolviera la memoria perdida, que son las cookies.

Sin estado significa que la petición número dos no sabe nada de la número uno. Todo lo que el servidor necesite saber tiene que venir dentro de cada petición.

Una petición tiene siempre las mismas cuatro partes y en el mismo orden: la línea de petición, las cabeceras, una línea en blanco y, si lo hay, el cuerpo.

1. 1Línea de petición: el método, la ruta del recurso y la versión del protocolo, separados por espacios.
2. 2Cabeceras: una por línea, con el formato nombre, dos puntos y valor. Aportan el contexto de la petición.
3. 3Línea en blanco: no es decorativa, es el separador. Marca dónde acaban las cabeceras.
4. 4Cuerpo: los datos que se envían, si el método los lleva. En un GET normalmente no hay cuerpo.

POST /api/intentos HTTP/1.1
Host: www.llegandoalcorte.com
User-Agent: Mozilla/5.0
Accept: application/json
Accept-Language: es-ES
Accept-Encoding: gzip, deflate
Content-Type: application/json
Content-Length: 74

{"alumno": 482, "tema": "internet-http-y-tls", "aciertos": 47, "total": 50}

La cabecera Host es obligatoria desde HTTP/1.1 y tiene un motivo muy concreto: la petición viaja a una dirección IP, y en una sola dirección IP puede haber alojados decenas de sitios distintos. Sin Host, el servidor no sabría cuál de ellos se le está pidiendo.

La respuesta es simétrica y cambia solo la primera línea. En lugar de una línea de petición lleva una línea de estado, con la versión del protocolo, el código numérico y una frase corta que lo describe y que solo está ahí para que una persona lo lea.

HTTP/1.1 201 Created
Date: Sun, 16 Aug 2026 09:14:22 GMT
Server: nginx
Location: /api/intentos/9137
Content-Type: application/json; charset=utf-8
Content-Length: 58
Cache-Control: no-store

{"id": 9137, "aciertos": 47, "total": 50, "nota": 9.4}

El cuerpo de la respuesta no tiene por qué ser una página: puede ser una imagen, un PDF, un JSON o nada en absoluto. Lo que declara de qué se trata es Content-Type, con un tipo MIME, y lo que declara cuánto ocupa es Content-Length. Si el servidor no sabe de antemano el tamaño, usa Transfer-Encoding: chunked y va enviando el cuerpo por trozos.

Petición y respuesta comparten estructura: primera línea, cabeceras, línea en blanco y cuerpo. Lo único que cambia es esa primera línea, que en la petición lleva el método y en la respuesta el código de estado.

Las cabeceras son el mecanismo con el que cliente y servidor se ponen de acuerdo sin cambiar el protocolo. Las genera el navegador en la petición y el servidor en la respuesta, y casi todas las preguntas van de saber a cuál de los dos lados pertenece cada una.

Conviene fijarse en las parejas que se responden entre sí: Accept-Encoding en la petición con Content-Encoding en la respuesta, Range con Content-Range, Set-Cookie con Cookie, y WWW-Authenticate con Authorization. Reconocer la pareja resuelve la pregunta aunque no se recuerde la definición exacta.

Volver a descargar algo que no ha cambiado es tirar ancho de banda. HTTP lo evita con dos mecanismos encadenados: primero decide cuánto tiempo puede darse por buena una copia guardada, y después, cuando ese tiempo expira, comprueba si de verdad ha cambiado algo antes de descargar de nuevo.

Lo primero lo gobierna Cache-Control. Con max-age el servidor dice cuántos segundos vale la copia. Con no-cache no está prohibiendo guardarla, que es el error de interpretación clásico: está exigiendo que se revalide antes de usarla. Quien prohíbe guardar es no-store.

Lo segundo es la petición condicional. El servidor etiqueta el recurso con ETag, un código calculado a partir de su contenido, y el navegador lo guarda junto a la copia. En la siguiente visita lo devuelve en If-None-Match. Si el código sigue siendo el mismo, el servidor responde 304 Not Modified, sin cuerpo, y el navegador reutiliza lo que ya tenía. Existe la variante por fecha, con Last-Modified en la respuesta e If-Modified-Since en la petición.

GET /temario/internet-http-y-tls HTTP/1.1
Host: www.llegandoalcorte.com
If-None-Match: "a41f9c-2b"


HTTP/1.1 304 Not Modified
ETag: "a41f9c-2b"
Cache-Control: max-age=3600

El 304 es la respuesta a una petición condicional y nunca lleva cuerpo: su mensaje es «lo que tienes guardado sigue valiendo».