Documentation de référence sur les propriétés des points de terminaison

Vous consultez la documentation d'Apigee Edge.
Consultez la documentation Apigee X. en savoir plus

Cet article décrit les propriétés de transport qui peuvent être définies dans les configurations TargetEndpoint et ProxyEndpoint pour contrôler le comportement de la messagerie et de la connexion. Pour une couverture complète des configurations TargetEndpoint et ProxyEndpoint, consultez la documentation de référence sur la configuration de proxy d'API.

Propriétés de transport TargetEndpoint

L'élément HTTPTargetConnection dans les configurations TargetEndpoint définit un ensemble de propriétés de transport HTTP. Vous pouvez utiliser ces propriétés pour définir des configurations au niveau du transport.

Les propriétés sont définies sur les éléments HTTPTargetConnection de TargetEndpoint comme indiqué ci-dessous :

<TargetEndpoint name="default">
  <HTTPTargetConnection>
    <URL>http://mocktarget.apigee.net</URL>
    <Properties>
      <Property name="supports.http10">true</Property>
      <Property name="request.retain.headers">User-Agent,Referer,Accept-Language</Property>
      <Property name="retain.queryparams">apikey</Property>
    </Properties>
    <CommonName>COMMON_NAME_HERE</CommonName>
  </HTTPTargetConnection>
</TargetEndpoint>

Spécification de la propriété de transport TargetEndpoint

Nom de propriété Valeur par défaut Description
keepalive.timeout.millis 60000 Délai d'inactivité pour la connexion cible dans le pool de connexions. Si la connexion au pool est inactive au-delà de la limite spécifiée, la connexion est fermée.
connect.timeout.millis

3000

Délai d'inactivité de la connexion cible Edge renvoie un code d'état HTTP 503 si un délai d'expiration de la connexion se produit.
io.timeout.millis 55000

Si aucune donnée n'est disponible pour le nombre de millisecondes spécifié ou si le socket n'est pas prêt à écrire des données pour le nombre de millisecondes spécifié, la transaction est traitée comme un délai d'inactivité.

  • Si un délai d'inactivité se produit lors de l'écriture de la requête HTTP, le code 408, Request Timeout est renvoyé.
  • Si un délai d'inactivité se produit lors de la lecture de la réponse HTTP, le code 504, Gateway Timeout est renvoyé.

Cette valeur doit toujours être inférieure à celle de la propriété proxy_read_timeout de l'hôte virtuel.

Cette valeur doit être inférieure au délai d'inactivité utilisé par le routeur pour communiquer avec le processeur de messages. Pour en savoir plus, consultez la page Configurer le délai d'inactivité du routeur.

Pour en savoir plus, consultez la section Définir io.timeout.millis et api.timeout pour Edge.
supports.http10 true Si la valeur est true et que le client envoie une requête 1.0, la cible reçoit également une requête 1.0. Sinon, la requête 1.1 est envoyée à la cible.
supports.http11 true Si la valeur est true et que le client envoie une requête 1.1, la cible reçoit également une requête 1.1. Sinon, la requête 1.0 est envoyée à la cible.
use.proxy true Si ce paramètre est défini sur true et que les configurations de proxy sont spécifiées dans http.properties (déploiements sur site uniquement), les connexions cibles sont définies pour utiliser le proxy spécifié.
use.proxy.tunneling true Si ce paramètre est défini sur true et que les configurations de proxy sont spécifiées dans http.properties (déploiements sur site uniquement), les connexions cibles sont définies pour utiliser le tunnel spécifié. Si la cible utilise TLS/SSL, cette propriété est ignorée et le message est toujours envoyé via un tunnel.
enable.method.override false Pour la méthode HTTP spécifiée, définit un en-tête X-HTTP-Method-Override sur la requête sortante vers le service cible. Par exemple, <Property name="GET.override.method">POST</Property>.
*.override.method N/A Pour la méthode HTTP spécifiée, définit un en-tête X-HTTP-Method-Override sur la requête sortante. Par exemple, <Property name="GET.override.method">POST</Property>.
request.streaming.enabled false

