Google utiliza tecnología de IA para traducir contenido a tu idioma preferido. Las traducciones realizadas con IA pueden contener errores.

Referencia de propiedades de extremos

Estás viendo la documentación de Apigee Edge.
Ir a la documentación de Apigee X. info

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

Especificación de la propiedad de transporte de TargetEndpoint

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 se agota el tiempo de espera de la conexión. En algunos casos, se puede mostrar un código de estado HTTP 504 cuando se usa `LoadBalancer` 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, el tiempo total de reintento puede exceder lo que se configuró 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` se muestra. Si se agota el tiempo de espera mientras se lee la respuesta HTTP, `504, Gateway Timeout` se muestra. 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 el Message Processor. Consulta Configura el tiempo de espera del router para 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 request. De lo contrario, recibe la solicitud 1.1.
`supports.http11`	`true`	Si es `true` y el cliente envía una solicitud 1.1, el destino también recibe una solicitud 1.1 solicitud; de lo contrario, recibe la solicitud 1.0.
`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`	Según la configuración predeterminada (`false`), las cargas útiles de la solicitud HTTP se leen en un búfer y las políticas que pueden operar en la carga útil funcionan de la manera esperada. En los casos en que las cargas útiles sean más grandes que el tamaño del búfer (10 MB), puedes establecer este atributo como `true`. Cuando es `true`, las cargas útiles de la solicitud HTTP no se leen en un búfer, sino que se transmiten sin modificaciones al extremo de destino. En este caso, se omiten las políticas que funcionan en la carga útil del flujo de solicitud de TargetEndpoint. Consulta también Solicitudes y respuestas de transmisión.
`response.streaming.enabled`	`false`	Según la configuración predeterminada (`false`), las cargas útiles de la respuesta HTTP se leen en un búfer y las políticas que pueden operar en la carga útil funcionan de la manera esperada. En los casos en que las cargas útiles sean más grandes que el tamaño del búfer (10 MB), puedes establecer este atributo como `true`. Cuando es `true`, las cargas útiles de respuesta HTTP no se leen en un búfer, sino que se transmiten sin modificaciones al flujo de respuesta de ProxyEndpoint. En este caso, se omiten las políticas que operan en la carga útil del flujo de respuesta de TargetEndpoint. Consulta también Solicitudes y respuestas de transmisión.
`success.codes`	N/A	De forma predeterminada, Apigee Edge trata a los códigos HTTP `4XX` o `5XX` como errores y a los códigos HTTP `1XX`, `2XX`, `3XX` como códigos de éxito. Esta propiedad habilita la definición explícita de los códigos de éxito, por ejemplo, `2XX, 1XX, 505` trata cualquier `100`, `200` y `505` código de respuesta HTTP como código de é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: <Property name="success.codes">400</Property> Si estableces el código HTTP `400` como el único código de éxito, los códigos `1XX`, `2XX` y `3XX` se tratan como fallas.
`compression.algorithm`	N/A	De forma predeterminada, Apigee Edge reenvía las solicitudes al destino con el mismo tipo de compresión que la solicitud del cliente. Si se recibe la solicitud del cliente mediante, por ejemplo, la compresión gzip, Apigee Edge reenvía la solicitud para orientar mediante la compresión gzip. Si la respuesta recibida del objetivo usa el formato Deflate, Apigee Edge reenvía la respuesta a el cliente mediante la definició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 o descompresión con compresión GZIP/deflate?
`request.retain.headers. enabled`	`true`	De forma predeterminada, Apigee Edge siempre conserva 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 `request.retain.headers.enabled` se configura como `false`, cualquier encabezado especificado en la `request.retain.headers` propiedad aún se establece en el mensaje saliente.
`response.retain.headers. enabled`	`true`	De forma predeterminada, Apigee Edge siempre conserva todos los encabezados HTTP en los mensajes salientes. Cuando se establece como `true`, todos los encabezados HTTP presentes en la respuesta entrante del servicio de destino se configuran en la respuesta saliente antes de pasarlos a ProxyEndpoint.
`response.retain.headers`	N/A	Define encabezados HTTP específicos de la respuesta que se deben establecer en la respuesta saliente antes de pasarlos a ProxyEndpoint. Por ejemplo, para transferir el `Expires` encabezado, configura el valor de `response.retain.headers` como `Expires`. 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 configura como `false`, cualquier encabezado especificado en la propiedad `response.retain.headers` aún se establece en el mensaje saliente.
`retain.queryparams. enabled`	`true`	De forma predeterminada, Apigee Edge siempre conserva 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 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 de ProxyEndpoint

Nombre de la propiedad	Valor predeterminado	Descripción
`X-Forwarded-For`	`false`	Cuando se configura como `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`	Según la configuración predeterminada (`false`), las cargas útiles de la solicitud HTTP se leen en un búfer y las políticas que pueden operar en la carga útil funcionan de la manera esperada. En los casos en que las cargas útiles sean más grandes que el tamaño del búfer (10 MB), puedes establecer este atributo como `true`. Cuando es `true`, las cargas útiles de la solicitud HTTP no se leen en un búfer, sino que se transmiten sin modificaciones al flujo de solicitud de TargetEndpoint. En este caso, se omiten las políticas que operan en la carga útil del flujo de solicitud de ProxyEndpoint. Consulta también Solicitudes y respuestas de transmisión.
`response.streaming. enabled`	`false`	Según la configuración predeterminada (`false`), las cargas útiles de la respuesta HTTP se leen en un búfer y las políticas que pueden operar en la carga útil funcionan de la manera esperada. En los casos en que las cargas útiles sean más grandes que el tamaño del búfer (10 MB), puedes establecer este atributo como `true`. Cuando es `true`, las cargas útiles de respuesta HTTP no se leen en un búfer, sino que se transmiten sin modificaciones al cliente. En este caso, se omiten las políticas que operan en la carga útil del 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 establecido para cualquier mensaje recibido. Por ejemplo, cuando un cliente envía una solicitud que usa compresión gzip, Apigee Edge reenvía la solicitud al destino mediante la compresión gzip. Puedes configurar los algoritmos de compresión para que se apliquen de forma explícita mediante la configuración de 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 o descompresión con compresión GZIP/deflate?
`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 los clientes que tienen proxies de API que tardan más en ejecutarse. Por ejemplo, supongamos que necesitas que proxies específicos se agoten después de 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 aumentar los tiempos de espera del sistema puede generar problemas de rendimiento, ya que todos los proxies sin una configuración de api.timeout usan el tiempo de espera del balanceador de cargas, el router y el procesador de mensajes nuevos. 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 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 el tiempo de espera del proxy de API, siempre que el tiempo de espera sea menor que el tiempo de espera estándar del procesador de mensajes de 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, el funcionamiento de io.timeout.millis y api.timeout está relacionado. En cada solicitud a un proxy de API:

El router envía su valor de tiempo de espera al Message Processor. El valor del tiempo de espera del router es el valor de proxy_read_timeout establecido por el host virtual que controla la solicitud o el valor predeterminado del tiempo de espera de 57 segundos.
Luego, el Message Processor 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 configura en el nivel del proxy, configúralo en Message Processor en el menor tiempo de espera del router o en el valor de api.timeout.
El valor de api.timeout especifica la cantidad máxima de tiempo que un proxy de API tiene para ejecutar 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 Message Processor envíe la solicitud al extremo de destino, este calcula (api.timeout - el tiempo transcurrido desde el inicio de la solicitud). Si el valor es menor que cero, el tiempo máximo para manejar la solicitud venció y el Message Processor muestra un 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, Message Processor determina la menor cantidad de (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 se muestra.
- Si se agota el tiempo de espera mientras se lee la respuesta HTTP, 504, Gateway Timeout se muestra.

Acerca de ScriptTarget para aplicaciones Node.js

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

Acerca de los extremos HostedTarget

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