Configurer le trafic sur le réseau CDN cdn-configuring-cloud

AEM as a Cloud Service propose un ensemble de fonctionnalités configurables au niveau de la couche CDN géré par Adobe qui modifient la nature des requêtes entrantes ou des réponses sortantes. Les règles suivantes, décrites en détail sur cette page, peuvent être déclarées pour obtenir le comportement suivant :

Vous pouvez également configurer sur le réseau CDN les règles de filtrage du trafic (y compris WAF), qui contrôlent le trafic autorisé ou refusé par le réseau CDN. Cette fonctionnalité est déjà disponible et vous pouvez en savoir plus à ce sujet sur la page Règles de filtrage de trafic , y compris les règles WAF.

De plus, si le réseau CDN ne peut pas contacter son origine, vous pouvez créer une règle qui fait référence à une page d’erreur personnalisée auto-hébergée (qui est ensuite rendue). Pour en savoir plus à ce sujet, consultez l’article Configuration des pages d’erreur du réseau CDN.

Toutes ces règles, déclarées dans un fichier de configuration dans le contrôle de code source, sont déployées à l’aide du pipeline Cloud Manager config. Notez que la taille cumulée du fichier de configuration, y compris les règles de filtrage du trafic, ne peut pas dépasser 100KB.

Pour obtenir des fragments de code supplémentaires pour les scénarios courants, consultez l’article ​ Fragments de code de configuration de réseau CDN pour les scénarios courants ​.

Ordre d’évaluation order-of-evaluation

Fonctionnellement, les différentes fonctionnalités mentionnées précédemment sont évaluées dans l’ordre suivant:

Configuration initial-setup

Avant de pouvoir configurer le trafic sur le réseau CDN, vous devez effectuer les opérations suivantes :

Syntaxe des règles configuration-syntax

Les types de règle des sections ci-dessous partagent une syntaxe commune.

Une syntaxe de règle standard est une entrée de liste avec un nom, une condition de when et une ou plusieurs actions :

- name: <name>
  when: <condition>
  action: <action>

Chaque section de niveau supérieur (requestTransformations, responseTransformations, redirects, originSelectors et trafficFilters dans Règles de filtrage de trafic) prend en charge son propre ensemble de types d’action et de propriétés. Les valeurs et champs de type autorisés sont définis dans les tableaux et exemples de cette section, et ne sont pas partagés sur tous les types de règle. Les sections telles que requestTransformations et responseTransformations prennent en charge plusieurs actions spécifiées sous la forme d’une liste yaml sous actions propriété .

La clause « quand » détermine si une règle sera évaluée en fonction des propriétés, notamment le domaine, le chemin, les chaînes de requête, les en-têtes et les cookies. La syntaxe est la même pour tous les types de règle ; voir Structure de condition ci-dessous. Les règles de filtrage du trafic (y compris WAF) utilisent la même syntaxe de condition. Pour les actions, les limites de débit et le comportement spécifique à WAF, voir Règles de filtrage du trafic y compris les règles WAF.

Structure de condition condition-structure

Une condition peut être soit une simple condition, soit un groupe de conditions.

Condition simple

Une condition simple est composée d’un getter et d’un prédicat.

{ <getter>: <value>, <predicate>: <value> }

Conditions de groupe

Un groupe de conditions est composé de plusieurs conditions simples et/ou de groupe.

<allOf|anyOf>:
  - { <getter>: <value>, <predicate>: <value> }
  - { <getter>: <value>, <predicate>: <value> }
  - <allOf|anyOf>:
    - { <getter>: <value>, <predicate>: <value> }

Getter

Prédicat

Remarques

when:
  reqProperty: clientIp
  in: [ "192.168.0.0/24" ]

Les détails du nœud d’actions diffèrent selon le type de règle et sont décrits dans les sections individuelles ci-dessous.

Dans les règles de configuration, vous pouvez référencer des secrets définis comme variables d’environnement (voir Secrets de configuration).

Transformations de requête request-transformations

Les règles de transformation des requêtes vous permettent de modifier les requêtes entrantes. Les règles prennent en charge la définition, la suppression et la modification de chemins, de paramètres de requête et d’en-têtes (y compris les cookies) en fonction de diverses conditions correspondantes, y compris des expressions régulières. Vous pouvez également définir des variables, qui peuvent ensuite être référencées plus loin dans la séquence d’évaluation.

