Referencia de propiedades de extremos

Estás consultando la documentación de Apigee Edge.
Consulta la documentación de Apigee X.
Información

En este tema, se describen las propiedades de transporte que se pueden establecer en las opcieones de configuración de TargetEndpoint y ProxyEndpoint para controlar la mensajería y el comportamiento de la conexión. Para ver la cobertura completa de la configuración de TargetEndpoint y ProxyEndpoint, consulta la referencia de configuración del proxy de API.

Propiedades de transporte TargetEndpoint

El elemento HTTPTargetConnection en la configuración de 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 los elementos TargetEndpoint HTTPTargetConnection como se muestra a continuación:

<TargetEndpoint name="default">
  <HTTPTargetConnection>
    <URL>http://mocktarget.apigee.net</URL>
    <Properties>
      <Property name="supports.http10">true</Property>
      <Property name="request.retain.headers">User-Agent,Referer,Accept-Language</Property>
      <Property name="retain.queryparams">apikey</Property>
    </Properties>
    <CommonName>COMMON_NAME_HERE</CommonName>
  </HTTPTargetConnection>
</TargetEndpoint>

Especificación de la propiedad de transporte TargetEndpoint

Nombre de propiedad Valor predeterminado Descripción
keepalive.timeout.millis 60000 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 Edge muestra un código de estado HTTP 503 si se agota el tiempo de espera de la conexión.

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, la transacción se considera un tiempo de espera.

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

Este valor siempre debe ser menor que el de la propiedad proxy_read_timeout del host virtual.

Este valor debe ser menor que el tiempo de espera que usa el router para comunicarse con Message Processor. Consulta Cómo configurar el tiempo de espera del router para obtener más información.

Consulta Configura io.timeout.millis y api.timeout para Edge para obtener más información.

supports.http10 true Si es true y el cliente envía una solicitud 1.0, el destino también recibe una solicitud 1.0. De lo contrario, la solicitud 1.1 se envía al destino.
supports.http11 true Si es true y el cliente envía una solicitud 1.1, el objetivo también recibe una solicitud 1.1; de lo contrario, la solicitud 1.0 se envía al objetivo.
use.proxy true Si se establece como true y las opciones de configuración del proxy se especifican en http.properties (solo implementaciones locales), las conexiones de destino se establecen para usar el proxy especificado.
use.proxy.tunneling true Si se establece como true y las opciones de configuración de proxy se especifican en http.properties (solo implementaciones locales), las conexiones de destino se establecen para usar el túnel especificado. Si el destino usa TLS/SSL, esta propiedad se ignora y el mensaje siempre se envía a través de un túnel.
enable.method.override false Para el método HTTP especificado, configura un encabezado X-HTTP-Method-Override en la solicitud saliente al servicio de destino. Por ejemplo, <Property name="GET.override.method">POST</Property>
*.override.method No disponible Para el método HTTP especificado, configura un encabezado X-HTTP-Method-Override en la solicitud saliente. Por ejemplo, <Property name="GET.override.method">POST</Property>
request.streaming.enabled false

De forma predeterminada (false), las cargas útiles de solicitudes HTTP se leen en un búfer, y las políticas que pueden operar en ella funcionan como se espera. En los casos en los que las cargas útiles son mayores que el tamaño del búfer (10 MB), puedes configurar este atributo como true. Cuando es true, las cargas útiles de solicitudes HTTP no se leen en un búfer, sino que se transmiten como están en el extremo de destino. En este caso, se omite cualquier política que opere en la carga útil en el flujo de solicitudes de TargetEndpoint. Consulta también Solicitudes y respuestas de transmisión.

response.streaming.enabled false

De forma predeterminada (false), las cargas útiles de respuesta 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 son mayores que el tamaño del búfer (10 MB), puedes configurar este atributo como true. Cuando es true, las cargas útiles de respuesta HTTP no se leen en un búfer, sino que se transmiten como están al flujo de respuesta de ProxyEndpoint. En este caso, se omite cualquier política que opere en la carga útil en el flujo de respuesta de TargetEndpoint. Consulta también Solicitudes y respuestas de transmisión.

