HEAD y OPTIONS: qué responden y para qué los usan los clientes

Qué es

HEAD, según RFC 9110, es idéntico a GET salvo que el servidor NO DEBE enviar contenido. El servidor DEBERÍA enviar los mismos campos de encabezado que enviaría para GET, pero PUEDE omitir campos cuyo valor solo se conoce al generar el contenido, como Content-Length o Vary en una respuesta dinámica almacenada en búfer. Un cuerpo en una solicitud HEAD no tiene un significado definido y puede provocar el cierre de la conexión por sospecha de un intento de contrabando de solicitudes (request smuggling). Las respuestas HEAD son almacenables en caché y, según RFC 9111, una caché usa una respuesta HEAD para actualizar una respuesta GET almacenada cuando los validadores y Content-Length coinciden, y la trata como obsoleta en caso contrario.

OPTIONS solicita información sobre las opciones de comunicación de un recurso, o del servidor en su conjunto cuando el destino es *, lo que RFC 9110 describe como un ping que comprueba capacidades sin implicar una acción sobre el recurso. Una respuesta correcta DEBERÍA incluir encabezados que describan las funciones opcionales, en particular Allow; el formato del cuerpo no está definido; las respuestas no son almacenables en caché por las cachés HTTP; Max-Forwards puede dirigirse a un proxy específico de la cadena. En CORS, el navegador envía un preflight OPTIONS con Access-Control-Request-Method y Access-Control-Request-Headers y espera de vuelta los encabezados Access-Control-Allow-* correspondientes; MDN señala que tanto 200 como 204 están permitidos para esa respuesta, pero que algunos navegadores han gestionado mal el 204.

Por qué importa

Los verificadores de enlaces, los gestores de descargas (que leen Content-Length y Accept-Ranges), los monitores de disponibilidad y los rastreadores dependen de HEAD; un framework que responde 405 a HEAD, o que devuelve encabezados distintos de los de GET, hace que informen mal. OPTIONS es lo que un navegador envía antes de cualquier solicitud entre orígenes que no sea simple; una API que responde con 404, 401 o una redirección resulta inutilizable desde navegadores sin importar sus encabezados CORS.

Cómo aplicarlo

• Derivar HEAD automáticamente de cada ruta GET; mantener idénticos el estado, Content-Type, ETag y Last-Modified, y omitir la generación del cuerpo cuando sea posible.
• Aplicar a HEAD la misma autorización que a GET; no filtrar la existencia de recursos protegidos mediante un estado distinto.
• Responder a OPTIONS con Allow calculado a partir del enrutador (e incluir Allow en las respuestas 405, tal como exige RFC 9110).
• Gestionar los preflight antes de la autenticación: MDN indica que las solicitudes de preflight nunca deben incluir credenciales. Establecer Access-Control-Max-Age para que el navegador almacene en caché el resultado.
• Enrutar OPTIONS * de forma explícita; los enrutadores basados en rutas a menudo lo convierten en un 404.

Trampas

Una respuesta HEAD puede llevar Transfer-Encoding: chunked y aun así no tener cuerpo. El middleware que calcula Content-Length renderizando el cuerpo anula el propósito de HEAD. La caché de preflight de CORS y la caché HTTP son mecanismos independientes; es Access-Control-Max-Age, no Cache-Control, lo que controla cuánto tiempo conserva un navegador el resultado de un preflight.