Google utilise la technologie IA pour traduire le contenu dans votre langue préférée. Les traductions générées par IA peuvent contenir des erreurs.

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

Vous consultez la documentation Apigee Edge.
Accédez à la documentation**Apigee X**. info

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 la 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'inactivité de la connexion se produit. Dans certains cas, un code d'état HTTP 504 peut être renvoyé lorsque `LoadBalancer` est utilisé dans la définition TargetServer et qu'un délai d'inactivité se produit. Remarque : Dans certains cas, Apigee tente automatiquement de relancer la connexion jusqu'à trois fois. Par conséquent, le délai total de nouvelle tentative peut dépasser ce qui est configuré pour `connect.timeout.millis`.
`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, `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 page Définir les paramètres io.timeout.millis et api.timeout pour Edge.
`supports.http10`	`true`	Si ce paramètre est défini sur `true` et que le client envoie une requête 1.0, une requête 1.0 est également envoyée à la cible. Sinon, la requête 1.1 est envoyée à la cible.
`supports.http11`	`true`	Si ce paramètre est défini sur `true` et que le client envoie une requête 1.1, une requête 1.1 est également envoyée à la cible. Sinon, une 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 `X-HTTP-Method-Override` en-tête sur la requête sortante vers le service cible. Par exemple, `<Property name="GET.override.method">POST</Property>`.
`*.override.method`	ND	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 de requête HTTP sont lues dans un tampon, et les règles qui peuvent s’appliquer à la charge utile fonctionnent comme prévu. Lorsque les charges utiles sont supérieures à la taille de la mémoire tampon (10 Mo), vous pouvez définir cet attribut sur `true`. Lorsque `true`, les charges utiles de requête HTTP ne sont pas lues dans un tampon ; elles sont diffusées telles quelles dans 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'appliquer à la charge utile fonctionnent comme prévu. Lorsque les charges utiles sont supérieures à la taille de la mémoire tampon (10 Mo), vous pouvez définir cet attribut sur `true`. Lorsque `true`, les charges utiles de réponse HTTP ne sont pas lues dans un tampon. Elles sont diffusées telles quelles dans 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 page Requêtes et réponses en flux continu.
`success.codes`	ND	Par défaut, Apigee Edge traite le code HTTP `4XX` ou `5XX` comme des erreurs, et le code HTTP `1XX`, `2XX`, `3XX` comme une réussite. Cette propriété active la définition explicite des codes de réussite, par exemple, `2XX, 1XX, 505` considère tous les codes de réponse HTTP `100`, `200` et `505` comme une réussite. 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> En définissant le code HTTP `400` comme seul code de réussite, les codes `1XX`, `2XX` et `3XX` sont traités comme des échecs.
`compression.algorithm`	ND	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. Consultez également l'article Does Apigee support compression/de-compression with GZIP/deflate compression?
`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 `request.retain.headers` propriété 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`	ND	Définit les en-têtes HTTP spécifiques de la réponse qui doivent être définis sur la réponse sortante avant que celle-ci ne soit transmise à ProxyEndpoint. Par exemple, pour transmettre 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`, tous les en-têtes spécifiés dans la propriété `response.retain.headers` sont toujours définis sur 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 la propriété	Valeur par défaut	Description
`X-Forwarded-For`	`false`	Lorsque cette propriété est définie sur `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 de requête HTTP sont lues dans un tampon, et les règles pouvant s’appliquer à la charge utile fonctionnent comme prévu. Lorsque 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êtes HTTP ne sont pas lues dans un tampon. Elles sont diffusées telles quelles dans le flux de requête 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'appliquer à la charge utile fonctionnent comme prévu. Lorsque 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 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`	ND	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. Consultez également l'article Does Apigee support compression/de-compression with GZIP/deflate compression?
`api.timeout`	ND	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 principal cas d'utilisation est destiné aux clients qui disposent de proxys d'API dont l'exécution prend plus de temps. 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. 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. 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>`. 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 d'inactivité Edge peuvent également configurer un délai d'inactivité du proxy d'API, tant que ce délai est inférieur au délai d'inactivité du processeur de messages Edge standard de 57 secondes. Pour en savoir plus, consultez la page Définir les paramètres io.timeout.millis et api.timeout pour Edge.

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

Sur Edge, le fonctionnement de io.timeout.millis et api.timeout est lié. À chaque requête envoyée à un proxy d'API :

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.
Le processeur de messages définit ensuite 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.
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.

Après l'exécution de chaque règle du proxy d'API, ou avant que le processeur de messages 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.
La valeur de io.timeout.millis spécifie la durée maximale pendant laquelle le point de terminaison cible peut répondre.

Avant la connexion à un point de terminaison cible, le processeur de messages détermine la valeur la plus faible entre (api.timeout - temps écoulé depuis le 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

Une balise <HostedTarget/> vide indique à Edge d'utiliser comme cible une application Node.js déployée dans l'environnement Hosted Targets. Pour en savoir plus, consultez la présentation de Hosted Targets.