Types de conditions pour les règles d'écoute - Elastic Load Balancing
Conditions de l'en-tête HTTPConditions de la méthode de demande HTTPConditions d'hôteConditions de cheminConditions d'une chaîne de requêteConditions d'une adresse IP source

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Types de conditions pour les règles d'écoute

Les conditions définissent les critères auxquels les demandes entrantes doivent répondre pour qu'une règle d'écoute prenne effet. Si une demande répond aux conditions d'une règle, elle est traitée conformément aux actions de la règle. Chaque condition de règle comporte un type et des informations de configuration. Les équilibreurs de charge d'application prennent en charge les types de conditions suivants pour les règles d'écoute.

Types de conditions
host-header

Chemin basé sur le nom d'hôte de chaque demande. Pour de plus amples informations, veuillez consulter Conditions d'hôte.

http-header

Chemin basé sur les en-têtes HTTP pour chaque demande. Pour de plus amples informations, veuillez consulter Conditions de l'en-tête HTTP.

http-request-method

Chemin basé sur la méthode de demande HTTP de chaque demande. Pour de plus amples informations, veuillez consulter Conditions de la méthode de demande HTTP.

path-pattern

Route basée sur les modèles de chemin contenus dans la demande URLs. Pour de plus amples informations, veuillez consulter Conditions de chemin.

query-string

Route basée sur des key/value paires ou des valeurs dans les chaînes de requête. Pour de plus amples informations, veuillez consulter Conditions d'une chaîne de requête.

source-ip

Chemin basé sur l’adresse IP source de chaque demande. Pour de plus amples informations, veuillez consulter Conditions d'une adresse IP source.

Bases de la condition

  • Chaque règle peut éventuellement inclure une des conditions suivantes : host-header, http-request-method, path-pattern et source-ip. Chaque règle peut également inclure une ou plusieurs des conditions suivantes : http-header et query-string.

  • Vous pouvez spécifier jusqu’à trois évaluations de correspondances par condition. Par exemple, pour chaque condition http-header, vous pouvez spécifier jusqu'à trois chaînes à comparer avec la valeur de l'en-tête HTTP dans la demande. La condition est remplie si l'une des chaînes correspond à la valeur de l'en-tête HTTP. Pour exiger que toutes les chaînes correspondent, créez une condition par évaluation de correspondance.

  • Vous pouvez spécifier jusqu’à cinq évaluations de correspondances par règle. Vous pouvez, par exemple, créer une règle avec cinq conditions, où chaque condition possède une évaluation de correspondance.

  • Vous pouvez inclure des caractères génériques dans les évaluations de correspondances pour les conditions http-header, host-header, path-pattern et query-string. Le nombre de caractères génériques par règle est limité à cinq.

  • Les règles sont appliquées uniquement aux caractères ASCII visibles ; les caractères de contrôle (0x00 à 0x1f et 0x7f) sont exclus.

Démonstrations

Pour des démonstrations, consultez Routage avancé des demandes.

Conditions de l'en-tête HTTP

Vous pouvez utiliser des conditions de l’en-tête HTTP pour configurer des règles qui acheminent des demandes, en fonction des en-têtes HTTP de la demande. Vous pouvez spécifier les noms des champs d'en-tête HTTP standard ou personnalisés. Le nom de l'en-tête et l'évaluation de correspondance ne sont pas sensibles à la casse. Les caractères génériques suivants sont pris en charge dans les chaînes de comparaison : * (correspond à 0 caractères ou plus) et ? (correspond exactement à 1 caractère). Les caractères génériques ne sont pas pris en charge par le nom de l’en-tête.

Lorsque l'attribut Application Load Balancer routing.http.drop_invalid_header_fields est activé, il supprime les noms d'en-têtes non conformes aux expressions régulières ()A-Z,a-z,0-9. Les noms d'en-tête qui ne sont pas conformes aux expressions régulières peuvent également être ajoutés.

Exemple de condition d'en-tête HTTP pour AWS CLI

Vous pouvez spécifier des conditions lorsque vous créez ou modifiez une règle. Pour en savoir plus veuillez consulter les commandes create-rule et modify-rule. La condition suivante est remplie par les demandes avec un en-tête d’agent utilisateur qui correspond à l'une des chaînes spécifiées.

[
  {
      "Field": "http-header",
      "HttpHeaderConfig": {
          "HttpHeaderName": "User-Agent",
          "Values": ["*Chrome*", "*Safari*"]
      }
  }
]

Conditions de la méthode de demande HTTP

Vous pouvez utiliser des conditions de méthode de demande HTTP pour configurer des règles qui acheminent des demandes, en fonction de la méthode de demande HTTP de la demande. Vous pouvez spécifier des méthodes HTTP standard ou personnalisées. L’évaluation des correspondances est sensible à la casse. Les caractères génériques ne sont pas pris en charge, le nom de la méthode doit par conséquent correspondre exactement.

Nous vous recommandons d’acheminer les demandes GET et HEAD de la même manière, car la réponse à une demande HEAD peut être mise en cache.

Exemple de condition de méthode HTTP pour AWS CLI

Vous pouvez spécifier des conditions lorsque vous créez ou modifiez une règle. Pour en savoir plus veuillez consulter les commandes create-rule et modify-rule. La condition suivante est remplie par les demandes qui utilisent la méthode spécifiée.

[
  {
      "Field": "http-request-method",
      "HttpRequestMethodConfig": {
          "Values": ["CUSTOM-METHOD"]
      }
  }
]

Conditions d'hôte