Les cas d’utilisation sont variés et incluent des réécritures d’URL pour simplifier l’application ou mapper des URL héritées.

Comme mentionné précédemment, le fichier de configuration est soumis à une limite de taille. Les entreprises ayant des besoins plus importants doivent donc définir des règles dans la couche de apache/dispatcher.

Exemple de configuration :

kind: "CDN"
version: "1"
data:
  requestTransformations:
    removeMarketingParams: true
    rules:
      - name: set-header-rule
        when:
          reqProperty: path
          like: /set-header
        actions:
          - type: set
            reqHeader: x-some-header
            value: some value
      - name: set-header-with-reqproperty-rule
        when:
          reqProperty: path
          like: /set-header
        actions:
          - type: set
            reqHeader: x-some-header
            value: {reqProperty: path}
      - name: unset-header-rule
        when:
          reqProperty: path
          like: /unset-header
        actions:
          - type: unset
            reqHeader: x-some-header
      - name: unset-matching-query-params-rule
        when:
          reqProperty: path
          equals: /unset-matching-query-params
        actions:
          - type: unset
            queryParamMatch: ^removeMe_.*$
      - name: unset-all-query-params-except-exact-two-rule
        when:
          reqProperty: path
          equals: /unset-all-query-params-except-exact-two
        actions:
          - type: unset
            queryParamMatch: ^(?!leaveMe$|leaveMeToo$).*$
      - name: multi-action
        when:
          reqProperty: path
          like: /multi-action
        actions:
          - type: set
            reqHeader: x-header1
            value: body set by transformation rule
          - type: set
            reqHeader: x-header2
            value: '201'
      - name: replace-html
        when:
          reqProperty: path
          like: /mypath
        actions:
          - type: transform
            reqProperty: path
            op: replace
            match: \.html$
            replacement: ""
      - name: log-on-request
        when: "*"
        actions:
          - type: set
            logProperty: forwarded_host
            value:
              reqHeader: x-forwarded-host

Actions

Les actions disponibles sont expliquées dans le tableau ci-dessous.

Remplacez les actions qui prennent en charge les groupes de capture, comme illustré ci-dessous :

      - name: extract-country-code-from-path
        when:
          reqProperty: path
          matches: ^/([a-zA-Z]{2})(/.*|$)
        actions:
          - type: set
            var: country-code
            value:
              reqProperty: path
          - type: transform
            var: country-code
            op: replace
            match: ^/([a-zA-Z]{2})(/.*|$)
            replacement: \1
      - name: replace-jpg-with-jpeg
        when:
          reqProperty: path
          like: /mypath
        actions:
          - type: transform
            reqProperty: path
            op: replace
            match: (.*)(\.jpg)$
            replacement: "\1\.jpeg"

Les actions peuvent être enchaînées. Par exemple :

actions:
    - type: transform
      reqProperty: path
      op: replace
      match: \.html$
      replacement: ""
    - type: transform
      reqProperty: path
      op: tolower

Variables variables

Vous pouvez définir des variables pendant la transformation de la requête, puis les référencer ultérieurement dans la séquence d’évaluation. Voir le diagramme ordre d’évaluation pour plus de détails.

Exemple de configuration :

kind: "CDN"
version: "1"
data:
  requestTransformations:
    rules:
      - name: set-variable-rule
        when:
          reqProperty: path
          equals: /set-variable
        actions:
          - type: set
            var: some_var_name
            value: some_value

  responseTransformations:
    rules:
      - name: set-response-header-while-variable
        when:
          var: some_var_name
          equals: some_value
        actions:
          - type: set
            respHeader: x-some-header
            value: some header value

Propriété de journal logproperty

Vous pouvez ajouter vos propres propriétés de journal dans vos journaux CDN à l’aide de transformations de requête et de réponse.

Exemple de configuration :

requestTransformations:
  rules:
    - name: log-on-request
      when: "*"
      actions:
        - type: set
          logProperty: forwarded_host
          value:
            reqHeader: x-forwarded-host
responseTransformations:
  rules:
    - name: log-on-response
      when: '*'
      actions:
        - type: set
          logProperty: cache_control
          value:
            respHeader: cache-control

Exemple de journal :

{
"timestamp": "2025-03-26T09:20:01+0000",
"ttfb": 19,
"cli_ip": "147.160.230.112",
"cli_country": "CH",
"rid": "974e67f6",
"req_ua": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.0.3 Safari/605.1.15",
"host": "example.com",
"url": "/content/hello.png",
"method": "GET",
"res_ctype": "image/png",
"cache": "PASS",
"status": 200,
"res_age": 0,
"pop": "PAR",
"rules": "",
"forwarded_host": "example.com",
"cache_control": "max-age=300"
}