Par défaut (false), les charges utiles des requêtes HTTP sont lues dans un tampon, et les règles qui peuvent s'exécuter sur la charge utile fonctionnent comme prévu. Si les charges utiles sont supérieures à la taille de la mémoire tampon (10 Mo), vous pouvez définir cet attribut sur true. Lorsque la valeur est true, les charges utiles de requête HTTP ne sont pas lues dans un tampon, mais diffusées telles quelles vers le point de terminaison cible. Dans ce cas, les règles qui s'exécutent sur la charge utile dans le flux de requête TargetEndpoint sont ignorées. Consultez également la page Requêtes et réponses en flux continu.
response.streaming.enabled false

Par défaut (false), les charges utiles de réponse HTTP sont lues dans un tampon, et les règles qui peuvent s'exécuter sur la charge utile fonctionnent comme prévu. Si les charges utiles sont supérieures à la taille de la mémoire tampon (10 Mo), vous pouvez définir cet attribut sur true. Lorsque la valeur est true, les charges utiles de réponse HTTP ne sont pas lues dans un tampon ; elles sont diffusées telles quelles vers le flux de réponse ProxyEndpoint. Dans ce cas, toutes les règles qui s'appliquent sur la charge utile dans le flux de réponse TargetEndpoint sont ignorées. Consultez également la section Requêtes et réponses en flux continu.
success.codes N/A

Par défaut, Apigee Edge traite le code HTTP 4XX ou 5XX comme des erreurs, et le code HTTP 1XX, 2XX et 3XX comme une réussite. Cette propriété permet de définir explicitement des codes de réussite. Par exemple, 2XX, 1XX, 505 traite les codes de réponse HTTP 100, 200 et 505 comme des réussites.

La définition de cette propriété écrase les valeurs par défaut. Par conséquent, si vous souhaitez ajouter le code HTTP 400 à la liste des codes de réussite par défaut, définissez cette propriété comme suit :

<Property name="success.codes">1XX,2XX,3XX,400</Property>

Si vous souhaitez que seul le code HTTP 400 soit traité comme code de réussite, définissez la propriété comme suit :

<Property name="success.codes">400</Property>

Si vous définissez le code HTTP 400 comme seul code de réussite, les codes 1XX, 2XX et 3XX sont traités comme des échecs.
compression.algorithm N/A Par défaut, Apigee Edge transmet les requêtes à la cible en utilisant le même type de compression que la requête du client. Si la requête est reçue par un client qui utilise, par exemple, une compression gzip, Apigee Edge transmet la requête à la cible à l'aide de la compression gzip. Si la réponse reçue de la cible utilise Deflate, Apigee Edge transmet la réponse au client à l'aide de Deflate. Les valeurs compatibles sont :
  • gzip: : le message est toujours envoyé à l'aide de la compression gzip.
  • deflate : le message est toujours envoyé à l'aide de la compression Deflate.
  • aucun : le message est toujours envoyé sans compression.

Voir aussi: Apigee est-il compatible avec la compression/décompression avec GZIP/deflate ?
request.retain.headers.
enabled		 true Par défaut, Apigee Edge conserve toujours tous les en-têtes HTTP des messages sortants. Lorsque ce paramètre est défini sur true, tous les en-têtes HTTP présents dans la requête entrante sont définis sur la requête sortante.
request.retain.headers N/A Définit les en-têtes HTTP spécifiques de la requête qui doivent être définis sur la requête sortante vers le service cible. Par exemple, pour transmettre l'en-tête User-Agent, définissez la valeur de request.retain.headers sur User-Agent. Plusieurs en-têtes HTTP sont spécifiés sous la forme d'une liste d'éléments séparés par une virgule (par exemple, User-Agent,Referer,Accept-Language). Cette propriété remplace request.retain.headers.enabled. Si request.retain.headers.enabled est défini sur false, tous les en-têtes spécifiés dans la propriété request.retain.headers sont toujours définis sur le message sortant.
response.retain.headers.
enabled		 true Par défaut, Apigee Edge conserve toujours tous les en-têtes HTTP des messages sortants. Lorsque ce paramètre est défini sur true, tous les en-têtes HTTP présents dans la réponse entrante du service cible sont définis sur la réponse sortante avant que celle-ci ne soit transmise au ProxyEndpoint.
response.retain.headers N/A Définit des en-têtes HTTP spécifiques de la réponse qui doivent être définis sur la réponse sortante avant de la transmettre au ProxyEndpoint. Par exemple, pour contourner l'en-tête Expires, définissez la valeur de response.retain.headers sur Expires. Plusieurs en-têtes HTTP sont spécifiés sous la forme d'une liste d'éléments séparés par une virgule (par exemple, Expires,Set-Cookie). Cette propriété remplace response.retain.headers.enabled. Si response.retain.headers.enabled est défini sur false, les en-têtes spécifiés dans la propriété response.retain.headers restent définis dans le message sortant.
retain.queryparams.
enabled		 true Par défaut, Apigee Edge conserve toujours tous les paramètres de requête sur les requêtes sortantes. Lorsqu'ils sont définis sur true, tous les paramètres de requête présents dans la requête entrante sont définis sur la requête sortante vers le service cible.
retain.queryparams N/A Définit des paramètres de requête spécifiques à définir sur la requête sortante. Par exemple, pour inclure le paramètre de requête apikey à partir du message de requête, définissez retain.queryparams sur apikey. Plusieurs paramètres de requête sont spécifiés sous forme de liste d'éléments séparés par une virgule, par exemple apikey,environment. Cette propriété remplace retain.queryparams.enabled.

