Esta página se ha traducido con Cloud Translation API.

Referencia de propiedades de puntos de conexión

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 definir en las configuraciones de TargetEndpoint y ProxyEndpoint para controlar el comportamiento de la mensajería y la conexión. Para obtener información completa sobre las opciones de configuración de TargetEndpoint y ProxyEndpoint, consulta la referencia de configuración de proxies de API.

Propiedades de transporte de TargetEndpoint

El elemento HTTPTargetConnection de las configuraciones de TargetEndpoint define un conjunto de propiedades de transporte HTTP. Puede usar estas propiedades para definir configuraciones a nivel de transporte.

Las propiedades se definen en los elementos TargetEndpoint HTTPTargetConnection, como se muestra en este ejemplo de configuración:

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

Nombre de 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 `true` (valor predeterminado), los clientes reutilizan las sesiones TLS al establecer nuevas conexiones con el destino. Seleccione `false` si no quiere reutilizar la sesión TLS. La reutilización de sesiones suele significar tiempos de conexión más cortos, pero es posible que algunos destinos no admitan la reutilización de sesiones o tengan dificultades para hacerlo.
`keepalive.timeout.millis`	60000	Tiempo de espera de inactividad de la conexión de destino en el grupo de conexiones. Si la conexión del grupo está inactiva durante más tiempo del límite especificado, se cierra.
`connect.timeout.millis`	3000	Tiempo de espera de conexión de destino agotado. Apigee devuelve un código de estado HTTP `503` si se agota el tiempo de espera de una conexión. En algunos casos, se puede devolver un código de estado HTTP `504` cuando se usa `LoadBalancer` en la definición de TargetServer y se produce un tiempo de espera. Nota: En algunos casos, Apigee volverá a intentar la conexión automáticamente hasta tres veces. Por lo tanto, el tiempo total de reintento puede superar el valor configurado para `connect.timeout.millis`.
`ignore.allow.header.for.405`	true	Permite devolver el código de estado 405 al cliente. Si habilita la marca, Apigee devolverá el código de estado 405 en lugar del 502.
`io.timeout.millis`	55000	Si no hay datos que leer durante el número de milisegundos especificado o si el socket no está listo para escribir datos durante el número de milisegundos especificado, la transacción se tratará como un tiempo de espera agotado. Si se agota el tiempo de espera al leer la solicitud HTTP de entrada, se devuelve `408 Request Timeout`. `408 Request Timeout` no se devolverá si se agota el tiempo de espera mientras se escribe una solicitud en el destino. Si se agota el tiempo de espera al escribir la solicitud HTTP o al leer la respuesta HTTP, se devuelve `504 Gateway Timeout`. Consulta Configurar io.timeout.millis y api.timeout.
`supports.http11`	true	Si es `true` y el cliente envía una solicitud `1.1`, también se envía una solicitud `1.1` al destino. De lo contrario, se envía una solicitud `1.0` al destino.
`use.proxy`	true	Si el archivo de anulaciones de Apigee hybrid contiene la configuración `HTTP_PROXY`, como se describe en Configurar el reenvío de proxy para proxies de API, utilice esta propiedad para gestionar o controlar qué proxies no deben usar la configuración de proxy. Si se define como `false`, el proxy de API omitirá las configuraciones de proxy HTTP especificadas en el archivo de anulaciones de Apigee Hybrid para las conexiones de destino definidas en el proxy.
`use.proxy.tunneling`	true	Si se define como true y se especifican configuraciones de proxy en el archivo de anulación de Apigee Hybrid, tal como se describe en Configurar el reenvío de proxy para proxies de API, las conexiones de destino se configurarán para usar el túnel especificado. Si el destino usa TLS/SSL, esta propiedad se ignora y el mensaje siempre se envía mediante un túnel.
`response.payload. parse.limit`	`10M`	Valor predeterminado (`10M`). Usa la propiedad `response.payload.parse.limit` para definir el tamaño máximo de la carga útil que se puede procesar en el flujo de respuesta, en megabytes (M). El límite mínimo configurable es de 10 M y el máximo es de 30 M. Si no se define la propiedad, el límite predeterminado es de 10 M. Consulta también Tamaño de la carga útil de los mensajes.
`request.streaming.enabled`	falso	De forma predeterminada (`false`), las cargas útiles de las solicitudes HTTP se leen en un búfer y las políticas que pueden operar en la carga útil funcionan como se espera. En los casos en los que las cargas útiles sean mayores que el tamaño del búfer (10 MB en Apigee), puede definir este atributo como `true`. Cuando se usa `true`, las cargas útiles de las solicitudes HTTP no se leen en un búfer, sino que se transmiten tal cual al endpoint de destino. En este caso, se omiten todas las políticas que operan en la carga útil del flujo de solicitudes `TargetEndpoint`. Consulta también Solicitudes y respuestas de streaming.
`response.streaming.enabled`	falso	De forma predeterminada (false), las cargas útiles de las respuestas HTTP se leen en un búfer y las políticas que pueden operar en la carga útil funcionan como se espera. En los casos en los que las cargas útiles sean mayores que el tamaño del búfer (10 MB en Apigee), puede definir este atributo como true. Si es true, las cargas útiles de las respuestas HTTP no se leen en un búfer, sino que se transmiten tal cual 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 streaming.
`success.codes`	N/A	De forma predeterminada, Apigee trata los códigos HTTP `4XX` o `5XX` como errores y los códigos HTTP `1XX`, `2XX` y `3XX` como correctos. Esta propiedad permite definir explícitamente los códigos de éxito. Por ejemplo, `2XX, 1XX, 505` trata los códigos de respuesta HTTP `100`, `200` y `505` como correctos. Si define esta propiedad, se sobrescribirán los valores predeterminados. Por lo tanto, si quieres añadir el código HTTP `400` a la lista de códigos de éxito predeterminados, define esta propiedad de la siguiente manera: `<Property name="success.codes">1xx,2xx,3xx,400</Property>` Si solo quieres que el código HTTP `400` se trate como un código correcto, define la propiedad de la siguiente manera: `<Property name="success.codes">400</Property>` Si se define el código HTTP `400` como el único código correcto, los códigos `1xx`, `2xx` y `3xx` se tratarán como errores.
`compression.algorithm`	N/A	De forma predeterminada, Apigee respeta el tipo de compresión definido (gzip, deflate o ninguno) para los mensajes recibidos. Si el cliente envía la solicitud mediante, por ejemplo, la compresión gzip, Apigee la reenvía al destino con la compresión gzip. Si la respuesta recibida del destino usa deflate, Apigee reenvía la respuesta al cliente mediante deflate. Los valores posibles son: gzip: envía siempre el mensaje con compresión gzip. deflate: siempre envía el mensaje con la compresión deflate Ninguna: siempre envía el mensaje sin comprimirlo. Consulta también ¿Apigee admite la compresión o descompresión con compresión GZIP o deflate?
`request.retain.headers. enabled`	true	De forma predeterminada, Apigee siempre conserva todos los encabezados HTTP en los mensajes salientes. Si se le asigna el valor `true`, todos los encabezados HTTP presentes en la solicitud entrante se definen en la solicitud saliente.
`request.retain.headers`	N/A	Define encabezados HTTP específicos de la solicitud que se deben definir en la solicitud saliente al servicio de destino. Por ejemplo, para transferir el encabezado `User-Agent`, asigne el valor `User-Agent` a `request.retain.headers`. 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 `request.retain.headers.enabled` tiene el valor `false`, los encabezados especificados en la propiedad `request.retain.headers` se siguen definiendo en el mensaje saliente.
`response.retain.headers. enabled`	true	De forma predeterminada, Apigee siempre conserva todos los encabezados HTTP en los mensajes salientes. Si se establece el valor `true`, todos los encabezados HTTP presentes en la respuesta entrante del servicio de destino se definen en la respuesta saliente antes de que se transfiera al `ProxyEndpoint`.
`response.retain.headers`	N/A	Define encabezados HTTP específicos de la respuesta que se deben definir en la respuesta saliente antes de que se transfiera a `ProxyEndpoint`. Por ejemplo, para transferir el encabezado `Expires`, asigne el valor `Expires` a `response.retain.headers`. Se especifican varios encabezados HTTP como una lista separada por comas. Por ejemplo, `Expires,Set-Cookie`. Esta propiedad anula `response.retain.headers.enabled`. Si `response.retain.headers.enabled` se define como `false`, las cabeceras especificadas en la propiedad `response.retain.headers` se siguen definiendo en el mensaje saliente.
`retain.queryparams. enabled`	true	De forma predeterminada, Apigee siempre conserva todos los parámetros de consulta en las solicitudes salientes. Si se le asigna el valor `true`, todos los parámetros de consulta presentes en la solicitud entrante se definen en la solicitud saliente al servicio de destino.
`retain.queryparams`	N/A	Define parámetros de consulta específicos que se deben definir en la solicitud saliente. Por ejemplo, para incluir el parámetro de consulta `apikey` del mensaje de solicitud, asigne el valor `apikey` a `retain.queryparams`. Se pueden especificar varios parámetros de consulta en una lista separada por comas, como `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 definir configuraciones a nivel de transporte.

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

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

Encabezados de solicitud

Una solicitud HTTP entrante incluye las cabeceras HTTP enviadas por el cliente. Los encabezados con nombres que coincidan con el patrón X-Apigee-* se eliminan 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 ProxyEndpoint

Nombre de propiedad	Valor predeterminado	Descripción
`X-Forwarded-For`	falso	Si se le asigna el valor "true", la dirección IP del host virtual se añade a la solicitud saliente como valor del encabezado HTTP `X-Forwarded-For`.
`request.streaming. enabled`	`false`	De forma predeterminada (`false`), las cargas útiles de las solicitudes HTTP se leen en un búfer y las políticas que pueden operar en la carga útil funcionan como se espera. En los casos en los que las cargas útiles sean mayores que el tamaño del búfer (10 MB en Apigee), puede definir este atributo como `true`. Cuando se usa `true`, las cargas útiles de las solicitudes HTTP no se leen en un búfer, sino que se transmiten tal cual al flujo de solicitudes de `TargetEndpoint`. En este caso, se omiten todas las políticas que operan en la carga útil del flujo de solicitudes `ProxyEndpoint`. Consulta también Solicitudes y respuestas de streaming.
`request.payload. parse.limit`	`10M`	Valor predeterminado (`10M`). Usa la propiedad `request.payload.parse.limit` para definir el tamaño máximo de la carga útil que se puede procesar en el flujo de solicitudes, en megabytes (M). El límite mínimo configurable es de 10 M y el máximo es de 30 M. Si no se define la propiedad, el límite predeterminado es de 10 M. Consulta también Tamaño de la carga útil de los mensajes.
`response.streaming. enabled`	`false`	De forma predeterminada (false), las cargas útiles de las respuestas HTTP se leen en un búfer y las políticas que pueden operar en la carga útil funcionan como se espera. En los casos en los que las cargas útiles sean mayores que el tamaño del búfer (10 MB en Apigee), puede definir este atributo como `true`. Cuando `true`, las cargas útiles de las respuestas HTTP no se leen en un búfer, sino que se envían tal cual 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 streaming.
`compression.algorithm`	N/A	De forma predeterminada, Apigee respeta el tipo de compresión definido (gzip, deflate o ninguno) para los mensajes recibidos. Por ejemplo, si un cliente envía una solicitud que usa la compresión gzip, Apigee reenvía la solicitud al destino usando la compresión gzip. Puede configurar algoritmos de compresión para que se apliquen explícitamente definiendo esta propiedad en `TargetEndpoint` o `ProxyEndpoint`. Los valores admitidos son: gzip: envía siempre el mensaje con compresión gzip. deflate: siempre envía el mensaje con la compresión deflate Ninguna: siempre envía el mensaje sin comprimirlo. Consulta también ¿Apigee admite la compresión o descompresión con compresión GZIP o deflate?
`api.timeout`	N/A	Configurar el tiempo de espera de proxies de API concretos (en milisegundos) Puedes configurar proxies de API, incluso aquellos que tengan el streaming habilitado, para que se agoten tras un tiempo especificado con el estado `504 Gateway Timeout`. Importante: El tiempo de espera especificado debe ser inferior al tiempo de espera estándar del procesador de mensajes, que es de 300 segundos. Por ejemplo, para configurar un proxy de forma que se agote el tiempo de espera después de 180.000 milisegundos (tres minutos), añade la siguiente propiedad a `HTTPProxyConnection`: <Property name="api.timeout">180000</Property> No puedes definir esta propiedad con una variable. Consulta Configurar io.timeout.millis y api.timeout.
`HTTPHeader.allowDuplicates`	N/A	Usa este ajuste para 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 ajuste para permitir encabezados duplicados (para encabezados específicos). <HTTPProxyConnection> <Properties> <Property name="HTTPHeader.multiValued">Content-Type,Authorization</Property> </Properties> </HTTPProxyConnection>

Configurar io.timeout.millis y api.timeout

El funcionamiento de io.timeout.millis y api.timeout están relacionados. En cada solicitud a un proxy de API:

Ingress (también conocido como balanceador de carga interno) envía su valor de tiempo de espera a Message Processor. El valor predeterminado de este tiempo de espera es de 300 segundos y no se puede configurar.
A continuación, el procesador de mensajes define api.timeout:
1. Si api.timeout no se define a nivel de proxy, usa el tiempo de espera definido por Ingress.
2. Si api.timeout se define a nivel de proxy, defínelo en el procesador de mensajes con el valor más bajo entre el tiempo de espera de entrada y el valor de api.timeout.
El valor de api.timeout especifica el tiempo máximo que tiene un proxy de API para ejecutarse 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 procesador de mensajes envíe la solicitud al punto de conexión de destino, el procesador de mensajes calcula (api.timeout - tiempo transcurrido desde el inicio de la solicitud).

Si el valor es inferior a cero, significa que ha transcurrido el tiempo máximo para gestionar la solicitud y el procesador de mensajes devuelve un 504 Gateway Timeout.
El valor de io.timeout.millis especifica el tiempo máximo que tiene el punto de conexión de destino para responder.

Antes de conectarse a un endpoint de destino, el procesador de mensajes determina el menor de los siguientes valores: (api.timeout - tiempo transcurrido desde el inicio de la solicitud) y io.timeout.millis. A continuación, asigna ese valor a io.timeout.millis.

Si se agota el tiempo de espera al escribir la solicitud HTTP o al leer la respuesta HTTP, se devuelve 504 Gateway Timeout.