Configurer le partage de ressources cross-origin pour CDN avec des en-têtes de réponse HTTP - CDN

Après avoir ajouté votre service à Alibaba Cloud CDN, activez l'accès cross-origin en configurant les en-têtes de réponse HTTP sur les points de présence (POP).

Qu'est-ce que le partage de ressources cross-origin ?

Le partage de ressources cross-origin (CORS) est un mécanisme standard qui permet à une page web d'accéder à des ressources provenant d'une origine différente (domaine, protocole ou port) de la sienne. Il offre un moyen sécurisé d'activer les transferts de données cross-origin. Pour plus d'informations, consultez Cross-Origin Resource Sharing (CORS).

Remarque

Q : Que se passe-t-il si CORS n'est pas activé par défaut sur CDN ?

Par défaut, CDN n'active pas le partage de ressources cross-origin (CORS). Sans cette configuration, les navigateurs appliquent la politique de même origine et bloquent les requêtes cross-origin, ce qui empêche d'autres sites web de charger vos ressources.

Pourquoi configurer le partage de ressources cross-origin ?

En raison des restrictions de sécurité, les navigateurs suivent généralement la politique de même origine, qui restreint les requêtes visant à charger et accéder à des ressources provenant de domaines, sous-domaines, protocoles ou ports différents. Par exemple, example.com ne peut pas accéder aux ressources hébergées sur example.org. En configurant le partage de ressources cross-origin (CORS), vous définissez les en-têtes de réponse appropriés sur le serveur CDNDCDN. Si une requête inclut des en-têtes conformes aux règles autorisées, le serveur renvoie les en-têtes de réponse HTTP correspondants, permettant ainsi le chargement et l'accès aux ressources cross-origin.

Fonctionnement

CORS configuré sur le serveur d'origine

Avec CORS configuré sur CDN

Notes d'utilisation

Si vous utilisez un compartiment OSS comme serveur d'origine, la configuration CORS dans la console CDNDCDN remplace celle définie dans la console OSS. Pour savoir comment configurer CORS dans la console OSS, consultez Définir des règles CORS.
Si vous utilisez un serveur local ou une instance ECS comme serveur d'origine, nous vous recommandons de séparer le contenu statique du contenu dynamique et d'utiliser CDNDCDN pour accélérer la diffusion des fichiers statiques. La fonctionnalité CORS configurée dans la console CDNDCDN s'applique uniquement aux fichiers statiques.

Activer le partage de ressources cross-origin

Connectez-vous à la console CDN.
Dans le volet de navigation de gauche, cliquez sur Domain Names.
Sur la page Domains, repérez le domaine que vous souhaitez gérer et cliquez sur Actions dans la colonne Manage.

Cliquez sur Cache, sélectionnez l'onglet Modify Outgoing Response Header et définissez les origines et méthodes autorisées pour les requêtes cross-origin.

Définir l'origine des requêtes cross-origin

Cliquez sur Customize, configurez les paramètres selon le tableau ci-dessous, puis cliquez sur OK.

Paramètre	Description	Exemple
Operation	Définissez ce paramètre sur Add pour activer la fonction de validation CORS.	Add
Response Header	Vous devez définir `Access-Control-Allow-Origin` pour utiliser la fonction de validation cross-origin.	Access-Control-Allow-Origin
Header Value	Si la validation CORS est désactivée : Vous ne pouvez spécifier qu'un caractère générique ou une seule origine. Caractère générique `` : Autorise toute origine à accéder à la ressource. Origine unique* : Permet l'accès aux ressources uniquement depuis une origine spécifique (nom de domaine). Si la validation CORS est activée : Vous pouvez spécifier un caractère générique, une origine unique, plusieurs origines ou un domaine avec caractère générique. Caractère générique `` : Autorise toute source à accéder à la ressource. Origine unique* : Permet l'accès aux ressources uniquement depuis une origine spécifique (nom de domaine). Plusieurs origines spécifiées : Configurez plusieurs origines spécifiques (noms de domaine), séparées par une virgule `,`, pour autoriser ces origines à accéder à la ressource. Domaine avec caractère générique : Spécifiez un domaine avec caractère générique pour autoriser l'accès depuis toutes les origines correspondant au modèle.	`` `http://www.aliyun.com` `https://aliyun.com,http://www.aliyun.com` `http://.aliyun.com`
Allow Duplicates	Oui : Les en-têtes du serveur d'origine sont conservés et le nouvel en-tête portant le même nom est également ajouté à la réponse. Non : Le nouvel en-tête remplace tout en-tête portant le même nom provenant du serveur d'origine. Important Les paramètres Autoriser les doublons et Validation CORS s'excluent mutuellement. Si vous définissez Autoriser les doublons sur Oui, la validation CORS est désactivée.	No
CORS	CORS ne peut être configuré que lorsque Operation est défini sur Add et que Response Header est défini sur « Access-Control-Allow-Origin ». CORS peut être défini sur Disable ou Enable. La valeur par défaut est Disable. Disable : Les POP CDN ne valident pas l'en-tête `Origin` des requêtes entrantes et renvoient toujours la valeur configurée pour `Access-Control-Allow-Origin`. Enable : Les POP CDN valident les requêtes cross-origin selon les règles suivantes et répondent avec la valeur `Access-Control-Allow-Origin` en conséquence. Response Header : Si Response Header est défini sur , le POP renvoie toujours `Access-Control-Allow-Origin:`, indépendamment de la présence ou de la valeur de l'en-tête `Origin` dans la requête utilisateur. Response Header : Response Header est défini sur une ou plusieurs origines spécifiques, séparées par des virgules (`,`). Si la valeur de l'en-tête `Origin` dans la requête utilisateur correspond exactement à l'une des origines configurées, le POP répond avec cette origine comme valeur de l'en-tête `Access-Control-Allow-Origin`. Si aucune correspondance n'est trouvée, le POP n'ajoute pas l'en-tête CORS à la réponse. Response Header : Si Response Header est défini sur un domaine avec caractère générique, le POP vérifie si l'en-tête `Origin` de la requête correspond au modèle générique. Si vous définissez Enable pour Header Value et que le nom de domaine dans le champ Header Value contient un trait d'union (`-`), vous devez l'échapper en remplaçant `-` par `%-`. Exemple : Valeur d'en-tête d'origine : `http://doc.aliyun-example.com`. Valeur d'en-tête échappée : `http://doc.aliyun%-example.com`.	Enable

