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

Cette page s'applique à Apigee et à Apigee hybrid.

Consultez la documentation d'Apigee Edge.

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 options de configuration TargetEndpoint et ProxyEndpoint, consultez la documentation de référence sur la configuration des proxys 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 TargetEndpoint, comme indiqué dans cet exemple de configuration :

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

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

Nom de la propriété Valeur par défaut Description
allow.post.without.content.length false Permet d'envoyer des requêtes POST sans contenu dans le corps.
allow.put.without.content.length false Permet d'envoyer des requêtes PUT sans contenu dans le corps.
allow.tls.session.resumption true Si true (valeur par défaut), les clients réutilisent les sessions TLS lors de l'établissement de nouvelles connexions à la cible. Définissez la valeur sur false si vous ne souhaitez pas réutiliser les sessions TLS. La réutilisation des sessions implique généralement des temps de connexion plus courts, mais il est possible que certaines cibles ne soient pas compatibles ou aient des difficultés avec la réutilisation de session.
keepalive.timeout.millis 60 000 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

3 000

Délai d'inactivité de la connexion cible Apigee renvoie un code d'état HTTP 503 en cas d'expiration du délai de connexion. Dans certains cas, un code d'état HTTP 504 peut être renvoyé lorsque LoadBalancer est utilisé dans la définition de TargetServer et qu'un délai avant expiration se produit.
ignore.allow.header.for.405

true

Permet de renvoyer le code d'état 405 au client. Si vous activez l'option, Apigee renvoie 405 au lieu du code d'état 502.
io.timeout.millis 55 000

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 la lecture de la requête HTTP depuis l'entrée, 408 Request Timeout est renvoyé. 408 Request Timeout ne sera pas renvoyé si un délai d'inactivité se produit lors de l'écriture d'une requête à la cible.
  • Si un délai d'inactivité se produit lors de l'écriture de la requête HTTP ou de la lecture de la réponse HTTP, 504 Gateway Timeout est renvoyé.

Consultez la section Définir io.timeout.millis et api.timeout.
supports.http11 true Si ce paramètre est défini sur true et que le client envoie une requête 1.1, la cible est également envoyée à une requête 1.1. Si ce n'est pas le cas, une requête 1.0 est envoyée à la cible.
use.proxy true

Cette propriété s'applique uniquement à Apigee hybrid.

Si le fichier de remplacement Apigee hybrid contient la configuration HTTP_PROXY, comme décrit dans la section Configurer le proxy de transfert pour les proxys d'API, utilisez cette propriété pour gérer/contrôler quels proxys ne doivent pas utiliser la configuration de proxy.

Si la valeur est false, le proxy d'API ignore les configurations de proxy HTTP spécifiées dans le fichier de remplacement Apigee hybrid pour les connexions cibles définies dans le proxy.

use.proxy.tunneling true

Cette propriété s'applique uniquement à Apigee hybrid.

Si cette valeur est définie sur "true" et que des configurations de proxy sont spécifiées dans le fichier de remplacement Apigee hybrid, comme décrit dans la section Configurer le proxy de transfert pour les proxys d'API, les connexions cibles sont définies pour utiliser Tunnel spécifié. Si la cible utilise TLS/SSL, cette propriété est ignorée et le message est toujours envoyé à l'aide d'un tunnel.

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 dans Apigee), vous pouvez définir cet attribut sur true. Lorsque ce paramètre est défini sur 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, toutes 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 pouvant s'appliquer à la charge utile fonctionnent comme prévu. Lorsque les charges utiles sont supérieures à la taille de la mémoire tampon, vous pouvez définir cet attribut sur "true". Lorsque le paramètre est défini sur "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 N/A

Par défaut, Apigee traite le code HTTP 4XX ou 5XX comme des erreurs, et le code HTTP 1XX, 2XX, 3XX est traité 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>

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 respecte le type de compression défini (gzip, deflate ou aucun) pour les messages reçus. Si la requête est reçue par un client qui utilise, par exemple, une compression gzip, Apigee transmet la requête à la cible à l'aide de la compression gzip. Si la réponse reçue de la cible utilise Deflate, Apigee 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 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 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 à ProxyEndpoint.
response.retain.headers N/A 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 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 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 ProxyEndpoint, comme indiqué dans cet exemple de configuration :

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

En-têtes de requête

Une requête HTTP entrante inclut des en-têtes HTTP envoyés par le client. Les en-têtes dont le nom correspond au format X-Apigee-* sont supprimés des requêtes entrantes si un client les envoie. Ce format de nom est réservé à Apigee.

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 X-Forwarded-For HTTP.
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 dans Apigee), vous pouvez définir cet attribut sur true. Lorsque la valeur est définie sur 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 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 dans Apigee), vous pouvez définir cet attribut sur true. Lorsque la valeur est définie sur 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'appliquent 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 respecte le type de compression défini (gzip, deflate ou aucun) pour les messages reçus. Par exemple, si un client envoie une requête utilisant la compression gzip, Apigee 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 TargetEndpoint ou 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 N/A

Configurer le délai d'inactivité pour des proxy d'API individuels (en millisecondes)

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.

Par exemple, pour configurer un proxy pour qu'il expire après 180 000 millisecondes (trois minutes), ajoutez la propriété suivante à HTTPProxyConnection : 

<Property name="api.timeout">180000</Property>

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

Consultez la section Définir io.timeout.millis et api.timeout.
HTTPHeader.allowDuplicates N/A

Utilisez ce paramètre pour autoriser les en-têtes en double (pour des en-têtes spécifiques).

<HTTPProxyConnection>
  <Properties>
     <Property name="HTTPHeader.allowDuplicates">Content-Type,Authorization</Property>
  </Properties>
</HTTPProxyConnection>
HTTPHeader.multiValued N/A

Utilisez ce paramètre pour autoriser les en-têtes en double (pour des en-têtes spécifiques).

<HTTPProxyConnection>
  <Properties>
    <Property name="HTTPHeader.multiValued">Content-Type,Authorization</Property>
  </Properties>
</HTTPProxyConnection>

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

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

  1. La ressource Ingress (équilibreur de charge interne) envoie sa valeur de délai avant expiration au processeur de messages. La valeur par défaut du délai avant expiration est de 300 secondes et n'est pas configurable.
  2. Le processeur de messages définit ensuite api.timeout :
    1. Si api.timeout n'est pas défini au niveau du proxy, utilisez le délai avant expiration défini par la ressource Ingress.
    2. Si api.timeout est défini au niveau du proxy, définissez-la valeur pour le processeur de messages sur la valeur la plus faible entre le délai d'expiration de la ressource Ingress 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.

    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 Gateway Timeout.

  4. 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 ou de la lecture de la réponse HTTP, 504 Gateway Timeout est renvoyé.