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.

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.

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:

  1. 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.
  2. 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.
  3. 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.

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