Se usó la API de Cloud Translation para traducir esta página.

Referencia de propiedades de extremos

Estás viendo la documentación de Apigee Edge.
Ve a 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 de TargetEndpoint

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

Las propiedades se establecen en los elementos HTTPTargetConnection de TargetEndpoint, 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>

Propiedad de transporte de TargetEndpoint Especificación

Nombre de la 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 una conexión se agota el tiempo de espera. En algunos casos, es posible que se muestre un código de estado HTTP 504 cuando `LoadBalancer` se usa 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, es posible que el tiempo total de reintento supere lo configurado para `connect.timeout.millis`.
`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, `408, Request Timeout` el resultado. Si se agota el tiempo de espera mientras se lee la respuesta HTTP, `504, Gateway Timeout` el resultado. 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 más. Consulta Cómo configurar 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. para cada solicitud. De lo contrario, se envía la solicitud 1.1 al destino.
`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 solicitudes, de lo contrario, se envía una solicitud 1.0 al destino.
`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`	N/A	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 puede operar en la carga útil como se espera. En los casos en que las cargas útiles sean mayores que el tamaño del búfer (10 MB), puedes configurar a `true`. Cuando es `true`, las cargas útiles de solicitudes HTTP no se leen en un búfer. que se transmitirse tal como está al extremo de destino. En este caso, cualquier política que opere en el en el flujo de solicitud 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 puede operar en la carga útil como se espera. En los casos en que las cargas útiles sean mayores que el tamaño del búfer (10 MB), puedes configurar a `true`. Cuando es `true`, las cargas útiles de respuesta HTTP no se leen en un búfer. que se transmitirse como está al flujo de respuesta de ProxyEndpoint. En este caso, cualquier política que que operan en la carga útil en el flujo de respuesta de TargetEndpoint. Consulta también Las solicitudes de transmisión y de respuestas ante incidentes.
`success.codes`	N/A	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 éxito. Esta propiedad permite 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 el é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: <Propertyname="success.codes">400</Property> Si estableces el código HTTP `400` como el único código de éxito, se aplicarán los siguientes códigos `1XX`, `2XX` y `3XX` tratarse como errores.
`compression.algorithm`	N/A	De forma predeterminada, Apigee Edge reenvía las solicitudes al destino con el mismo tipo de compresión como la solicitud del cliente. Si la solicitud se recibe del cliente usando, por ejemplo, gzip y, luego, Apigee Edge reenviará la solicitud al destino mediante la compresión gzip. Si cuando se recibe una respuesta del objetivo, se reduce cliente con la 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 compresión y descompresión con GZIP o descompresión?
`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`	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 Edge siempre retiene todos los encabezados HTTP en los mensajes salientes. Cuando se establezca a `true`, todos los encabezados HTTP presentes en la respuesta entrante del destino de servicio se configuran en la respuesta saliente antes de pasarla al ProxyEndpoint.
`response.retain.headers`	N/A	Define encabezados HTTP específicos de la respuesta que deben configurarse en la salida antes de pasarlos al ProxyEndpoint. Por ejemplo, para pasar los Encabezado `Expires`, establece el valor de `response.retain.headers` en `Expires` Múltiples encabezados HTTP se especifican en una lista separada por comas, por por ejemplo, `Expires,Set-Cookie`. Esta propiedad anula `response.retain.headers.enabled`. Si `response.retain.headers.enabled` se establece en `false`, cualquier encabezado. especificadas en la propiedad `response.retain.headers` siguen estando configuradas en mensaje saliente.
`retain.queryparams. enabled`	`true`	De forma predeterminada, Apigee Edge siempre retiene todos los parámetros de consulta 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 HTTPTargetConnection de ProxyEndpoint definen un conjunto de propiedades de transporte de 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.

Propiedad de transporte de ProxyEndpoint Especificación

Nombre de la 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 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 operar en la carga útil como se espera. En los casos en que las cargas útiles sean más grandes que el tamaño del búfer (10 MB), puedes configurar este a `true`. Cuando es `true`, las cargas útiles de solicitudes HTTP no se leen en un búfer. que se transmitirse tal como está al flujo de solicitud de TargetEndpoint. En este caso, 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 puede operar en la carga útil como se espera. En los casos en que las cargas útiles sean mayores que el tamaño del búfer (10 MB), puedes configurar a `true`. Cuando es `true`, las cargas útiles de respuesta HTTP no se leen en un búfer. que se transmitirse tal como están al cliente. En este caso, cualquier política que opere en la carga útil en el Se omite el flujo de respuesta de ProxyEndpoint. Consulta también Solicitudes y respuestas de transmisión.
`compression.algorithm`	N/A	De forma predeterminada, Apigee Edge respeta el tipo de compresión configurado para cualquier mensaje recibido. Para 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 la compresión algoritmos que se aplicarán explícitamente configurando esta propiedad en el 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 compresión y descompresión con GZIP o descompresión?
`api.timeout`	N/A	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 de uso principal es para clientes que tienen proxies de API que tardan más en ejecutarse. Por ejemplo, supongamos que necesitas proxies específicos para que el tiempo de espera se agote en 3. minutos. A continuación, te mostramos cómo usar `api.timeout`. 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. 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>` Sin embargo, ten en cuenta que un aumento de los tiempos de espera del sistema ya que todos los proxies sin una configuración api.timeout usan la nueva carga más alta. del balanceador de cargas, el router y el procesador de mensajes. 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 establece un El tiempo de espera del proxy de API se agotará 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 proxy de API. tiempo de espera, siempre y cuando el tiempo de espera sea menor que el del procesador de mensajes de Edge estándar el tiempo de espera de 57 segundos. Consulta Cómo configurar 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, la operación de io.timeout.millis y api.timeout están relacionados. En cada solicitud a un proxy de API:

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 que establece el host virtual que procesa la solicitud, o el valor de tiempo de espera predeterminado de 57 segundos.
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 se configura api.timeout a nivel del proxy, configúralo en Message Processor en la opción que corresponda: menor que el tiempo de espera del router o el valor de api.timeout.
El valor de api.timeout especifica la cantidad máxima de tiempo que tiene un proxy de API. ejecutar desde la solicitud a la API hasta la respuesta.

Después de que se ejecuta cada política en el proxy de API, o antes de que Message Processor envíe la solicitud al extremo de destino, que calcula Message Processor (api.timeout, es decir, el tiempo transcurrido desde el inicio de la solicitud). Si el valor es menor que cero, entonces la cantidad máxima de tiempo para controlar la solicitud venció y Message Processor muestra 504.
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, el procesador de mensajes determina (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, 408, Request Timeout el resultado.
- Si se agota el tiempo de espera mientras se lee la respuesta HTTP, 504, Gateway Timeout el resultado.

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 para obtener más información sobre el uso de Node.js y ScriptTarget, consulta lo siguiente:

Acerca de los extremos de HostedTarget

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