Transformations de réponse response-transformations

Les règles de transformation de réponse vous permettent de définir et de dédéfinir des en-têtes, des cookies et le statut des réponses sortantes du réseau CDN. Consultez également l’exemple ci-dessus pour référencer une variable précédemment définie dans une règle de transformation de requête.

Exemple de configuration :

kind: "CDN"
version: "1"
data:
  responseTransformations:
    rules:
      - name: set-response-header-rule
        when:
          reqProperty: path
          like: /set-response-header
        actions:
          - type: set
            value: value-set-by-resp-rule
            respHeader: x-resp-header
      - name: unset-response-header-rule
        when:
          reqProperty: path
          like: /unset-response-header
        actions:
          - type: unset
            respHeader: x-header1
      - name: multi-action-response-header-rule
        when:
          reqProperty: path
          like: /multi-action-response-header
        actions:
          - type: set
            respHeader: x-resp-header-1
            value: value-set-by-resp-rule-1
          - type: set
            respHeader: x-resp-header-2
            value: value-set-by-resp-rule-2
      - name: status-code-rule
        when:
          reqProperty: path
          like: status-code
        actions:
          - type: set
            respProperty: status
            value: '410'
      - name: set-response-cookie-with-attributes-as-object
        when: '*'
        actions:
          - type: set
            respCookie: first-name
            value: first-value
            attributes:
              expires: '2025-08-29T10:00:00'
              domain: example.com
              path: /some-path
              secure: true
              httpOnly: true
              extension: ANYTHING
      - name: unset-response-cookie
        when: '*'
        actions:
          - type: unset
            respCookie: third-name

Actions

Les actions disponibles sont expliquées dans le tableau ci-dessous.

Sélecteurs d’origine origin-selectors

Vous pouvez tirer parti du réseau CDN d’AEM pour acheminer le trafic vers différents serveurs principaux, y compris les applications non Adobe (par chemin d’accès ou sous-domaine, par exemple).

Les propriétés de requête originalPath et originalUrl sont respectivement le chemin d’accès d’origine non modifiable (sans paramètres de requête) et l’URL complète (y compris les paramètres de requête), chacun utilisé avant toute transformation de requête CDN. Utilisez-les dans des conditions when lorsque vous devez ancrer des règles sur ce que le client a envoyé initialement, plutôt que sur des valeurs qui ont peut-être été réécrites plus tôt dans la séquence d’évaluation. Utilisez originalPath pour la correspondance de chemin d’accès uniquement. Utilisez originalUrl lorsque la chaîne de requête doit faire partie de la condition (par exemple, le routage ou le filtrage sur une URL de requête initiale spécifique).

Exemple de configuration :

kind: "CDN"
version: "1"
data:
  originSelectors:
    rules:
      - name: example-com
        when: { reqProperty: originalPath, like: /proxy* }
        action:
          type: selectOrigin
          originName: example-com
          # skipCache: true
          # headers:
          #   Authorization: ${{AUTH_TOKEN}}
    origins:
      - name: example-com
        domain: www.example.com
        # ip: '1.1.1.1'
        # forwardHost: true
        # forwardCookie: true
        # forwardAuthorization: true
        # timeout: 20

Actions

L’action disponible est expliquée dans le tableau ci-dessous.

Origines

Les connexions aux origines sont SSL uniquement et utilisent le port 443.

Proxy d’un domaine personnalisé vers le niveau statique AEM proxy-custom-domain-static

Les sélecteurs d’origine peuvent être utilisés pour acheminer le trafic de publication AEM vers le contenu statique d’AEM déployé à l’aide du pipeline front-end. Les cas d’utilisation incluent la diffusion de ressources statiques sur le même domaine que la page (par exemple, example.com/static) ou sur un domaine explicitement différent (par exemple, static.example.com).

Voici un exemple de règle de sélecteur d’origine qui peut accomplir cela :

kind: CDN
version: '1'
data:
  originSelectors:
    rules:
      - name: select-aem-static-origin
        when:
          reqProperty: domain
          equals: static.example.com
        action:
          type: selectAemOrigin
          originName: static

Proxy vers Edge Delivery Services proxying-to-edge-delivery