Propriétés de transport ProxyEndpoint

Les éléments HTTPTargetConnection de ProxyEndpoint définissent un ensemble de propriétés de transport HTTP. Ces propriétés permettent de définir des configurations au niveau du transport.

Les propriétés sont définies sur les éléments HTTPProxyConnection de ProxyEndpoint comme suit :

<ProxyEndpoint name="default">
  <HTTPProxyConnection>
    <BasePath>/v1/weather</BasePath>
    <Properties>
      <Property name="request.streaming.enabled">true</Property>
    </Properties>
    <VirtualHost>default</VirtualHost>
    <VirtualHost>secure</VirtualHost>
  </HTTPProxyConnection>
</ProxyEndpoint>

Pour plus d'informations sur les hôtes virtuels, voir À propos des hôtes virtuels.

Spécification de la propriété de transport ProxyEndpoint

Nom de propriété Valeur par défaut Description
X-Forwarded-For false Lorsque la valeur est true, l'adresse IP de l'hôte virtuel est ajoutée à la requête sortante en tant que valeur de l'en-tête HTTP X-Forwarded-For.
request.streaming.
enabled		 false Par défaut (false), les charges utiles des requêtes HTTP sont lues dans un tampon, et les règles pouvant s'exécuter sur la charge utile fonctionnent comme prévu. Si les charges utiles sont supérieures à la taille de la mémoire tampon (10 Mo), vous pouvez définir cet attribut sur true. Lorsque la valeur est true, les charges utiles de requête HTTP ne sont pas lues dans un tampon. Elles sont transmises telles quelles au flux de requêtes TargetEndpoint. Dans ce cas, toutes les règles qui s'exécutent sur la charge utile dans le flux de requête ProxyEndpoint sont ignorées. Consultez également la page Requêtes et réponses en flux continu.
response.streaming.
enabled		 false Par défaut (false), les charges utiles de réponse HTTP sont lues dans un tampon, et les règles qui peuvent s'exécuter sur la charge utile fonctionnent comme prévu. Si les charges utiles sont supérieures à la taille de la mémoire tampon (10 Mo), vous pouvez définir cet attribut sur true. Lorsque la valeur est true, les charges utiles de réponse HTTP ne sont pas lues dans un tampon, mais diffusées telles quelles vers le client. Dans ce cas, toutes les règles qui s'exécutent sur la charge utile dans le flux de réponse ProxyEndpoint sont ignorées. Consultez également la page Requêtes et réponses en flux continu.
compression.algorithm N/A

Par défaut, Apigee Edge respecte le type de compression défini pour chaque message reçu. Par exemple, si un client envoie une requête utilisant la compression gzip, Apigee Edge transmet la requête à la cible à l'aide de la compression gzip. Vous pouvez configurer les algorithmes de compression pour qu'ils soient explicitement appliqués en définissant cette propriété sur le TargetEndpoint ou le ProxyEndpoint. Les valeurs compatibles sont :

  • gzip: : le message est toujours envoyé à l'aide de la compression gzip.
  • deflate : le message est toujours envoyé à l'aide de la compression Deflate.
  • aucun : le message est toujours envoyé sans compression.

Voir aussi: Apigee est-il compatible avec la compression/décompression avec GZIP/deflate ?
api.timeout N/A

