Referencia de propiedades de extremos

Esta página se aplica a Apigee y Apigee Hybrid.

Consulta la documentación de Apigee Edge.

En este tema, se describen las propiedades de transporte que se pueden establecer en la configuración TargetEndpoint y ProxyEndpoint para controlar el comportamiento de los mensajes y la conexión. Para obtener una cobertura completa de las opciones de configuración TargetEndpoint y ProxyEndpoint, consulta la referencia de la configuración del proxy de API.

Propiedades de transporte de TargetEndpoint

El elemento HTTPTargetConnection en la configuración TargetEndpoint define un conjunto de propiedades de transporte HTTP. Puedes usar estas propiedades para establecer las opciones de configuración de nivel de transporte.

Las propiedades se establecen en elementos TargetEndpoint y HTTPTargetConnection como se muestra en esta configuración de ejemplo:

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

Especificación de la propiedad de transporte de TargetEndpoint

Nombre de la propiedad	Valor predeterminado	Descripción
`allow.post.without.content.length`	falso	Te permite enviar solicitudes POST sin contenido en el cuerpo.
`allow.put.without.content.length`	falso	Te permite enviar solicitudes PUT sin contenido en el cuerpo.
`allow.tls.session.resumption`	true	Si los clientes `true` (predeterminado) reutilizan las sesiones de TLS cuando realizan conexiones nuevas al destino. Configúralo en `false` si no deseas que se vuelva a usar la sesión TLS. Por lo general, la reutilización de sesiones implica tiempos de conexión más cortos, pero es posible que algunos objetivos no admitan la reutilización de sesiones o tengan dificultades.
`keepalive.timeout.millis`	60,000	Tiempo de espera de inactividad de la conexión de destino para la conexión de destino en el grupo de conexiones. Si la conexión en el grupo está inactiva más allá del límite especificado, la conexión se cierra.
`connect.timeout.millis`	3000	Tiempo de espera de conexión de destino Apigee muestra un código de estado HTTP `503` si se produce un tiempo de espera de conexión. En algunos casos, se puede mostrar un código de estado HTTP `504` cuando se usa `LoadBalancer` en la definición de TargetServer y se agota el tiempo de espera. Nota: En algunos casos, Apigee volverá a intentar la conexión de forma automática hasta tres veces. Como resultado, el tiempo total de reintento puede exceder lo que se configuró para `connect.timeout.millis`.
`ignore.allow.header.for.405`	true	Te permite pasar el código de estado 405 al cliente. Si se habilita la marca, Apigee mostrará 405 en lugar de 502 código de estado.
`io.timeout.millis`	55000	Si no hay datos para leer durante la cantidad de milisegundos especificada o si el socket no está listo para escribir datos para la cantidad de milisegundos especificada, entonces, la transacción se considera como tiempo de espera. Si se agota el tiempo de espera mientras se lee la solicitud HTTP desde la entrada, se muestra `408 Request Timeout`. No se mostrará `408 Request Timeout` si se agota el tiempo de espera mientras se escribe una solicitud en el destino. Si se agota el tiempo de espera mientras se escribe la solicitud HTTP o se lee la respuesta HTTP, se muestra `504 Gateway Timeout`. Nota: Si usas conexiones de WebSocket, cualquier tiempo de espera establecido por encima del valor predeterminado de 5,500 mediante esta propiedad no se respetará si la conexión de WebSocket está inactiva. La conexión se cerrará después de 55 segundos. Consulta Configuración de io.timeout.millis y api.timeout.
`supports.http11`	true	Si es `true` y el cliente envía una solicitud `1.1`, el destino también recibe una solicitud `1.1`; de lo contrario, recibe la solicitud `1.0`.
`use.proxy`	true	Esta propiedad se aplica solo a Apigee Hybrid. Si el archivo de anulación de Apigee Hybrid contiene la configuración de `HTTP_PROXY`, como se describe en Configura proxy de reenvío para proxies de API, usa esta propiedad a fin de administrar o controlar qué proxies no deben usar la configuración del proxy. Si se configura como `false`, el proxy de API omitirá los parámetros de configuración de proxy HTTP especificados en el archivo de anulaciones híbridas de Apigee para las conexiones de destino establecidas en el proxy.
`use.proxy.tunneling`	true	Esta propiedad se aplica solo a Apigee Hybrid. Si se establece como verdadero y las opciones de configuración de proxy se especifican en el archivo de anulaciones híbridas de Apigee como se describe en Configura proxies de reenvío para proxies de API, entonces las conexiones de destino se configuran para usar el túnel especificado. Si el destino usa TLS/SSL, esta propiedad se ignora y el mensaje se envía siempre a través de un túnel.
`request.streaming.enabled`	falso	Según la configuración predeterminada (`false`), las cargas útiles de la solicitud HTTP se leen en un búfer y las políticas que pueden operar en la carga útil funcionan de la manera esperada. En los casos en que las cargas útiles sean más grandes que el tamaño del búfer (10 MB en Apigee), puedes establecer este atributo como `true`. Cuando es `true`, las cargas útiles de la solicitud HTTP no se leen en un búfer, se transmiten sin modificaciones al extremo de destino. En este caso, se omiten las políticas que funcionan en la carga útil del flujo de solicitud `TargetEndpoint`. Consulta también Solicitudes y respuestas de transmisión.
`response.streaming.enabled`	falso	Según la configuración predeterminada (falso), las cargas útiles de la respuesta HTTP se leen en un búfer y las políticas que pueden operar en la carga útil funcionan de la manera esperada. En los casos en que las cargas útiles sean más grandes que el tamaño del búfer (10 MB en Apigee), puedes establecer este atributo como verdadero. Si es verdadero, las cargas útiles de respuesta HTTP no se leen en un búfer y se transmiten sin modificaciones al flujo de respuesta `ProxyEndpoint`. En este caso, se omiten las políticas que operan en la carga útil del flujo de respuesta `TargetEndpoint`. Consulta también Solicitudes y respuestas de transmisión.
`success.codes`	N/A	De forma predeterminada, Apigee trata a los códigos HTTP `4XX` o `5XX` como errores y a los códigos HTTP `1XX`, `2XX`, `3XX` como códigos de éxito. Esta propiedad habilita la definición explícita de los códigos de éxito, por ejemplo, `2XX, 1XX, 505` trata cualquier código de respuesta HTTP `100`, `200` y `505` como código de éxito. Si configuras esta propiedad, se reemplazarán los valores predeterminados. Por lo tanto, si deseas agregar el código HTTP `400` a la lista de códigos de éxito predeterminados, configura esta propiedad de la siguiente manera: `<Property name="success.codes">1xx,2xx,3xx,400</Property>` Si solo deseas que el código HTTP `400` se trate como un código de éxito, configura la propiedad de la siguiente manera: `<Property name="success.codes">400</Property>` Cuando se configura el código HTTP `400` como el único código de éxito, los códigos `1xx`, `2xx` y `3xx` se tratan como errores.
`compression.algorithm`	N/A	De forma predeterminada, Apigee respeta el conjunto de tipos de compresión (gzip, deflate o ninguno) para los mensajes recibidos. Si se recibe la solicitud del cliente mediante, por ejemplo, la compresión gzip, Apigee reenvía la solicitud al destino mediante la compresión gzip. Si la respuesta recibida del objetivo usa el formato Deflate, Apigee reenvía la respuesta al cliente mediante la definición. Los valores admitidos son los que se detallan a continuación: gzip: envia siempre el mensaje con la compresión gzip deflate: envía siempre un mensaje con la compresión de deflate ninguno: envía siempre mensajes sin compresión Consulta también: ¿Apigee admite la compresión o descompresión con compresión GZIP/deflate?
`request.retain.headers. enabled`	true	De forma predeterminada, Apigee siempre conserva todos los encabezados HTTP en los mensajes salientes. Cuando se establece en `true`, todos los encabezados HTTP presentes en la solicitud entrante se configuran en la solicitud saliente.
`request.retain.headers`	N/A	Define encabezados HTTP específicos de la solicitud que se deben configurar en la solicitud saliente al servicio de destino. Por ejemplo, para transferir el encabezado `User-Agent`, configura el valor de `request.retain.headers` como `User-Agent`. Se especifican varios encabezados HTTP como una lista separada por comas, por ejemplo, `User-Agent,Referer,Accept-Language`. Esta propiedad anula `request.retain.headers.enabled`. Si se configura `request.retain.headers.enabled` como `false`, cualquier encabezado especificado en la propiedad `request.retain.headers` aún se establece en el mensaje saliente.
`response.retain.headers. enabled`	true	De forma predeterminada, Apigee siempre conserva todos los encabezados HTTP en los mensajes salientes. Cuando se establece como `true`, todos los encabezados HTTP presentes en la respuesta entrante del servicio de destino se configuran en la respuesta saliente antes de pasarlos a `ProxyEndpoint`.
`response.retain.headers`	N/A	Define encabezados HTTP específicos de la respuesta que se deben establecer en la respuesta saliente antes de pasarlos a `ProxyEndpoint`. Por ejemplo, para transferir el encabezado `Expires`, configura el valor de `response.retain.headers` como `Expires`. Varios encabezados HTTP se especifican como una lista separada por comas, por ejemplo, `Expires,Set-Cookie`. Esta propiedad anula `response.retain.headers.enabled`. Si se establece `response.retain.headers.enabled` como `false`, cualquier encabezado especificado en la propiedad `response.retain.headers` aún se establece en el mensaje saliente.
`retain.queryparams. enabled`	true	De forma predeterminada, Apigee siempre conserva todos los parámetros de búsqueda en las solicitudes salientes. Cuando se establece en `true`, todos los parámetros de consulta presentes en la solicitud entrante se establecen en la solicitud saliente al servicio de destino.
`retain.queryparams`	N/A	Define parámetros de consulta específicos para establecer en la solicitud saliente. Por ejemplo, para incluir el parámetro de búsqueda `apikey` del mensaje de solicitud, establece `retain.queryparams` como `apikey`. Varios parámetros de búsqueda se especifican como una lista separada por comas, por ejemplo, `apikey,environment`. Esta propiedad anula `retain.queryparams.enabled`.