Vous pouvez utiliser des conditions d'hôte afin de définir des règles qui acheminent des demandes en fonction du nom d'hôte de l'en-tête de l'hôte (également appelé routage basé sur l'hôte). Cela vous permet de prendre en charge plusieurs sous-domaines et différents domaines de premier niveau à l'aide d'un seul équilibreur de charge.

Le nom d'hôte n'est pas sensible à la casse, peut comporter jusqu'à 128 caractères et peut contenir les caractères suivants :

  • A à Z, a à z, 0 à 9

  • - .

  • * (correspond à 0 caractère ou plus)

  • ? (correspond à 1 caractère exactement)

Vous devez inclure au moins un caractère « . ». Vous pouvez inclure uniquement des caractères alphabétiques après le dernier caractère « . ».

Exemples de noms d'hôtes

  • example.com

  • test.example.com

  • *.example.com

La règle *.example.com correspond à test.example.com, mais ne correspond pas à example.com.

Exemple de condition d'en-tête d'hôte pour AWS CLI

Vous pouvez spécifier des conditions lorsque vous créez ou modifiez une règle. Pour en savoir plus veuillez consulter les commandes create-rule et modify-rule. La condition suivante est remplie par les demandes avec un en-tête d’hôte qui correspond à la chaîne spécifiée.

[
  {
      "Field": "host-header",
      "HostHeaderConfig": {
          "Values": ["*.example.com"]
      }
  }
]

Conditions de chemin

Vous pouvez utiliser des conditions de chemin d'accès afin de définir des règles qui acheminent les demandes sur la base de l'URL contenue dans la demande (routage basé sur le chemin d'accès).

Le modèle de chemin est appliqué uniquement au chemin d'accès de l'URL, pas à ses paramètres de requête. Il est appliqué uniquement aux caractères ASCII visibles ; les caractères de contrôle (0x00 à 0x1f et 0x7f) sont exclus.

L'évaluation des règles n'est effectuée qu'après normalisation de l'URI.

Un modèle de chemin est sensible à la casse, peut comporter jusqu'à 128 caractères et peut contenir les caractères suivants.

  • A à Z, a à z, 0 à 9

  • _ - . $ / ~ " ' @ : +

  • & (utilisation de &)

  • * (correspond à 0 caractère ou plus)

  • ? (correspond à 1 caractère exactement)

Si la version du protocole est gRPC, les conditions peuvent être spécifiques à un package, à un service ou à une méthode.

Exemples de modèles de chemins HTTP

  • /img/*

  • /img/*/pics

Exemples de modèles de chemins gRPC

  • /package

  • /package.service

  • /package.service/method

Le modèle de chemin est utilisé pour acheminer des demandes, mais il ne les modifie pas. Par exemple, si une règle a un motif de chemin d'accès de /img/*, la règle redirige une demande pour /img/picture.jpg vers le groupe cible spécifié en tant que demande pour /img/picture.jpg.

Exemple de condition de modèle de chemin pour AWS CLI

Vous pouvez spécifier des conditions lorsque vous créez ou modifiez une règle. Pour en savoir plus veuillez consulter les commandes create-rule et modify-rule. La condition suivante est remplie par les demandes avec une URL qui contient la chaîne spécifiée.

[
  {
      "Field": "path-pattern",
      "PathPatternConfig": {
          "Values": ["/img/*"]
      }
  }
]

Conditions d'une chaîne de requête

Vous pouvez utiliser les conditions de chaîne de requête pour configurer des règles qui acheminent les demandes en fonction de key/value paires ou de valeurs contenues dans la chaîne de requête. L’évaluation de correspondance n’est pas sensible à la casse. Les caractères génériques suivants sont pris en charge : * (correspond à 0 caractères ou plus) et ? (correspond exactement à 1 caractère).

Exemple de condition de chaîne de requête pour AWS CLI

Vous pouvez spécifier des conditions lorsque vous créez ou modifiez une règle. Pour en savoir plus veuillez consulter les commandes create-rule et modify-rule. La condition suivante est satisfaite par les demandes dont la chaîne de requête inclut soit une key/value paire de « version=v1 », soit une clé définie sur « exemple ».

[
  {
      "Field": "query-string",
      "QueryStringConfig": {
          "Values": [
            {
                "Key": "version", 
                "Value": "v1"
            },
            {
                "Value": "*example*"
            }
          ]
      }
  }
]

Conditions d'une adresse IP source

Vous pouvez utiliser des conditions d’adresse IP source pour configurer des règles qui acheminent des demandes, en fonction de l’adresse IP source de la demande. L’adresse IP doit être spécifiée au format CIDR. Vous pouvez utiliser à la fois les IPv6 adresses IPv4 et les adresses. Les caractères génériques ne sont pas pris en charge. Vous ne pouvez pas spécifier le CIDR 255.255.255.255/32 pour la condition de règle IP source.

Si un client se trouve derrière un proxy, il s'agit de l'adresse IP du proxy et non de l'adresse IP du client.

Cette condition n'est pas satisfaite par les adresses figurant dans l' X-Forwarded-Foren-tête. Pour rechercher des adresses dans l' X-Forwarded-Foren-tête, utilisez une http-header condition.

Exemple de condition IP source pour AWS CLI

Vous pouvez spécifier des conditions lorsque vous créez ou modifiez une règle. Pour en savoir plus veuillez consulter les commandes create-rule et modify-rule. La condition suivante est remplie par les demandes avec une adresse IP source dans l’un des blocs CIDR spécifiés.

[
  {
      "Field": "source-ip",
      "SourceIpConfig": {
          "Values": ["192.0.2.0/24", "198.51.100.10/32"]
      }
  }
]