Consulta de encabezados HTTP

La Consulta de encabezados HTTP es una herramienta gratuita que obtiene todos los encabezados de respuesta HTTP que devuelve una URL ante una solicitud GET habitual.

¿Qué son los encabezados de respuesta HTTP?

Los encabezados de respuesta HTTP son metadatos que un servidor web envía antes del cuerpo de la respuesta, como una página HTML, una imagen o un documento JSON. Indican al cliente cómo interpretar, almacenar en caché, redirigir o proteger la respuesta.

Una respuesta HTTP/1.x suele comenzar con una línea de estado HTTP, seguida de los encabezados. En HTTP/2 y HTTP/3, el estado equivalente se incluye en el pseudoencabezado :status. Aunque técnicamente la línea de estado HTTP/1.x no forma parte de los encabezados, suele mostrarse junto a ellos porque permite saber si la solicitud se ha completado correctamente. Un estado 200 significa que se ha devuelto el recurso, 301 o 302 indica una redirección, 404 significa que no se ha encontrado el recurso y 500 señala un error del servidor.

Los encabezados pueden proceder del servidor de origen, de un proxy inverso o de una red de distribución de contenido como Cloudflare. Algunos se añaden o eliminan a medida que la respuesta atraviesa estos sistemas, por lo que el resultado puede ofrecer información que va más allá de la aplicación que generó la página.

¿Cómo consulto los encabezados HTTP?

Introduce la URL completa que quieras comprobar, incluido el esquema, por ejemplo, https://www.example.com/account. La herramienta envía desde su servidor una solicitud GET habitual y devuelve los encabezados HTTP recibidos de esa URL.

Para comparar los encabezados de respuesta con precisión, utiliza exactamente las variantes de la URL que quieras analizar. Los encabezados de http://example.com, https://example.com y https://www.example.com pueden ser distintos, ya que cada dirección puede tener sus propias redirecciones, reglas de caché y configuración del servidor.

La sintaxis de la URL también afecta a la solicitud:

• Los espacios no son caracteres válidos sin codificar en una URL y normalmente deben codificarse mediante porcentajes, habitualmente como %20 dentro de una ruta.
• ? marca el inicio del componente de consulta, mientras que & y = suelen emplearse en la codificación de consultas con formato de formulario, aunque no cumplen esas funciones en todas las cadenas de consulta.
• Los nombres de dominio con caracteres acentuados o no latinos se procesan mediante IDNA y se representan como etiquetas A en ASCII, que suelen comenzar por xn--. Por su parte, los caracteres de la ruta normalmente se codifican primero como bytes UTF-8 y después mediante porcentajes.
• El navegador gestiona los fragmentos que comienzan por #, por lo que no se envían en la solicitud HTTP.
• No existe una longitud máxima universal para las URL. Un servidor, proxy o aplicación puede rechazar las URL muy largas.

¿Cómo interpreto el resultado de los encabezados HTTP?

Examina los encabezados relacionados con el problema que estés investigando. Los nombres de los encabezados no distinguen entre mayúsculas y minúsculas, aunque la sintaxis de sus valores sí puede hacerlo.

Otros encabezados pueden ser específicos de una aplicación. Por ejemplo, Access-Control-Allow-Origin controla qué orígenes pueden leer una respuesta mediante solicitudes entre orígenes realizadas por el navegador. Un encabezado Server puede identificar un software o proxy, pero no demuestra de forma fiable cuál es la plataforma subyacente, ya que los administradores pueden modificarlo o eliminarlo.

Casos prácticos de resolución de problemas

Los problemas de redirección son uno de los motivos más habituales para examinar los encabezados. Supón que https://example.com/old-page devuelve el estado 301 con Location: https://example.com/new-page. Esto significa que el servidor indica al cliente que solicite la nueva dirección. Comprobar sucesivamente cada destino puede ayudarte a detectar un bucle de redirección o un cambio inesperado entre HTTP y HTTPS.

Si una página detrás de Cloudflare u otra CDN muestra contenido desactualizado, examina Cache-Control, Age, ETag y cualquier encabezado de caché específico del proveedor. Un valor elevado de Age indica la antigüedad calculada de la respuesta almacenada en caché, que puede incluir el tiempo transcurrido en cachés ascendentes, no cuánto tiempo la ha conservado un intermediario concreto. Tampoco demuestra que todas las cachés regionales tengan la misma versión.

