En bref. Les règles _headers de Cloudflare Pages excluent les réponses produites par les Functions, y compris le SSR ; les en-têtes personnalisés se définissent donc dans le code de réponse des Functions.

Définition : Non. Au 17 octobre 2026, Cloudflare Pages applique les règles _headers aux réponses des ressources statiques et exclut les réponses produites par Pages Functions, même lorsque l’URL de la requête correspond à une règle. Les en-têtes personnalisés des réponses produites par une Function se définissent dans le code de réponse de cette Function.

Points clés

La documentation de Cloudflare sur les en-têtes personnalisés mentionne explicitement le rendu côté serveur (server-side rendering), le répertoire functions/ et le fichier _worker.js en mode avancé dans son avertissement sur les réponses exclues.
La documentation sur le routage des Functions décrit le recours à une ressource statique disponible lorsqu’aucune Function ne correspond à une requête.
La documentation de Cloudflare sur les middlewares place les middlewares applicables à l’ensemble de l’application dans functions/_middleware.js, y compris ceux qui s’exécutent avant les fichiers statiques.
L’exemple « Adding CORS headers » définit les en-têtes de réponse dans le code et comprend un gestionnaire distinct pour la méthode de requête OPTIONS.

Quelles réponses sont exclues des règles d’en-têtes statiques ?

La documentation « Headers » de Cloudflare distingue les réponses des ressources statiques des réponses produites par Pages Functions. Le rendu côté serveur (SSR) consiste à produire une page sur le serveur ; Cloudflare inclut les frameworks SSR dans cet avertissement. L’exclusion couvre également les Functions mises en œuvre au moyen d’un répertoire functions/ ou d’un fichier _worker.js en mode avancé.

Un chemin correspondant dans _headers ne configure donc aucun en-tête pour une réponse produite par une Function. La même documentation indique que les applications doivent ajouter les en-têtes personnalisés dans le code de Pages Functions. Ses consignes sur les en-têtes de sécurité incluent expressément les points d’accès d’une interface de programmation d’application (API) et imposent des en-têtes de réponse interorigines sur les requêtes OPTIONS lorsque ces en-têtes sont nécessaires.

Pour les ressources statiques, _headers reste un fichier texte sans extension placé dans le répertoire des ressources statiques du projet. Pages analyse ce fichier pour en extraire les règles ; le fichier lui-même n’est pas servi comme ressource statique.

Comment le code d’une Function peut-il ajouter un en-tête ?

L’exemple « Adding CORS headers » de Cloudflare illustre le partage de ressources entre origines (Cross-Origin Resource Sharing, CORS), le mécanisme utilisé ici pour autoriser les requêtes provenant d’autres origines. Son gestionnaire attend le résultat de context.next(), définit des en-têtes sur la réponse obtenue, puis renvoie cette réponse. Le code JavaScript suivant adapte ce modèle pour ne conserver que l’en-tête relatif à l’origine :

export const onRequest = async (context) => {
  const response = await context.next();
  response.headers.set("Access-Control-Allow-Origin", "*");
  return response;
};

La documentation de Cloudflare sur les middlewares définit un middleware comme une logique réutilisable qui s’exécute avant une fonction onRequest. Un fichier functions/_middleware.js s’applique à l’ensemble de l’application, y compris avant les fichiers statiques. Un middleware placé dans un sous-répertoire s’applique aux Functions correspondantes de ce répertoire et de ses sous-répertoires.

L’exemple CORS exporte également onRequestOptions pour construire la réponse à la requête préliminaire (preflight). Ce gestionnaire intervient lorsqu’un point d’accès doit répondre à la vérification par le navigateur des autorisations interorigines.

Comment rechercher la cause d’un en-tête manquant ?

La documentation sur le routage associe les fichiers des Functions aux chemins des requêtes. Elle décrit également _routes.json, placé dans le répertoire de compilation, qui contrôle l’invocation des Functions. Ses règles exclude sont prioritaires sur les règles include.

L’analyse commence par le chemin demandé, la Function correspondante et les éventuels middlewares. Pour une réponse produite par ce code, la logique qui définit les en-têtes se place dans le chemin d’exécution qui renvoie la réponse. Pour une réponse de ressource statique, la configuration pertinente est la règle _headers correspondante. La seule vérification du motif d’URL ne permet pas de déterminer l’origine de la réponse.

Termes associés

Questions fréquentes

Un caractère générique dans _headers couvre-t-il les pages produites par les Functions ?

Non. La documentation « Headers » de Cloudflare exclut explicitement les réponses produites par les Functions, même lorsque l’URL de leur requête correspond à une règle _headers.

Où puis-je définir un en-tête pour plusieurs Functions ?

Vous pouvez utiliser un fichier functions/_middleware.js. La documentation de Cloudflare sur les middlewares prévoit également de placer un middleware dans un sous-répertoire pour limiter sa portée à ce répertoire et à ses sous-répertoires.

Sources

Vérifiez comment une page se lit pour les moteurs de réponse. Ouvrir l’analyseur de score GEO

Les règles _headers de Cloudflare Pages s’appliquent-elles aux réponses des Functions ?