HEAD

Uso

Una solicitud HEAD recupera metadatos sobre un recurso: tamaño, tipo, frescura y existencia. El servidor procesa la solicitud exactamente igual que un GET, pero se detiene antes de transmitir el cuerpo. Todas las cabeceras de respuesta, incluidas Content-Length y Content-Type, coinciden con las de una respuesta GET completa.

Casos de uso habituales

Validación de enlaces. Las herramientas automatizadas envían solicitudes HEAD para verificar que las URL devuelven 200 sin descargar las páginas completas. Los enlaces rotos aparecen como respuestas 404 o 410.

Monitorización y comprobaciones de estado. Los monitores de disponibilidad sondean los endpoints con HEAD para confirmar que están disponibles. El menor tamaño de la respuesta reduce el ancho de banda y acelera los intervalos de sondeo.

Sondeo de negociación de contenido. Los clientes inspeccionan las cabeceras Content-Type, Content-Encoding y Content-Language antes de decidir si recuperan el recurso completo.

Validación de caché. Una respuesta HEAD que incluye ETag o Last-Modified permite a las cachés comprobar la frescura sin descargar el cuerpo. Si las cabeceras de la respuesta HEAD indican que una copia almacenada está obsoleta, la caché marca la entrada en consecuencia.

Estimación del tamaño de descarga. Los gestores de archivos y las herramientas de descarga leen Content-Length de una respuesta HEAD para mostrar el tamaño del archivo o reservar espacio en disco antes de iniciar la transferencia.

Nota

Un cuerpo en una solicitud HEAD no tiene una semántica generalmente definida. Algunas implementaciones rechazan las solicitudes HEAD que llevan cuerpo. Incluir un cuerpo arriesga desencadenar vulnerabilidades de contrabando de solicitudes en intermediarios que interpretan mal el entramado del mensaje.

Ejemplo

Una solicitud HEAD para comprobar si un recurso existe e inspeccionar las cabeceras de respuesta. El servidor devuelve 200 con metadatos del contenido pero sin cuerpo.

Solicitud

HEAD /report.pdf HTTP/1.1
Host: example.com

Respuesta

HTTP/1.1 200 OK
Content-Type: application/pdf
Content-Length: 284750
Last-Modified: Mon, 10 Feb 2025 08:30:00 GMT
ETag: "f47ac10b"

La cabecera Content-Length revela que el archivo ocupa aproximadamente 278 KB. Las cabeceras Last-Modified y ETag proporcionan validadores para las solicitudes condicionales en recuperaciones posteriores.

CORS

HEAD es un método incluido en la lista segura de CORS. Las solicitudes HEAD de origen cruzado no desencadenan una comprobación previa, siguiendo el mismo comportamiento de lista segura que GET.

HEAD frente a GET

HEAD devuelve las mismas cabeceras que GET, pero omite por completo el cuerpo de la respuesta. Esto hace que HEAD sea más rápido y más eficiente en ancho de banda para tareas que solo necesitan metadatos.

Entre las aplicaciones habituales están comprobar si un recurso existe, leer Content-Length para conocer el tamaño del archivo, inspeccionar las fechas de Last-Modified y obtener validadores de caché como ETag sin descargar el recurso completo.

Algunos servidores implementan HEAD ejecutando internamente el manejador completo de GET y eliminando el cuerpo antes de enviar la respuesta. En esos casos, el beneficio de rendimiento se limita al tiempo de transferencia ahorrado únicamente por los bytes del cuerpo.

Las respuestas HEAD también actualizan las respuestas GET almacenadas en caché. Cuando una caché envía una solicitud HEAD y los validadores devueltos coinciden con una entrada GET almacenada, la caché actualiza las cabeceras guardadas en consecuencia.

Impacto en SEO

Los rastreadores de búsqueda recuperan las páginas con GET, no con HEAD, por lo que HEAD no impulsa la indexación. HEAD sigue siendo útil para verificadores de enlaces, monitores de disponibilidad y herramientas de auditoría SEO que confirman que una URL devuelve 200 sin descargar el cuerpo.