Propiedades de transporte de ProxyEndpoint

Los elementos ProxyEndpoint HTTPTargetConnection definen un conjunto de propiedades de transporte HTTP. Estas propiedades se pueden usar para establecer opciones de configuración de nivel de transporte.

Las propiedades se establecen en los elementos HTTPProxyConnection de ProxyEndpoint, como se muestra en esta configuración de ejemplo:

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

Solicita encabezados

Una solicitud HTTP nueva incluye los encabezados HTTP que envía el cliente. Los encabezados con nombres que coinciden con el patrón X-Apigee-* se quitan de las solicitudes entrantes si un cliente los envía. Este patrón de nombre está reservado para Apigee.

Especificación de la propiedad de transporte de ProxyEndpoint

Nombre de la propiedad	Valor predeterminado	Descripción
`X-Forwarded-For`	falso	Cuando se configura como verdadero, la dirección IP del host virtual se agrega a la solicitud saliente como valor del encabezado HTTP `X-Forwarded-For`.
`request.streaming. enabled`	`false`	Según la configuración predeterminada (`false`), las cargas útiles de la solicitud HTTP se leen en un búfer y las políticas que pueden operar en la carga útil funcionan de la manera esperada. En los casos en que las cargas útiles sean más grandes que el tamaño del búfer (10 MB en Apigee), puedes establecer este atributo como `true`. Cuando es `true`, las cargas útiles de la solicitud HTTP no se leen en un búfer y se transmiten sin modificaciones al flujo de solicitudes `TargetEndpoint`. En este caso, se omiten las políticas que operan en la carga útil del flujo de solicitud `ProxyEndpoint`. Consulta también Solicitudes y respuestas de transmisión.
`response.streaming. enabled`	`false`	Según la configuración predeterminada (falso), las cargas útiles de la respuesta HTTP se leen en un búfer y las políticas que pueden operar en la carga útil funcionan de la manera esperada. En los casos en que las cargas útiles sean más grandes que el tamaño del búfer (10 MB en Apigee), puedes establecer este atributo como `true`. Cuando es `true`, las cargas útiles de respuesta HTTP no se leen en un búfer y se transmiten sin modificaciones al cliente. En este caso, se omiten las políticas que operan en la carga útil del flujo de respuesta `ProxyEndpoint`. Consulta también Solicitudes y respuestas de transmisión.
`compression.algorithm`	N/A	De forma predeterminada, Apigee respeta el conjunto de tipos de compresión (gzip, deflate o ninguno) para los mensajes recibidos. Por ejemplo, cuando un cliente envía una solicitud que usa compresión gzip, Apigee reenvía la solicitud al destino con la compresión gzip. Puedes configurar los algoritmos de compresión para que se apliquen de forma explícita mediante la configuración de esta propiedad en `TargetEndpoint` o `ProxyEndpoint`. Los valores admitidos son los que se detallan a continuación: gzip: envia siempre el mensaje con la compresión gzip deflate: envía siempre un mensaje con la compresión de deflate ninguno: envía siempre mensajes sin compresión Consulta también: ¿Apigee admite la compresión o descompresión con compresión GZIP/deflate?
`api.timeout`	N/A	Configura el tiempo de espera para proxies de API individuales (en milisegundos) Puedes configurar proxies de API, incluso aquellos con transmisión habilitada, para agotar el tiempo de espera después de un tiempo especificado con un estado `504 Gateway Timeout`. Importante: El tiempo de espera especificado debe ser menor que el tiempo de espera estándar del procesador de mensajes de 300 segundos. Por ejemplo, para configurar que se agote el tiempo de espera de un proxy después de 180,000 milisegundos (tres minutos), agrega la siguiente propiedad a `HTTPProxyConnection`: <Property name="api.timeout">180000</Property> No puedes establecer esta propiedad con una variable. Consulta Configuración de io.timeout.millis y api.timeout.
`HTTPHeader.allowDuplicates`	N/A	Usa este parámetro de configuración a fin de permitir encabezados duplicados (para encabezados específicos). <HTTPProxyConnection> <Properties> <Property name="HTTPHeader.allowDuplicates">Content-Type,Authorization</Property> </Properties> </HTTPProxyConnection>
`HTTPHeader.multiValued`	N/A	Usa este parámetro de configuración a fin de permitir encabezados duplicados (para encabezados específicos). <HTTPProxyConnection> <Properties> <Property name="HTTPHeader.multiValued">Content-Type,Authorization</Property> </Properties> </HTTPProxyConnection>

