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 |
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.
|
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
Si se define como |
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. |
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 ( |
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 |
success.codes |
N/A |
De forma predeterminada, Apigee trata los códigos HTTP Si define esta propiedad, se sobrescribirán los valores predeterminados. Por lo tanto, si quieres añadir el código HTTP
Si solo quieres que el código HTTP
Si se define el código HTTP |
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:
Consulta también ¿Apigee admite la compresión o descompresión con compresión GZIP o deflate? |
request.retain.headers. |
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. |
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. |
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. |
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. |
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. |
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
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
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 <Property name="api.timeout">180000</Property> No puedes definir esta propiedad con una variable. |
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
:- Si
api.timeout
no se define a nivel de proxy, usa el tiempo de espera definido por Ingress. - 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 deapi.timeout
.
- Si
-
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) yio.timeout.millis
. A continuación, asigna ese valor aio.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
.