success.codes No disponible

De forma predeterminada, Apigee Edge trata el código HTTP 4XX o 5XX como errores y el código HTTP 1XX, 2XX y 3XX como correcto. Esta propiedad habilita la definición explícita de códigos de éxito, por ejemplo, 2XX, 1XX, 505 trata cualquier código de respuesta HTTP 100, 200 y 505 como correcto.

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:

<Propertyname="success.codes">400</Property>

Cuando configuras 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 No disponible De forma predeterminada, Apigee Edge reenvía solicitudes al destino con el mismo tipo de compresión que la solicitud del cliente. Si el cliente recibe la solicitud mediante, por ejemplo, la compresión gzip, Apigee Edge reenviará la solicitud de destino mediante la compresión gzip. Si la respuesta recibida del destino usa deflación, Apigee Edge reenviará la respuesta al cliente mediante deflació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 y la descompresión con la compresión GZIP/deflate?

request.retain.headers.
enabled
true De forma predeterminada, Apigee Edge siempre retiene 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 No disponible 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 Edge siempre retiene todos los encabezados HTTP en los mensajes salientes. Cuando se establece en true, todos los encabezados HTTP presentes en la respuesta entrante del servicio de destino se configuran en la respuesta saliente antes de pasar al ProxyEndpoint.
response.retain.headers No disponible Define encabezados HTTP específicos de la respuesta que se debe configurar en la respuesta saliente antes de pasar al ProxyEndpoint. Por ejemplo, para pasar el encabezado Expires, establece el valor de response.retain.headers en Expires. Varios encabezados HTTP se especifican en una lista separada por comas, por ejemplo, Expires,Set-Cookie. Esta propiedad anula response.retain.headers.enabled. Si response.retain.headers.enabled se configura como false, cualquier encabezado especificado en la propiedad response.retain.headers se establecerá en el mensaje saliente de todos modos.
retain.queryparams.
enabled
true De forma predeterminada, Apigee Edge siempre retiene todos los parámetros de consulta de 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 No disponible 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 HTTPTargetConnection de ProxyEndpoint 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 elementos de HTTPProxyConnection de ProxyEndpoint de la siguiente manera:

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

Para obtener más información sobre los hosts virtuales, consulta Acerca de los hosts virtuales.

Especificación de la propiedad de transporte ProxyEndpoint

Nombre de propiedad Valor predeterminado Descripción
X-Forwarded-For false Cuando se establece en true, la dirección IP del host virtual se agrega a la solicitud saliente como el valor del encabezado HTTP X-Forwarded-For.
request.streaming.
enabled
false De forma predeterminada (false), las cargas útiles de 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 son mayores que el tamaño del búfer (10 MB), puedes configurar este atributo como true. Cuando es true, las cargas útiles de solicitud HTTP no se leen en un búfer, sino que se transmiten como están al flujo de solicitudes de TargetEndpoint. En este caso, se omite cualquier política que opere en la carga útil en el flujo de solicitud de ProxyEndpoint. Consulta también Solicitudes y respuestas de transmisión.
response.streaming.
enabled
false De forma predeterminada (false), las cargas útiles de respuesta 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 son mayores que el tamaño del búfer (10 MB), puedes configurar este atributo como true. Cuando es true, las cargas útiles de respuesta HTTP no se leen en un búfer, sino que se transmiten como están al cliente. En este caso, se omite cualquier política que opere en la carga útil en el flujo de respuesta de ProxyEndpoint. Consulta también Solicitudes y respuestas de transmisión.
compression.algorithm No disponible