Définir les méthodes pour les requêtes cross-origin

Cliquez sur Customize, configurez les paramètres selon le tableau ci-dessous, puis cliquez sur OK.

Paramètre	Description	Exemple
Operation	Définissez ce paramètre sur Add.	Add
Response Header	Doit être défini sur `Access-Control-Allow-Methods`	Access-Control-Allow-Methods
Header Value	Prend en charge les méthodes de requête `GET, POST et PUT`. Si vous devez ajouter `GET, POST et PUT` simultanément, séparez-les par une virgule `,`.	`GET`
Allow Duplicates	Oui : Les en-têtes du serveur d'origine sont conservés et le nouvel en-tête portant le même nom est également ajouté à la réponse. Non : Le nouvel en-tête remplace tout en-tête portant le même nom provenant du serveur d'origine.	No

Remarque

Q : Après l'ajout d'un en-tête de réponse CORS, celui-ci s'appliquera-t-il aux ressources statiques précédemment mises en cache ?

Non. CDN met en cache l'intégralité de la réponse HTTP, y compris les en-têtes. Pour appliquer un nouvel en-tête CORS au contenu déjà mis en cache, vous devez purger les URL de ces ressources. Sinon, les utilisateurs continueront à recevoir l'ancienne réponse issue du cache.

Exemples de configuration

Exemple 1

Si la valeur de l'en-tête de réponse pour CORS est définie sur une ou plusieurs origines spécifiques séparées par des virgules (,) :

Si la valeur de l'en-tête Origin dans la requête de l'utilisateur correspond exactement à l'une des origines spécifiées, le POP CDNDCDN répond avec l'en-tête CORS correspondant.
Si aucune correspondance exacte n'est trouvée, l'en-tête CORS n'est pas inclus dans la réponse.

Sur CDN/DCDN, définissez : Access-Control-Allow-Origin: http://example.com,https://aliyundoc.com.

L'en-tête Origin de la requête utilisateur est http://example.com et le point de présence (POP) CDNDCDN répond par Access-Control-Allow-Origin: http://example.com.
L'en-tête Origin dans la requête utilisateur est https://aliyundoc.com et le nœud CDNDCDN répond par Access-Control-Allow-Origin: https://aliyundoc.com.
Le nœud CDNDCDN ne répondra pas à une requête utilisateur dont l'en-tête Origin est http://aliyundoc.com (en raison d'une incompatibilité de protocole : la requête utilisateur utilise HTTP, tandis que CDNDCDN est configuré pour HTTPS).
Si l'en-tête Origin d'une requête est http://aliyun.com, le POP CDNDCDN ne répondra pas (incompatibilité de domaine).

Exemple 2

Si la valeur de l'en-tête de réponse pour CORS est définie sur un domaine avec caractère générique, le POP vérifie si la valeur Origin dans l'en-tête de requête correspond au modèle générique.

Sur CDN/DCDN, définissez : Access-Control-Allow-Origin: http://*.aliyundoc.com.

