Cette page a été traduite par l'API Cloud Translation.

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

<ph type="x-smartling-placeholder"></ph> Vous consultez la documentation Apigee Edge.
Accédez à la page Documentation sur 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 des configurations TargetEndpoint définit un ensemble des propriétés de transport. 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>

Propriété de transport TargetEndpoint Spécification

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 une connexion le délai avant expiration. Dans certains cas, un code d'état HTTP 504 peut être renvoyé lorsque `LoadBalancer` est utilisé dans la définition du serveur cible. et un délai avant expiration se produit. Remarque : Dans certains cas, Apigee tente automatiquement de relancer la connexion jusqu'à trois fois. Par conséquent, le temps total de nouvelle tentative peut dépasser la configuration configurée 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, 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 Routeur pour communiquer avec le processeur de messages. Pour en savoir plus, consultez la page Configurer le délai d'inactivité du routeur. Voir Définir io.timeout.millis et api.timeout pour Edge pour en savoir plus.
`supports.http10`	`true`	Si cette valeur est `true` et que le client envoie une requête 1.0, la cible reçoit également une valeur 1.0. requête. Sinon, la requête 1.1 est envoyée à la cible.
`supports.http11`	`true`	Si cette 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`	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êtes HTTP sont lues dans un tampon, et les règles qui peut fonctionner comme prévu sur la charge utile. Dans les cas où les charges utiles sont supérieures à la taille de la mémoire tampon (10 Mo), vous pouvez la définir à `true`. Lorsque la valeur est `true`, les charges utiles de requêtes HTTP ne sont pas lues dans un tampon. ils sont 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 section Requêtes et réponses de streaming.
`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 peut fonctionner comme prévu sur la charge utile. Dans les cas où les charges utiles sont supérieures à la taille de la mémoire tampon (10 Mo), vous pouvez la définir à `true`. Lorsque la valeur est `true`, les charges utiles de réponse HTTP ne sont pas lues dans un tampon. ils 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. Voir aussi Les requêtes en flux continu et réponses.
`success.codes`	N/A	Par défaut, Apigee Edge traite le code HTTP `4XX` ou `5XX` comme des erreurs, ainsi que le code HTTP. `1XX`, `2XX` et `3XX` comme réussite. Cette propriété permet de définir explicitement les codes de réussite, par Par exemple, `2XX, 1XX, 505` traite tous les codes de réponse HTTP `100`, `200` et `505` comme avec succès. 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 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 prend-il en charge la compression/décompression avec la compression 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`	ND	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`	ND	Définit les en-têtes HTTP spécifiques de la réponse qui doivent être définis sur le trafic sortant avant d'être transmis au ProxyEndpoint. Par exemple, pour effectuer un passthrough, `Expires`, définissez la valeur de `response.retain.headers` sur `Expires` Plusieurs en-têtes HTTP sont spécifiés sous forme de 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ées dans la propriété `response.retain.headers` sont toujours définies sur la 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`	ND	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.

Propriété de transport ProxyEndpoint Spécification

Nom de la propriété	Valeur par défaut	Description
`X-Forwarded-For`	`false`	Si la valeur est `true`, l'adresse IP de l'hôte virtuel est ajoutée à la requête sortante en tant que de l'en-tête HTTP `X-Forwarded-For`.
`request.streaming. enabled`	`false`	Par défaut (`false`), les charges utiles de requêtes HTTP sont lues dans un tampon et les règles pouvant opèrent sur la charge utile comme prévu. Dans les cas où les charges utiles sont supérieures à de la mémoire tampon (10 Mo), vous pouvez la définir à `true`. Lorsque la valeur est `true`, les charges utiles de requêtes HTTP ne sont pas lues dans un tampon. ils sont diffusées telles quelles vers le 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 section Requêtes et réponses de streaming.
`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 peut fonctionner comme prévu sur la charge utile. Dans les cas où les charges utiles sont supérieures à la taille de la mémoire tampon (10 Mo), vous pouvez la définir à `true`. Lorsque la valeur est `true`, les charges utiles de réponse HTTP ne sont pas lues dans un tampon. ils sont diffusées telles quelles au 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 section Requêtes et réponses de streaming.
`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. Voir aussi: Apigee prend-il en charge la compression/décompression avec la compression 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 principal cas d'utilisation concerne les clients disposant 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 dans 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 proxy d'API délai avant expiration, à condition qu'il soit plus court que celui du processeur de messages Edge standard et un délai avant expiration de 57 secondes. Voir Définir io.timeout.millis et api.timeout pour Edge pour en savoir plus.

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

Sur Edge, le fonctionnement de io.timeout.millis et api.timeout sont liés. À 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 stratégie dans le 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, cela signifie que la durée maximale de traitement de la requête a expiré. 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 de se connecter à un point de terminaison cible, le processeur de messages détermine le plus petit (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 sur l'utilisation de Node.js et ScriptTarget, consultez les pages suivantes:

À propos des points de terminaison HostedTarget

Une balise <HostedTarget/> vide indique à Edge d'utiliser comme cible un nœud.js qui est déployée dans l'environnement de cibles hébergées. Pour en savoir plus, consultez Présentation des cibles hébergées