HEAD et OPTIONS : à quoi ils répondent et à quoi les clients les utilisent

Ce que c'est

HEAD est, selon la RFC 9110, identique à GET si ce n'est que le serveur NE DOIT PAS envoyer de contenu. Le serveur DEVRAIT envoyer les mêmes champs d'en-tête que pour GET mais PEUT omettre les champs dont la valeur n'est connue qu'en générant le contenu, tels que Content-Length ou Vary sur une réponse dynamique mise en tampon. Un corps dans une requête HEAD n'a pas de signification définie et peut entraîner la fermeture de la connexion en tant que tentative suspectée de contrebande de requêtes. Les réponses HEAD peuvent être mises en cache et, selon la RFC 9111, un cache utilise une réponse HEAD pour mettre à jour une réponse GET stockée lorsque les validateurs et Content-Length correspondent, et la traite comme périmée dans le cas contraire.

OPTIONS demande des informations sur les options de communication pour une ressource, ou pour le serveur dans son ensemble lorsque la cible est *, ce que la RFC 9110 décrit comme un ping qui teste les capacités sans impliquer d'action sur une ressource. Une réponse réussie DEVRAIT inclure des en-têtes décrivant les fonctionnalités optionnelles, notamment Allow ; le format du corps n'est pas défini ; les réponses ne sont pas mises en cache par les caches HTTP ; Max-Forwards permet d'adresser un mandataire précis dans la chaîne. En CORS, le navigateur envoie un préflight OPTIONS avec Access-Control-Request-Method et Access-Control-Request-Headers et attend en retour les en-têtes Access-Control-Allow-* correspondants ; MDN note que 200 et 204 sont tous deux permis pour cette réponse, mais que certains navigateurs ont mal géré le 204.

Pourquoi c'est important

Les vérificateurs de liens, les gestionnaires de téléchargement (qui lisent Content-Length et Accept-Ranges), les moniteurs de disponibilité et les robots d'indexation s'appuient sur HEAD ; un framework qui répond 405 à HEAD, ou qui renvoie des en-têtes différents de GET, les fait se tromper. OPTIONS est ce qu'un navigateur envoie avant toute requête inter-origines non simple ; une API qui y répond par 404, 401 ou une redirection est inutilisable depuis les navigateurs, quels que soient ses en-têtes CORS.

Comment l'appliquer

• Dériver HEAD automatiquement de chaque route GET ; garder identiques le statut, Content-Type, ETag et Last-Modified, et éviter la génération du corps quand c'est possible.
• Appliquer à HEAD la même autorisation qu'à GET ; ne pas révéler l'existence de ressources protégées par un statut différent.
• Répondre à OPTIONS avec Allow calculé à partir du routeur (et inclure Allow dans les réponses 405, comme l'exige la RFC 9110).
• Traiter les préflights avant l'authentification : MDN précise que les requêtes de préflight ne doivent jamais inclure d'identifiants. Régler Access-Control-Max-Age afin que le navigateur mette le résultat en cache.
• Router explicitement OPTIONS * ; les routeurs fondés sur le chemin le transforment souvent en 404.

Pièges

Une réponse HEAD peut porter Transfer-Encoding: chunked et n'avoir toujours aucun corps. Un intergiciel qui calcule Content-Length en générant le corps annule l'intérêt de HEAD. Le cache de préflight CORS et le cache HTTP sont des mécanismes distincts ; c'est Access-Control-Max-Age, et non Cache-Control, qui contrôle combien de temps un navigateur conserve un résultat de préflight.