La requête utilisateur contient l'en-tête Origin http://demo.aliyundoc.com et le POP CDNDCDN répond par Access-Control-Allow-Origin: http://demo.aliyundoc.com.
Si l'en-tête Origin d'une requête est http://demo.example.com, le POP CDNDCDN ne répondra pas car le nom de domaine ne correspond pas.
Le nœud CDNDCDN ne répond pas à une requête utilisateur dont l'en-tête Origin est https://demo.aliyundoc.com car la requête utilise le protocole HTTPS, alors que CDNDCDN est configuré avec le protocole HTTP.

Remarque

Q : Comment puis-je utiliser curl pour vérifier que l'en-tête Access-Control-Allow-Origin de CDN fonctionne correctement ?

Envoyez une requête GET avec un en-tête Origin en utilisant curl -svo /dev/null et examinez la sortie détaillée pour les en-têtes de réponse. Si l'en-tête Access-Control-Allow-Origin apparaît dans la réponse avec la valeur attendue (par exemple, * ou votre domaine spécifié), votre configuration CORS fonctionne. Si l'en-tête est absent, vérifiez vos règles d'en-tête de réponse personnalisées dans la console CDN ainsi que les paramètres CORS de votre serveur d'origine.

curl -svo /dev/null https://img.anleme.cc/agent/dl1.jpg -H 'origin:https://am.anleme.cc'

FAQ

Pourquoi une erreur cross-origin survient-elle toujours après avoir configuré l'en-tête de réponse Access-Control-Allow-Origin, et pourquoi cet en-tête est-il absent de la réponse ?

Remarque

Q : La configuration CORS de CDN prend-elle en charge plusieurs domaines avec caractères génériques séparés par des virgules ?

Non. Lorsque la validation CORS est activée sur CDN, vous ne pouvez configurer qu'un seul domaine avec caractère générique. Vous pouvez également répertorier plusieurs domaines exacts (sans caractère générique) séparés par des virgules. Il est impossible de spécifier une liste de plusieurs domaines avec caractères génériques séparés par des virgules, telle que https://*.iflyvoice.cn,https://*.xxx.com.

Remarque

Q : Pourquoi les fichiers de polices accessibles via un domaine accéléré par CDN déclenchent-ils un problème CORS, contrairement aux fichiers vidéo ?

Ce comportement est déterminé par le type de ressource et la politique de sécurité du navigateur. Par défaut, les fichiers vidéo (tels que MP4 ou WebM) chargés via une balise <video> ne sont pas soumis aux restrictions CORS, sauf si l'attribut crossorigin est explicitement ajouté. En revanche, les fichiers de polices (tels que .ttf ou .woff) sont toujours soumis à une validation CORS obligatoire par le navigateur, quelle que soit la méthode de chargement. Ainsi, même si les deux types de ressources sont hébergés sur le même domaine, les requêtes de polices échoueront sans une politique CORS valide, tandis que les requêtes vidéo réussiront souvent. Cette différence découle des politiques de sécurité standard des navigateurs pour différents types de contenu.

Remarque

Q : Comment puis-je vérifier que ma configuration CORS CDN est effective ?

Utilisez les méthodes suivantes pour la vérification :

Effectuez à nouveau un test pour voir si l'erreur cross-origin persiste.
Utilisez la commande curl -svo /dev/null pour envoyer une requête GET avec un en-tête Origin spécifique et vérifiez les en-têtes de réponse dans la sortie détaillée. Par exemple :curl -svo /dev/null https://img.anleme.cc/agent/dl1.jpg -H 'origin:https://am.anleme.cc'
Fournissez le domaine de test au support technique pour obtenir de l'aide.

Remarque

Q : Lors de l'accélération d'un compartiment OSS avec CDN, comment puis-je transmettre la configuration CORS depuis l'OSS d'origine ?

Pour activer la transmission de la configuration CORS depuis un serveur d'origine OSS, la requête initiale adressée à CDN doit inclure un en-tête Origin . Cela permet à CDN de récupérer les données depuis l'origine et de mettre en cache l'en-tête de réponse Access-Control-Allow-Origin . Toutefois, ce mécanisme de mise en cache peut provoquer des problèmes CORS pour les requêtes ultérieures ayant un Origin différent ou aucun en-tête Origin . La meilleure pratique recommandée consiste à configurer directement les en-têtes CORS dans la console CDN en utilisant la fonctionnalité Modify Outgoing Request Header dans les Cache Settings, plutôt que de s'appuyer sur la transmission.

Remarque

Q : Si plusieurs domaines CDN sont associés au même compartiment OSS, puis-je configurer la règle CORS une seule fois dans OSS et la faire hériter automatiquement par tous les domaines CDN ?

Non. Étant donné que les POP CDN mettent en cache les en-têtes de réponse et que ce comportement est influencé par la présence ou non d'un en-tête Origin dans la requête initiale, s'appuyer sur une configuration transmise depuis OSS peut entraîner des erreurs CORS intermittentes. La meilleure pratique consiste à ajouter des en-têtes CORS en utilisant la fonctionnalité Modify Outgoing Request Header afin de garantir un comportement correct et stable.