De forma predeterminada, Apigee Edge respeta el tipo de compresión configurado para cualquier mensaje recibido. Por ejemplo, cuando un cliente envía una solicitud que usa compresión gzip, Apigee Edge reenvía la solicitud de destino mediante compresión gzip. Puedes configurar los algoritmos de compresión para que se apliquen de forma explícita si estableces 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 y la descompresión con la compresión GZIP/deflate?

api.timeout No disponible

Configura el tiempo de espera para proxies de API individuales

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. El caso práctico principal es para clientes que tienen proxies de API que tardan más en ejecutarse. Por ejemplo, supongamos que necesitas que proxies específicos se agote el tiempo de espera a los 3 minutos. A continuación, te mostramos cómo usar api.timeout.

  1. Primero, asegúrate de configurar el balanceador de cargas, el router y el procesador de mensajes para que se agote el tiempo de espera después de tres minutos.
  2. Luego, configura los proxies relevantes para que se agote el tiempo de espera en tres minutos. Especifica el valor en milisegundos. Por ejemplo: <Property name="api.timeout">180000</Property>
  3. Sin embargo, ten en cuenta que aumentar los tiempos de espera del sistema podría ocasionar problemas de rendimiento, ya que todos los proxies sin una configuración de api.timeout usan los tiempos de espera nuevos del balanceador de cargas, del router y del procesador de mensajes más altos. Por lo tanto, configura otros proxies de API que no requieran tiempos de espera más largos para usar tiempos de espera más bajos. Por ejemplo, lo siguiente configura un proxy de API para que se agote el tiempo de espera después de 1 minuto:
    <Property name="api.timeout">60000</Property>

No puedes establecer esta propiedad con una variable.

Los clientes, que no pueden modificar los tiempos de espera de Edge, también pueden configurar un tiempo de espera de proxy de API, siempre que el tiempo de espera sea menor que el tiempo de espera estándar del procesador de mensajes Edge de 57 segundos.

Consulta Configura io.timeout.millis y api.timeout para Edge para obtener más información.

Configura io.timeout.millis y api.timeout para Edge

En Edge, las operaciones de io.timeout.millis y api.timeout están relacionadas. En cada solicitud a un proxy de API:

  1. El router envía su valor de tiempo de espera al procesador de mensajes. El valor de tiempo de espera del router es el valor de proxy_read_timeout establecido por el host virtual que controla la solicitud o el valor de tiempo de espera predeterminado de 57 segundos.
  2. Luego, el procesador de mensajes establece api.timeout:
    1. Si api.timeout no está establecido a nivel del proxy, configúralo en el tiempo de espera del router.
    2. Si api.timeout se establece en el nivel del proxy, configúralo en Message Processor en el valor menor del tiempo de espera del router o en el valor de api.timeout.
  3. El valor de api.timeout especifica la cantidad máxima de tiempo que un proxy de API tiene para ejecutarse desde la solicitud a la API hasta la respuesta.

    Después de que se ejecuta cada política en el proxy de la API, o antes de que Message Processor envíe la solicitud al extremo de destino, el Message Processor realiza la cálculo (api.timeout es el tiempo transcurrido desde el inicio de la solicitud). Si el valor es menor que cero, venció el tiempo máximo para procesar la solicitud y Message Processor muestra 504.

  4. 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 el menor de (api.timeout, el 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, se muestra 408, Request Timeout.
    • Si se agota el tiempo de espera mientras se lee la respuesta HTTP, se muestra 504, Gateway Timeout.

Acerca de ScriptTarget para aplicaciones de Node.js

El elemento ScriptTarget se usa para integrar una aplicación de Node.js en tu proxy. Para obtener información sobre el uso de Node.js y ScriptTarget, consulta los siguientes vínculos:

Acerca de los extremos de HostedTarget

Una etiqueta <HostedTarget/> vacía le indica a Edge que use como destino una aplicación de Node.js que se implemente en el entorno de Destinos alojados. Para obtener más información, consulta la Descripción general de los destinos alojados.