Cuando una API funciona en un script del servidor, pero falla en el navegador, revisa Content-Type y los encabezados de respuesta CORS, incluido Access-Control-Allow-Origin. Si un endpoint JSON devuelve text/html, es posible que en realidad esté mostrando una página de error o una pantalla de inicio de sesión. La ausencia de permisos entre orígenes puede hacer que el navegador bloquee el acceso aunque el servidor haya devuelto el estado 200.

Los encabezados también pueden ayudar a investigar un sitio que parece no estar disponible. Una respuesta 503 apunta a un fallo temporal del servidor o de un sistema ascendente, mientras que un 404 significa que no se ha encontrado la ruta solicitada. Sin embargo, no permiten diagnosticar todos los fallos. Si la resolución DNS, la conexión TCP o la negociación TLS falla antes de que exista una respuesta HTTP, quizá no haya encabezados de respuesta que examinar. La Prueba de ping permite comprobar la conectividad por separado, mientras que la Verificación de HTTP/2 sirve para comprobar la compatibilidad con ese protocolo.

¿Por qué un resultado correcto puede parecer erróneo?

Un resultado correcto puede diferir de lo que muestra tu navegador porque las cachés, los registros DNS y el contexto de la solicitud pueden hacer que ambas solicitudes obtengan respuestas distintas. Esta consulta se ejecuta en el servidor, por lo que puede llegar a otro nodo de la CDN o resolver un registro DNS modificado recientemente antes o después que tu red local.

Además, los navegadores envían sus propias cookies, tipos de contenido aceptados, idiomas y validadores de caché. Por eso, una página de WordPress en la que has iniciado sesión puede devolver reglas de caché diferentes a las de una solicitud anónima realizada desde un servidor. El enrutamiento geográfico y los sistemas de gestión de bots también pueden variar la respuesta según la red de origen o los encabezados de la solicitud.

Después de modificar el DNS, los resolvedores con caché pueden seguir utilizando el registro anterior hasta que caduque su tiempo de vida. Una vez que el tráfico llega al nuevo servidor, un objeto antiguo de la CDN o la caché del navegador todavía puede devolver contenido previo. Comprueba por separado el host resuelto, vacía las cachés cuando corresponda y compara la URL exacta en lugar de asumir que todos los nombres de host utilizan la misma configuración.

Preguntas frecuentes

¿Esta consulta muestra los encabezados de la solicitud?

No. Obtiene los encabezados de respuesta que devuelve la URL ante una solicitud GET habitual. Los encabezados de solicitud son los metadatos enviados al servidor. Para examinarlos por completo, necesitas las herramientas para desarrolladores del navegador, los registros del servidor o un cliente de línea de comandos.

¿Son privadas las URL que introduzco en la herramienta?

Las URL que introduces no se almacenan, pero la consulta se realiza en el servidor. La URL viaja hasta ese servidor mediante HTTPS. Evita introducir URL que contengan contraseñas, tokens de acceso o parámetros de consulta confidenciales, ya que el servidor de destino también recibirá esos valores cuando se realice la solicitud.

¿Los encabezados HTTP pueden explicar una advertencia sobre el certificado?

Por sí solos, normalmente no. La conexión TLS se establece antes de enviar la respuesta HTTP, por lo que un certificado caducado, un nombre de host que no coincide o un emisor que no es de confianza puede impedir que se devuelva cualquier encabezado. Si la advertencia del navegador aparece antes de que se cargue la página, examina por separado el certificado y su cadena.

¿Por qué aparecen varios encabezados Set-Cookie?

Porque una respuesta puede establecer más de una cookie, y cada una utiliza su propio campo Set-Cookie. No los combines como si fueran una lista separada por comas, ya que las fechas de caducidad de las cookies también pueden contener comas. Revisa por separado el dominio, la ruta y los atributos de seguridad de cada cookie.

¿Puedo comparar el resultado con curl?

Sí. Un comando como curl -D - https://example.com/ -o /dev/null muestra los encabezados de respuesta y descarta el cuerpo. La versión de curl, los encabezados de la solicitud, la configuración de las redirecciones y la ubicación de red pueden producir resultados distintos. Asegúrate de que esas condiciones coincidan antes de interpretar una diferencia como un fallo del servidor.