De una dirección a una página.

https://pokeatlas.test/index.html

pokeatlas.test → 192.0.2.10

Destino de ejemplo: 192.0.2.10:443
TLS: conexión cifrada y certificado válido

Destino de ejemplo: 192.0.2.10:80
Sin TLS: comunicación no cifrada por HTTPS

GET /index.html HTTP/1.1
Host: pokeatlas.test
Accept: text/html

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8

<h1>Bienvenido a PokéAtlas</h1>

HTTP/1.1 404 Not Found
Content-Type: text/html; charset=utf-8

<h1>Página no encontrada</h1>

HTTP/1.1 500 Internal Server Error
Content-Type: text/html; charset=utf-8

<h1>No pudimos preparar la página</h1>

Recorrido simplificado: las cachés, las conexiones reutilizadas, los intermediarios y las versiones del protocolo pueden cambiar el trabajo necesario en una visita real.

https://pokeatlas.test:443/pokedex.html?region=kanto#resultados

Esquema · https

Indica cómo acceder al recurso.

Nombre del servidor · pokeatlas.test

Nombre que puede resolverse mediante DNS. Una URL también puede utilizar una IP.

Puerto · 443

Identifica el servicio del destino. Si se omite, se usa el predeterminado del esquema.

Ruta · /pokedex.html

Identifica el recurso; no tiene que corresponder a un archivo físico.

Consulta · ?region=kanto

Transporta parámetros. Su significado lo define la aplicación.

Fragmento · #resultados

Lo interpreta el navegador, por ejemplo para ir a una sección. No se envía al servidor en la petición HTTP.

1. Se comprueba la caché

   El navegador, el sistema o el resolvedor pueden tener información reutilizable. La caché evita repetir trabajo.

2. El resolvedor busca una respuesta

   Si necesita buscarla, puede consultar la jerarquía DNS: raíz, dominio de nivel superior y servidores autoritativos.

3. Se obtiene el registro

   Un registro A contiene una dirección IPv4; AAAA, una IPv6. Un nombre puede tener varias direcciones.

TTL: indica cuánto tiempo puede conservarse un registro en caché. Un cambio DNS puede tardar en verse porque todavía hay respuestas anteriores guardadas; no existe una espera universal idéntica para todos.

En tu proyecto: el dominio es el nombre; el hosting sirve los recursos; los registros DNS conectan ese nombre con el destino. Ninguno sustituye a index.html.

Referencia: DNS en MDN

POST /api/comentarios HTTP/1.1
Host: pokeatlas.test
Content-Type: application/json

{"texto":"Mi Pokémon favorito es Eevee"}

HTTP/1.1 201 Created
Content-Type: application/json

{"id":42,"texto":"Mi Pokémon favorito es Eevee"}

El ejemplo de comentarios es ficticio. No hay un servidor que guarde comentarios en estos proyectos.

La API define qué métodos admite cada ruta. Usar POST no cifra los datos; la protección del transporte corresponde a HTTPS.

Relación con JavaScript: fetch() no rechaza automáticamente su promesa por una respuesta 404 o 500. Comprueba response.ok o response.status antes de leer los datos.

const response = await fetch("https://pokeapi.co/api/v2/pokemon/25");
if (!response.ok) {
  throw new Error(`Respuesta HTTP: ${response.status}`);
}
const pokemon = await response.json();
console.log(pokemon.name);

Este bloque es un ejemplo para estudiar. Practica fetch en el laboratorio JavaScript.

Referencia: mensajes HTTP · Referencia: estados HTTP

APRENDE A DIAGNOSTICAR

404 y otros errores HTTP

Abre cada código para conocer su significado, un caso cotidiano y qué revisar. Los códigos describen una respuesta: por sí solos no explican toda la causa del fallo.

Las cinco familias: 1xx informa del progreso; 2xx indica éxito; 3xx trata redirecciones o validación de caché; 4xx señala un problema con la solicitud; 5xx señala un fallo del servidor. Un 301 o un 304 no es un error.

¿Es HTTP o es otro tipo de error?

• DNS: el dominio no se puede resolver; puede no haber respuesta HTTP.
• Conexión o TLS: falla el acceso o la conexión segura antes de recibir una respuesta.
• CORS: el navegador impide que JavaScript lea una respuesta por las reglas de acceso entre orígenes; no es un código HTTP.
• JavaScript: SyntaxError, ReferenceError o TypeError son errores del programa; consulta la consola.

Revisa un 404 paso a paso

1. Abre las herramientas del navegador y la pestaña Network (Red).
2. Recarga la página y selecciona la petición con estado 404.
3. Comprueba la URL completa, método y respuesta: puede fallar el HTML, una imagen, el CSS o una API.
4. Corrige la ruta o el recurso y vuelve a comprobar. En producción, revisa también las reglas del alojamiento.

HTML no establece el estado HTTP: escribir «404» en una página no convierte una respuesta 200 en 404. El servidor o la plataforma de alojamiento debe enviar el estado correcto. Una página de error útil puede ofrecer un enlace al inicio y una explicación clara.

Prueba 404 y 500 en la simulación · Relacionarlo con HTML y SEO

Fuente: MDN: códigos de estado HTTP.

Referencia: HTTPS en MDN

1. Abre las herramientas del navegador

   Entra en la pestaña Network / Red y recarga la página.

2. Elige un recurso

   Examina su dirección, método, estado, tipo, tiempo y cabeceras.

3. Lee la respuesta

   Comprueba si recibiste HTML, JSON, un mensaje de error o una respuesta desde caché.

En PokéAtlas, compara la carga de index.html con la petición a pokeapi.co. Son servidores y recursos diferentes.