HEAD

Utilisation

Une requête HEAD récupère les métadonnées d’une ressource : taille, type, fraîcheur et existence. Le serveur traite la requête exactement comme un GET, mais s’arrête avant de transmettre le corps. Tous les en-têtes de réponse, y compris Content-Length et Content-Type, sont identiques à ceux d’une réponse GET complète.

Cas d’usage courants

Validation de liens. Des outils automatisés envoient des requêtes HEAD pour vérifier que des URL renvoient 200 sans télécharger les pages entières. Les liens cassés se signalent par des réponses 404 ou 410.

Supervision et contrôles de santé. Les moniteurs de disponibilité sondent les points de terminaison avec HEAD pour confirmer leur disponibilité. La taille réduite de la réponse diminue la bande passante consommée et accélère les intervalles d’interrogation.

Sondage de la négociation de contenu. Les clients inspectent les en-têtes Content-Type, Content-Encoding et Content-Language avant de décider s’ils récupèrent la ressource complète.

Validation de cache. Une réponse HEAD portant ETag ou Last-Modified permet aux caches de vérifier la fraîcheur sans télécharger le corps. Si les en-têtes de la réponse HEAD indiquent qu’une copie en cache est périmée, le cache marque l’entrée en conséquence.

Estimation de la taille de téléchargement. Les gestionnaires de fichiers et les outils de téléchargement lisent Content-Length dans une réponse HEAD pour afficher la taille du fichier ou réserver de l’espace disque avant de démarrer le transfert.

Remarque

Un corps de requête dans une requête HEAD n’a pas de sémantique généralement définie. Certaines implémentations rejettent les requêtes HEAD comportant un corps. Inclure un corps risque de déclencher des vulnérabilités de request smuggling chez les intermédiaires qui analysent mal le découpage du message.

Exemple

Une requête HEAD permettant de vérifier si une ressource existe et d’inspecter les en-têtes de réponse. Le serveur renvoie 200 avec les métadonnées du contenu, mais sans corps.

Requête

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

Réponse

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

L’en-tête Content-Length révèle que le fichier pèse environ 278 Ko. Les en-têtes Last-Modified et ETag fournissent des validateurs pour les requêtes conditionnelles lors des récupérations ultérieures.

CORS

HEAD est une méthode figurant sur la liste sûre de CORS. Les requêtes HEAD cross-origin ne déclenchent pas de requête de préflight, selon le même comportement de liste sûre que GET.

HEAD vs GET

HEAD renvoie les mêmes en-têtes que GET, mais omet entièrement le corps de la réponse. HEAD est de ce fait plus rapide et plus économe en bande passante pour les tâches qui ne nécessitent que les métadonnées.

Les applications courantes incluent la vérification de l’existence d’une ressource, la lecture de Content-Length pour connaître la taille d’un fichier, l’inspection des dates Last-Modified et l’obtention de validateurs de cache comme ETag sans télécharger la ressource complète.

Certains serveurs implémentent HEAD en exécutant en interne le gestionnaire GET complet puis en supprimant le corps avant d’envoyer la réponse. Dans ces cas, le gain de performance se limite au temps de transfert économisé sur les seuls octets du corps.

Les réponses HEAD mettent aussi à jour les réponses GET mises en cache. Lorsqu’un cache envoie une requête HEAD et que les validateurs renvoyés correspondent à une entrée GET stockée, le cache rafraîchit en conséquence les en-têtes stockés.

Impact SEO

Les robots d’exploration récupèrent les pages avec GET, pas avec HEAD : HEAD ne pilote donc pas l’indexation. HEAD reste utile aux vérificateurs de liens, aux moniteurs de disponibilité et aux outils d’audit SEO qui confirment qu’une URL renvoie 200 sans télécharger le corps.