Une clé de cache est un identifiant unique attribué à un fichier mis en cache sur un nœud Dynamic Route for CDN (DCDN). Par défaut, cette clé correspond à l'URL de la requête, paramètres inclus. DCDN permet de réécrire les clés de cache afin que les requêtes ciblant une même ressource partagent un identifiant commun. Cette fonctionnalité optimise l'espace de stockage et réduit le nombre de requêtes redirigées vers le serveur d'origine. Cette rubrique explique comment configurer une clé de cache personnalisée.
Cas d'usage
Scénario 1 :
Les URL des requêtes peuvent contenir des paramètres complexes, même lorsqu'elles ciblent le même fichier de ressources. En raison de ces différences, les nœuds DCDN traitent chaque requête comme une demande distincte et mettent en cache plusieurs copies du fichier. Par conséquent, un grand nombre de requêtes sont redirigées vers le serveur d'origine.
Pour limiter les redirections vers l'origine, définissez une clé de cache spécifique pour ce type de requête.
Scénario 2 :
Des requêtes partagent la même URL et ciblent donc la même ressource selon DCDN. Toutefois, le système d'exploitation du client est spécifié dans le champ client de l'en-tête HTTP. Vous devez alors servir des fichiers différents selon le système d'exploitation indiqué.
Pour résoudre ce problème, configurez deux clés de cache intégrant la valeur du champ client. Cela permet de distinguer les requêtes lors de la mise en cache.
Procédure
Connectez-vous à la console DCDN.
Sur la page Domain Names, repérez le nom de domaine à gérer, puis cliquez sur Configure dans la colonne Actions.
Dans le volet de navigation de gauche de la page de détails du domaine, cliquez sur Cache.
-
Sous l'onglet Custom Cache Key, configurez la clé de cache.
RemarqueSeuls les URI, les actions sur les paramètres et les en-têtes HTTP d'une clé de cache sont modifiables. Les variables personnalisées sont prises en charge pour extraire des champs spécifiques des requêtes. Une clé de cache se compose d'URI, d'actions sur les paramètres, d'en-têtes HTTP et de variables personnalisées.
Les clés de cache personnalisées ne modifient pas les URL des requêtes transmises au serveur d'origine. Elles modifient uniquement les identifiants de cache. Le contenu des requêtes envoyées par les clients et redirigées vers l'origine reste donc inchangé.
Cliquez sur OK.
Exemple
URIs
Dans l'exemple ci-dessous, les requêtes ciblant les URI
http://example.com/a/b/test.jpg
et
http://example.com/a/b/c/test.jpg
sont considérées comme visant la même ressource. La clé de cache générée pour ce fichier est
http://example.com/c/test.jpg
.
Parameter Actions
L'illustration suivante présente des requêtes destinées à
http://example.com/a/b/test.jpg?delete_par=1&modify_par=1
. Le paramètre
add_par=1
est ajouté à l'URL, le paramètre
delete_par
en est supprimé, et la valeur du paramètre
modify_par
passe à
2
. L'URL finale devient
http://example.com/a/b/test.jpg?modify_par=2&add_par=1
.
Concernant les actions sur les paramètres, l'ordre de priorité des règles appliquées à une même variable est le suivant : Add > Delete > Retain Only > Modify.
HTTP Headers
Dans cet exemple, les valeurs des champs
User-Agent
et
Accept-Language
de l'en-tête HTTP sont intégrées aux clés de cache. Ainsi, si une requête vers
http://example.com/a/b/test.jpg
contient
User-Agent=Mozilla/5,0 (Linux; X11)
et
Accept-Language=en
dans son en-tête, la clé de cache résultante est
http://example.com/a/b/test.jpgMozilla/5,0(Linux;X11)en
.
Custom Variables
Exemple 1 :
La variable se nomme
language
. La source de la variable est
Request Header
, son champ source est
Accept-Language
, sa règle de correspondance est
([%w]+),([%w]+)
et son expression est
$1aa
.
Si une requête vers
http://example.com/a/b/test.jpg
inclut l'en-tête HTTP
Accept-Language=en,ch
, la règle de correspondance attribue la valeur
en
à
$1
dans l'expression. La chaîne
aa
est également ajoutée à la fin. La variable générée est donc
enaa
avec l'alias
language
. Une fois cette variable ajoutée à l'URL par DCDN, la clé de cache finale est :
http://example.com/a/b/test.jpgenaa
.
Dans l'expression de la variable,
$n
fait référence au contenu capturé par la
n
-ième parenthèse. Dans cet exemple, pour
Accept-Language=en,ch
et la règle
([%w]+),([%w]+)
, on obtient
$1=en
et
$2=ch
.
Exemple 2 :
La variable personnalisée s'appelle
expired
. La source de la variable est
Request Cookie
, utilise le champ source
a
, applique la règle de correspondance
[%w]+:(.*)
et l'expression
$1
.
Si une requête vers http://example.com/a/b/test.jpg contient le cookie Cookie a=expired_time:12635187, la règle de correspondance assigne la valeur 12635187 à $1 dans l'expression. L'alias de la variable est expired. La clé de cache finale est http://example.com/a/b/test.jpg12635187.
Exemple 3 :
Combinaison de règles URI et de variables personnalisées
URI :
Transformation de
/abc/.*/abc
en
/abc
pour tous les URI de requête.
Variable personnalisée :
Cette variable nommée
testname
. La source de la variable est
Path
, utilise la règle de correspondance
/abc/xyz/(.*)
et l'expression
$1
.
Pour une requête vers http://example.com/abc/xyz/abc/test.jpg, l'URL devient http://example.com/abc/test.jpg conformément à la règle URI. Elle correspond ensuite au motif /abc/xyz/(.*). Ainsi, $1 reçoit la valeur abc, qui est ajoutée à la clé de cache. Le résultat final est http://example.com/abc/test.jpgabc. L'application simultanée de ces deux règles permet de gérer des logiques de mise en cache plus complexes.