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

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`	faux	Permet d'envoyer des requêtes POST sans contenu dans le corps.
`allow.put.without.content.length`	faux	Permet d'envoyer des requêtes PUT sans contenu dans le corps.
`allow.tls.session.resumption`	vrai	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. 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`.
`ignore.allow.header.for.405`	vrai	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`	vrai	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	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	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`	faux	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`	faux	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`	vrai	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`	vrai	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`	vrai	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`	faux	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`. Important : Le délai avant expiration spécifié doit être inférieur au délai standard du processeur de messages, qui est de 300 secondes. 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 :

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.
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.
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.
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é.