Il existe des scénarios où les sélecteurs d’origine doivent être utilisés pour acheminer le trafic via l’instance de publication AEM vers AEM Edge Delivery Services :

Voici un exemple de règle de sélecteur d’origine qui peut accomplir cela :

kind: CDN
version: '1'
data:
  originSelectors:
    rules:
      - name: select-edge-delivery-services-origin
        when:
          allOf:
            - reqProperty: tier
              equals: publish
            - reqProperty: domain
              equals: <Production Host>
            - reqProperty: path
              matches: "^(/scripts/.*|/styles/.*|/fonts/.*|/blocks/.*|/icons/.*|.*/media_.*|/favicon.ico)"
        action:
          type: selectOrigin
          originName: aem-live
    origins:
      - name: aem-live
        domain: main--repo--owner.aem.live

Proxy de l’environnement AEMaaCS proxying-to-aemaacs

Vous ne pouvez pas utiliser un domaine adobeaemcloud.com directement comme origine dans votre configuration de réseau CDN. Cette action est rejetée (le domaine ne doit pas contenir de .adobeaemcloud.com) pour se protéger contre les boucles de requête indésirables. Cela s’applique également au routage à partir d’un domaine installé pour un site Edge Delivery.

Si votre domaine personnalisé (www.example.com) est déjà installé dans un environnement AEMaaCS, le routage par défaut sera acheminé vers le serveur principal AEM sans règle CDN. Utilisez des sélecteurs d’origine lorsque vous devez acheminer le contenu d’un environnement à l’autre (par exemple, de pXXXX-eYYYY à pXXXX-eZZZZ) ou d’un site Edge Delivery vers un environnement AEMaaCS.

Dans ce cas, pour acheminer le trafic par proxy vers votre environnement AEM as a Cloud Service (par exemple, pour acheminer des chemins spécifiques tels que /graphql vers un serveur principal), installez un domaine personnalisé dans votre environnement AEMaaCS et utilisez ce domaine personnalisé comme origine dans votre configuration de réseau CDN.

Exemple : si votre niveau de publication AEM est accessible à l’adresse publish-pXXXXX-eYYYYY.adobeaemcloud.com, n’utilisez pas ce domaine dans originSelectors. Au lieu de cela :

kind: CDN
version: '1'
data:
  originSelectors:
    rules:
      - name: graphql-to-aem-publish
        when:
          allOf:
            - reqProperty: domain
              equals: www.example.com
            - reqProperty: originalPath
              like: /graphql*
        action:
          type: selectOrigin
          originName: aem-publish-origin
    origins:
      - name: aem-publish-origin
        domain: aem-publish-origin.example.com

Redirections côté serveur server-side-redirectors

Vous pouvez utiliser des règles de redirection côté client pour les redirections 301, 302 et autres redirections côté client similaires. Si une règle correspond, le réseau CDN répond avec une ligne d’état qui inclut le code d’état et le message (par exemple, HTTP/1.1 301 Moved Permanency), ainsi que l’ensemble d’en-têtes d’emplacement.

Les emplacements absolus et relatifs avec des valeurs fixes sont autorisés.

Notez que la taille cumulée du fichier de configuration, y compris les règles de filtrage du trafic, ne peut pas dépasser 100KB.

Exemple de configuration :

kind: "CDN"
version: "1"
data:
  redirects:
    rules:
      - name: redirect-absolute
        when: { reqProperty: originalPath, equals: "/page.html" }
        action:
          type: redirect
          status: 301
          location: https://example.com/page
      - name: redirect-relative
        when: { reqProperty: originalPath, equals: "/anotherpage.html" }
        action:
          type: redirect
          location: /anotherpage

Les emplacements d’une redirection peuvent être des littéraux de chaîne (par exemple, https://www.example.com/page) ou le résultat d’une propriété (par exemple, path) qui est éventuellement transformée, avec la syntaxe suivante :

redirects:
  rules:
    - name: country-code-redirect
      when: { reqProperty: path, like: "/" }
      action:
        type: redirect
        location:
          reqProperty: clientCountry
          transform:
            - op: replace
              match: '^(.*)


              replacement: 'https://www.example.com/\1/home'
            - op: tolower
    - name: www-redirect
      when: { reqProperty: domain, equals: "example.com" }
      action:
        type: redirect
        location:
          reqProperty: url
          transform:
            - op: replace
              match: '^/(.*)


              replacement: 'https://www.example.com/\1'