Configura io.timeout.millis y api.timeout

La operación de io.timeout.millis y api.timeout está relacionada. En cada solicitud a un proxy de API:

El Ingress (también conocido como balanceador de cargas interno) envía su valor de tiempo de espera al Message Processor. El valor de tiempo de espera predeterminado es 300 segundos y no se puede configurar.
Luego, el procesador de mensajes establece api.timeout:
1. Si api.timeout no se configura a nivel del proxy, usa el tiempo de espera que establece el Ingress.
2. Si api.timeout se configura a nivel del proxy, defínelo en Message Processor en el menor tiempo de espera del Ingress o en el valor de api.timeout.
El valor de api.timeout especifica la cantidad máxima de tiempo en el que un proxy de API se debe ejecutar desde la solicitud a la API hasta la respuesta.

Después de que se ejecute cada política en el proxy de API o antes de que el Message Processor envíe la solicitud al extremo de destino, este calcula api.timeout, el tiempo transcurrido desde el inicio de la solicitud.

Si el valor es menor que cero, el tiempo máximo para manejar la solicitud venció y el procesador de mensajes muestra un 504 Gateway Timeout.
El valor de io.timeout.millis especifica la cantidad máxima de tiempo que el extremo de destino debe responder.

Antes de conectarse a un extremo de destino, Message Processor determina la menor cantidad de api.timeout, tiempo transcurrido desde el inicio de la solicitud, y io.timeout.millis. Luego, establece io.timeout.millis en ese valor.

Si se agota el tiempo de espera mientras se escribe la solicitud HTTP o se lee la respuesta HTTP, se muestra 504 Gateway Timeout.