You're viewing **Apigee Edge** documentation.  
[Go to the
**Apigee X** documentation](http://cloud.google.com/apigee/docs/api-platform/reference/endpoint-properties-reference). info

This topic describes transport properties that can be set in TargetEndpoint and ProxyEndpoint
configurations to control messaging and connection behavior. For full coverage of TargetEndpoint
and ProxyEndpoint configuration, see [API proxy configuration reference](https://docs.apigee.com/api-platform/reference/api-proxy-configuration-reference).

## TargetEndpoint transport properties

The HTTPTargetConnection element in TargetEndpoint configurations defines a set of HTTP
transport properties. You can use these properties to set transport-level configurations.

Properties are set on TargetEndpoint HTTPTargetConnection elements as shown below:

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

> [!NOTE]
> **Note:** Property values can only be literals. You cannot set values using variables.

## TargetEndpoint transport property
Specification

| Property Name | Default Value | Description |
|---|---|---|
| `keepalive.timeout.millis` | `60000` | Connection idle timeout for the target connection in the connection pool. If the connection in the pool is idle beyond the specified limit, then the connection is closed. |
| `connect.timeout.millis` | `3000` | Target connection timeout. Edge returns an HTTP `503` status code if a connection timeout occurs. In some cases an HTTP 504 status code may be returned when `LoadBalancer` is used in the [TargetServer definition](https://docs.apigee.com/api-platform/deploy/load-balancing-across-backend-servers#configuringatargetendpointtoloadbalanceacrossnamedtargetservers) and a timeout occurs. > [!NOTE] > **Note:** In some cases, Apigee will automatically retry the connection up to three times. As a result, the total retry time may exceed what is configured for `connect.timeout.millis`. |
| `io.timeout.millis` | `55000` | If there is no data to read for the specified number of milliseconds, or if the socket is not ready to write data for specified number of milliseconds, then the transaction is treated as a timeout. - If a timeout happens while writing the HTTP request, `408, Request Timeout` is returned. - If a timeout happens while reading the HTTP response, `504, Gateway Timeout` is returned. This value should always be smaller than the value of the [virtual host's proxy_read_timeout property](https://docs.apigee.com/api-platform/fundamentals/virtual-host-property-reference). This value should be less than the timeout used by the Router for communicating with the Message Processor. See [Configuring the Router timeout](https://docs.apigee.com/private-cloud/latest/configure-router-timeout) for more. See [Setting io.timeout.millis and api.timeout for Edge](https://docs.apigee.com/api-platform/reference/endpoint-properties-reference#cloud-timeouts) for more. |
| `supports.http10` | `true` | If this is `true` and the client sends a 1.0 request, the target is also sent a 1.0 request. Otherwise 1.1 request is sent to target. |
| `supports.http11` | `true` | If this is `true` and the client sends a 1.1 request, the target is also sent a 1.1 request, otherwise 1.0 request is sent to target. |
| `use.proxy` | `true` | If set to `true`, and proxy configurations are specified in `http.properties` (on-premises deployments only), then target connections are set to use the specified proxy. |
| `use.proxy.tunneling` | `true` | If this is set to `true`, and proxy configurations are specified in `http.properties` (on-premises deployments only), then target connections are set to use the specified tunnel. If the target uses TLS/SSL, then this property is ignored, and the message is always sent via a tunnel. |
| `enable.method.override` | `false` | For the specified HTTP method, sets an `X-HTTP-Method-Override` header on the outbound request to the target service. For example, `<Property name="GET.override.method">POST</Property>` |
| `*.override.method` | N/A | For the specified HTTP method, sets an `X-HTTP-Method-Override` header on the outbound request. For example, `<Property name="GET.override.method">POST</Property>` |
| `request.streaming.enabled` | `false` | By default (`false`), HTTP request payloads are read into a buffer, and policies that can operate on the payload work as expected. In cases where the payloads are larger than the buffer size (10 MB), you can set this attribute to `true`. When `true`, HTTP request payloads are not read into a buffer; they are streamed as-is to the target endpoint. In this case, any policies that operate on the payload in the TargetEndpoint request flow are bypassed. See also [Streaming requests and responses](https://docs.apigee.com/api-platform/develop/enabling-streaming). |
| `response.streaming.enabled` | `false` | By default (`false`), HTTP response payloads are read into a buffer, and policies that can operate on the payload work as expected. In cases where the payloads are larger than the buffer size (10 MB), you can set this attribute to `true`. When `true`, HTTP response payloads are not read into a buffer; they are streamed as-is to the ProxyEndpoint response flow. In this case, any policies that operate on the payload in the TargetEndpoint response flow are bypassed. See also [Streaming requests and responses](https://docs.apigee.com/api-platform/develop/enabling-streaming). |
| `success.codes` | N/A | By default, Apigee Edge treats HTTP code `4XX` or `5XX` as errors, and it treats HTTP code `1XX`, `2XX`, `3XX` as success. This property enables explicit definition of success codes, for example, `2XX, 1XX, 505` treats any `100`, `200` and `505` HTTP response codes as success. Setting this property overwrites the default values. Therefore, if you want to add HTTP code `400` to the list of default success codes, set this property as: \<Property name="success.codes"\>1XX,2XX,3XX,400\</Property\> If you want only HTTP code `400` to be treated as a success code, set the property as: \<Property name="success.codes"\>400\</Property\> By setting HTTP code `400` as the only success code, the codes `1XX`, `2XX`, and `3XX` are treated as failures. |
| `compression.algorithm` | N/A | By default, Apigee Edge forwards requests to the target using the same compression type as the client request. If the request is received from client using, for example, gzip compression, then Apigee Edge forwards the request to target using gzip compression. If the response received from target uses deflate, then Apigee Edge forwards the response to the client using deflate. Supported values are: - **gzip:** always send message using gzip compression - **deflate:** always send message using deflate compression - **none:** always send message without any compression See also: [Does Apigee support compression/de-compression with GZIP/deflate compression?](https://discuss.google.dev/t/does-apigee-support-compression-de-compression-with-gzip-deflate-compression/7335) |
| `request.retain.headers. enabled` | `true` | By default, Apigee Edge always retains all HTTP headers on outbound messages. When set to `true`, all HTTP headers present on the inbound request are set on the outbound request. |
| `request.retain.headers` | N/A | Defines specific HTTP headers from the request that should be set on the outbound request to the target service. For example, to *passthrough* the `User-Agent` header, set the value of `request.retain.headers` to `User-Agent`. Multiple HTTP headers are specified as a comma-separated list, for example, `User-Agent,Referer,Accept-Language`. This property overrides `request.retain.headers.enabled`. If `request.retain.headers.enabled` is set to `false`, any headers specified in the `request.retain.headers` property are still set on the outbound message. |
| `response.retain.headers. enabled` | `true` | By default, Apigee Edge always retains all HTTP headers on outbound messages. When set to `true`, all HTTP headers present on the inbound response from the target service are set on the outbound response before it is passed to the ProxyEndpoint. |
| `response.retain.headers` | N/A | Defines specific HTTP headers from the response that should be set on the outbound response before it is passed to the ProxyEndpoint. For example, to *passthrough* the `Expires` header, set the value of `response.retain.headers` to `Expires`. Multiple HTTP headers are specified as a comma-separated list, for example, `Expires,Set-Cookie`. This property overrides `response.retain.headers.enabled`. If `response.retain.headers.enabled` is set to `false`, any headers specified in the `response.retain.headers` property are still set on the outbound message. |
| `retain.queryparams. enabled` | `true` | By default, Apigee Edge always retains all query parameters on outbound requests. When set to `true`, all query parameters present on the inbound request are set on the outbound request to the target service. |
| `retain.queryparams` | N/A | Defines specific query parameters to set on the outbound request. For example, to include the query parameter `apikey` from the request message, set `retain.queryparams` to `apikey`. Multiple query parameters are specified as a comma-separated list, for example, `apikey,environment`. This property overrides `retain.queryparams.enabled`. |

## ProxyEndpoint transport properties

ProxyEndpoint HTTPTargetConnection elements define a set of HTTP transport properties. These
properties can be used to set transport-level configurations.

Properties are set on ProxyEndpoint HTTPProxyConnection elements as follows:

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

For more on virtual hosts, see [About virtual hosts](https://docs.apigee.com/api-platform/fundamentals/virtual-hosts).

## ProxyEndpoint transport property
Specification

| Property Name | Default Value | Description |
|---|---|---|
| `X-Forwarded-For` | `false` | When set to `true`, the virtual host's IP address is added to the outbound request as the value of the HTTP `X-Forwarded-For` header. |
| `request.streaming. enabled` | `false` | By default (`false`), HTTP request payloads are read into a buffer, and policies that can operate on the payload work as expected. In cases where the payloads are larger than the buffer size (10 MB), you can set this attribute to `true`. When `true`, HTTP request payloads are not read into a buffer; they are streamed as-is to the TargetEndpoint request flow. In this case, any policies that operate on the payload in the ProxyEndpoint request flow are bypassed. See also [Streaming requests and responses](https://docs.apigee.com/api-platform/develop/enabling-streaming). |
| `response.streaming. enabled` | `false` | By default (`false`), HTTP response payloads are read into a buffer, and policies that can operate on the payload work as expected. In cases where the payloads are larger than the buffer size (10 MB), you can set this attribute to `true`. When `true`, HTTP response payloads are not read into a buffer; they are streamed as-is to the client. In this case, any policies that operate on the payload in the ProxyEndpoint response flow are bypassed. See also [Streaming requests and responses](https://docs.apigee.com/api-platform/develop/enabling-streaming). |
| `compression.algorithm` | N/A | By default, Apigee Edge honors the compression type set for any message received. For example, where a client submits a request that uses gzip compression, Apigee Edge forwards the request to target using gzip compression. You can configure compression algorithms to be explicitly applied by setting this property on the TargetEndpoint or ProxyEndpoint. Supported values are: - **gzip:** always send message using gzip compression - **deflate:** always send message using deflate compression - **none:** always send message without any compression See also: [Does Apigee support compression/de-compression with GZIP/deflate compression?](https://discuss.google.dev/t/does-apigee-support-compression-de-compression-with-gzip-deflate-compression/7335) |
| `api.timeout` | N/A | **Configure the timeout for individual API proxies** You can configure API proxies, even those with [streaming](https://docs.apigee.com/api-platform/develop/enabling-streaming) enabled, to time out after a specified time with a `504 Gateway Timeout` status. The primary use case is for customers who have API proxies that take longer to execute. For example, say you need specific proxies to time out at 3 minutes. Following is how you'd use `api.timeout`. 1. First, be sure to configure the load balancer, router, and message processor to time out *after* three minutes. 2. Then configure the relevant proxies to time out at three minutes. Specify the value in milliseconds. For example: `<Property name="api.timeout">180000</Property>` 3. Note, however, that raising the system timeouts could result in performance issues, because all proxies without an api.timeout setting use the new, higher load balancer, router, and message processor timeouts. So configure other API proxies that don't require longer timeouts to use lower timeouts. For example, the following sets an API proxy to time out after 1 minute: `<Property name="api.timeout">60000</Property>` You cannot set this property with a variable. Customers who can't modify the Edge timeouts can also configure an API proxy timeout, as long as the timeout is shorter than the standard Edge message processor timeout of 57 seconds. See [Setting io.timeout.millis and api.timeout for Edge](https://docs.apigee.com/api-platform/reference/endpoint-properties-reference#cloud-timeouts) for more. |

## Setting io.timeout.millis and api.timeout for Edge

On Edge, the operation of `io.timeout.millis` and `api.timeout`
are related.

On every request to an API proxy:

1. The Router sends its timeout value to the Message Processor. The Router timeout value is either the value of `proxy_read_timeout` set by the [virtual host](https://docs.apigee.com/api-platform/fundamentals/virtual-host-property-reference) that handles the request, or the default timeout value of 57 seconds.
2. The Message Processor then sets `api.timeout`:
   1. If `api.timeout` is **not** set at the proxy level, set it to the Router timeout.
   2. If `api.timeout` is set at the proxy level, set it on the Message Processor to the lesser of the Router timeout or the value of `api.timeout`.
3. The value of `api.timeout` specifies the maximum amount of time an API proxy has
   to execute from the API request to the response.

   After each policy in the API proxy executes,
   or before the Message Processor sends the request to the target endpoint,
   the Message Processor calculates (`api.timeout` - elapsed time from the start of the request).
   If the value is less than zero, then the maximum amount of time to handle the request has expired and
   the Message Processor returns `504`.

   <br />

4. The value of `io.timeout.millis` specifies the maximum amount of time that the target endpoint
   has to respond.

   Before connecting to a target endpoint, the Message Processor determines the lesser of
   (`api.timeout` - elapsed time from the start of the request) and `io.timeout.millis`.
   It then sets `io.timeout.millis` to that value.
   - If a timeout happens while writing the HTTP request, `408, Request Timeout` is returned.
   - If a timeout happens while reading the HTTP response, `504, Gateway Timeout` is returned.

## About ScriptTarget for Node.js applications

The ScriptTarget element is used to integrate a Node.js application into your proxy. For
information on using Node.js and ScriptTarget, see:

- [Specify the Node.js target with ScriptTarget](https://docs.apigee.com/api-platform/nodejs/adding-nodejs-existing-api-proxy#specifythenodejstargetwithscripttarget)
- [Advanced ScriptTarget configuration](https://docs.apigee.com/api-platform/nodejs/understanding-edge-support-nodejs-modules#advancedscripttargetconfiguration)

## About HostedTarget endpoints

An empty `<HostedTarget/>` tag tells Edge to use as its target a Node.js
application that is deployed to the Hosted Targets environment. For details, see
[Hosted Targets overview](https://docs.apigee.com/api-platform/hosted-targets/hosted-targets-overview).