Configurer le délai d'inactivité pour des proxy d'API individuels

Vous pouvez configurer des proxys d'API, même ceux pour lesquels la diffusion est activée, afin qu'ils expirent au bout d'une période spécifiée avec un état 504 Gateway Timeout. Le cas d'utilisation principal concerne les clients dont l'exécution prend plus de temps que des proxys d'API. Par exemple, supposons que vous ayez besoin que des proxys spécifiques dépassent le délai au bout de 3 minutes. Vous utiliserez api.timeout comme suit.

  1. Commencez par configurer l'équilibreur de charge, le routeur et le processeur de messages pour qu'ils dépassent le délai après trois minutes.
  2. Configurez ensuite les proxys concernés pour qu'ils dépassent le délai au bout de trois minutes Spécifiez la valeur en millisecondes. Par exemple : <Property name="api.timeout">180000</Property>
  3. Notez toutefois que l'augmentation des délais d'inactivité du système peut entraîner des problèmes de performances, car tous les proxys sans paramètre api.timeout utilisent les nouveaux délais d'inactivité plus élevés de l'équilibreur de charge, du routeur et du processeur de messages. Configurez donc d'autres proxys d'API qui ne nécessitent pas de délais d'inactivité plus longs afin d'utiliser des délais d'inactivité plus courts. Par exemple, la commande suivante définit le délai d'inactivité d'un proxy d'API au bout d'une minute :
    <Property name="api.timeout">60000</Property>

Vous ne pouvez pas définir cette propriété avec une variable.

Les clients, qui ne peuvent pas modifier les délais avant expiration Edge, peuvent également configurer un délai avant expiration du proxy d'API, à condition qu'il soit inférieur au délai avant expiration du processeur de messages Edge standard de 57 secondes.

Pour en savoir plus, consultez la section Définir io.timeout.millis et api.timeout pour Edge.

Définir io.timeout.millis et api.timeout pour Edge

Sur Edge, les opérations de io.timeout.millis et api.timeout sont liées. À chaque requête envoyée à un proxy d'API :

  1. Le routeur envoie sa valeur de délai d'inactivité au processeur de messages. La valeur du délai avant expiration du routeur correspond soit à la valeur proxy_read_timeout définie par l'hôte virtuel qui gère la requête, soit à la valeur par défaut de 57 secondes.
  2. Le processeur de messages définit alors api.timeout :
    1. Si api.timeout n'est pas défini au niveau du proxy, définissez-le sur le délai d'inactivité du routeur.
    2. Si api.timeout est défini au niveau du proxy, définissez-le sur le processeur de messages sur la valeur inférieure du délai d'inactivité du routeur ou la valeur de api.timeout.

  3. La valeur de api.timeout spécifie la durée maximale pendant laquelle un proxy d'API doit s'exécuter à partir de la requête API à la réponse.

    Une fois que chaque stratégie du proxy d'API est exécutée, ou avant que le processeur de messages n'envoie la requête au point de terminaison cible, le processeur de messages calcule (api.timeout - temps écoulé depuis le début de la requête). Si la valeur est inférieure à zéro, le délai maximal de traitement de la requête a expiré et le processeur de messages renvoie 504.

  4. La valeur de io.timeout.millis spécifie la durée maximale pendant laquelle le point de terminaison cible peut répondre.

    Avant de se connecter à un point de terminaison cible, le processeur de messages détermine la valeur la plus faible de (api.timeout - temps écoulé à partir du début de la requête) et io.timeout.millis. Il définit ensuite io.timeout.millis sur cette valeur.

    • Si un délai d'inactivité se produit lors de l'écriture de la requête HTTP, le code 408, Request Timeout est renvoyé.
    • Si un délai d'inactivité se produit lors de la lecture de la réponse HTTP, le code 504, Gateway Timeout est renvoyé.

À propos de ScriptTarget pour les applications Node.js

L'élément ScriptTarget permet d'intégrer une application Node.js à votre proxy. Pour en savoir plus sur l'utilisation de Node.js et de ScriptTarget, consultez les pages suivantes:

À propos des points de terminaison HostedTarget

Un tag <HostedTarget/> vide indique à Edge d'utiliser comme cible une application Node.js déployée dans l'environnement de cibles hébergées. Pour en savoir plus, consultez la section Présentation des cibles hébergées.