Avant même que le contenu d’une page n’arrive, la requête et la réponse HTTP échangent une série d’instructions administratives : type de contenu attendu, langue préférée, jeton d’authentification, durée de mise en cache autorisée. Ces instructions voyagent dans les en-têtes, invisibles à l’écran mais consultables dans l’onglet « Réseau » des outils de développement du navigateur.
Où WordPress s’en sert
WordPress envoie ou reçoit des en-têtes à de multiples endroits : Content-Type: text/html; charset=UTF-8 sur chaque page, X-Pingback pour signaler l’URL de rétroliens, ou encore les en-têtes Cache-Control et Expires posés par un plugin de cache. Côté PHP, on les manipule avec header() ou, plus proprement dans le contexte de l’API REST, via l’objet WP_REST_Response et sa méthode header().
Exemple
GET /wp-json/wp/v2/posts HTTP/1.1
Accept: application/json
Authorization: Bearer eyJhbGciOi...Pièges fréquents
- Appeler
header()en PHP après qu’un espace ou un caractère ait déjà été envoyé au navigateur déclenche l’avertissement « headers already sent », un classique du dépannage WordPress. - Confondre en-tête de requête (envoyé par le client) et en-tête de réponse (renvoyé par le serveur) :
Acceptest un en-tête de requête,Content-Typede la réponse en est le miroir. - Négliger l’en-tête
Cache-Controlsur les ressources statiques (images, CSS), ce qui prive un site de gains de performance faciles à obtenir. - Certains en-têtes de sécurité (
Content-Security-Policy,X-Frame-Options) doivent être réglés avec soin : trop restrictifs, ils peuvent casser silencieusement un script ou un widget tiers légitime.