Эта страница переведена с помощью Cloud Translation API.

Справочник по свойствам конечной точки

Вы просматриваете документацию Apigee Edge .
Перейдите к документации Apigee X. информация

В этом разделе описаны свойства транспорта, которые можно установить в конфигурациях TargetEndpoint и ProxyEndpoint для управления обменом сообщениями и поведением подключения. Полный обзор конфигурации TargetEndpoint и ProxyEndpoint см. в справочнике по настройке прокси-сервера API .

Свойства транспорта TargetEndpoint

Элемент HTTPTargetConnection в конфигурациях TargetEndpoint определяет набор свойств транспорта HTTP. Эти свойства можно использовать для установки конфигураций транспортного уровня.

Свойства устанавливаются для элементов TargetEndpoint HTTPTargetConnection, как показано ниже:

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

Спецификация транспортного свойства TargetEndpoint

Имя свойства	Значение по умолчанию	Описание
`keepalive.timeout.millis`	`60000`	Тайм-аут простоя соединения для целевого соединения в пуле соединений. Если соединение в пуле простаивает сверх указанного лимита, то соединение закрывается.
`connect.timeout.millis`	`3000`	Тайм-аут целевого соединения. Edge возвращает код состояния HTTP `503` , если происходит тайм-аут соединения. В некоторых случаях код состояния HTTP 504 может быть возвращен, когда `LoadBalancer` используется в определении TargetServer и происходит тайм-аут. Примечание. В некоторых случаях Apigee автоматически повторяет попытку подключения до трех раз. В результате общее время повтора может превысить значение, настроенное для `connect.timeout.millis` .
`io.timeout.millis`	`55000`	Если нет данных для чтения в течение указанного количества миллисекунд или если сокет не готов записывать данные в течение указанного количества миллисекунд, транзакция рассматривается как тайм-аут. Если во время записи HTTP-запроса происходит тайм-аут, возвращается `408, Request Timeout` . Если во время чтения HTTP-ответа происходит тайм-аут, возвращается `504, Gateway Timeout` . Это значение всегда должно быть меньше значения свойства proxy_read_timeout виртуального хоста . Это значение должно быть меньше времени ожидания, используемого маршрутизатором для связи с процессором сообщений. Дополнительную информацию см. в разделе Настройка тайм-аута маршрутизатора . Дополнительную информацию см. в разделе Настройка io.timeout.millis и api.timeout для Edge .
`supports.http10`	`true`	Если это `true` и клиент отправляет запрос 1.0, целевому объекту также отправляется запрос 1.0. В противном случае запрос 1.1 отправляется в цель.
`supports.http11`	`true`	Если это `true` и клиент отправляет запрос 1.1, целевому объекту также отправляется запрос 1.1, в противном случае целевому объекту отправляется запрос 1.0.
`use.proxy`	`true`	Если установлено значение `true` и конфигурации прокси-сервера указаны в `http.properties` (только для локальных развертываний), целевые соединения настроены на использование указанного прокси-сервера.
`use.proxy.tunneling`	`true`	Если для этого параметра задано значение `true` и в `http.properties` указаны конфигурации прокси-сервера (только для локальных развертываний), то целевые соединения настроены на использование указанного туннеля. Если цель использует TLS/SSL, это свойство игнорируется, и сообщение всегда отправляется через туннель.
`enable.method.override`	`false`	Для указанного метода HTTP устанавливает заголовок `X-HTTP-Method-Override` в исходящем запросе к целевой службе. Например, `<Property name="GET.override.method">POST</Property>`
`*.override.method`	Н/Д	Для указанного метода HTTP устанавливает заголовок `X-HTTP-Method-Override` в исходящем запросе. Например, `<Property name="GET.override.method">POST</Property>`
`request.streaming.enabled`	`false`	По умолчанию ( `false` ) полезные данные HTTP-запроса считываются в буфер, а политики, которые могут работать с полезными данными, работают должным образом. В случаях, когда полезные данные превышают размер буфера (10 МБ), вы можете установить для этого атрибута значение `true` . Если `true` , полезные данные HTTP-запроса не считываются в буфер; они передаются в целевую конечную точку в неизменном виде. В этом случае все политики, которые работают с полезными данными в потоке запросов TargetEndpoint, игнорируются. См. также Потоковая передача запросов и ответов .
`response.streaming.enabled`	`false`	По умолчанию ( `false` ) полезные данные ответа HTTP считываются в буфер, и политики, которые могут работать с полезными данными, работают должным образом. В случаях, когда полезные данные превышают размер буфера (10 МБ), вы можете установить для этого атрибута значение `true` . Если `true` , полезные данные ответа HTTP не считываются в буфер; они передаются как есть в поток ответов ProxyEndpoint. В этом случае любые политики, которые работают с полезными данными в потоке ответов TargetEndpoint, игнорируются. См. также Потоковая передача запросов и ответов .
`success.codes`	Н/Д	По умолчанию Apigee Edge рассматривает HTTP-код `4XX` или `5XX` как ошибки, а HTTP-коды `1XX` , `2XX` , `3XX` как успешные. Это свойство позволяет явно определять коды успеха, например `2XX, 1XX, 505` рассматривает любые коды ответа HTTP `100` , `200` и `505` как успешные. Установка этого свойства перезаписывает значения по умолчанию. Поэтому, если вы хотите добавить HTTP-код `400` в список кодов успеха по умолчанию, установите это свойство как: <Property name="success.codes">1XX,2XX,3XX,400</Property> Если вы хотите, чтобы кодом успеха считался только HTTP-код `400` , задайте для свойства следующее: <Property name="success.codes">400</Property> Если установить HTTP-код `400` в качестве единственного кода успеха, коды `1XX` , `2XX` и `3XX` будут считаться неудачными.
`compression.algorithm`	Н/Д	По умолчанию Apigee Edge пересылает запросы цели, используя тот же тип сжатия, что и запрос клиента. Если запрос получен от клиента с использованием, например, сжатия gzip, Apigee Edge пересылает запрос целевому пользователю с использованием сжатия gzip. Если ответ, полученный от цели, использует deflate, Apigee Edge пересылает ответ клиенту, используя deflate. Поддерживаемые значения: gzip: всегда отправлять сообщение, используя сжатие gzip deflate: всегда отправлять сообщение с использованием сжатия deflate нет: всегда отправлять сообщение без сжатия См. также: Поддерживает ли Apigee сжатие/распаковку с помощью сжатия GZIP/deflate?
`request.retain.headers. enabled`	`true`	По умолчанию Apigee Edge всегда сохраняет все заголовки HTTP в исходящих сообщениях. Если установлено значение `true` , все HTTP-заголовки, присутствующие во входящем запросе, устанавливаются в исходящем запросе.
`request.retain.headers`	Н/Д	Определяет конкретные заголовки HTTP из запроса, которые должны быть установлены в исходящем запросе к целевой службе. Например, чтобы передать заголовок `User-Agent` , установите для параметра `request.retain.headers` значение `User-Agent` . Несколько заголовков HTTP указываются в виде списка, разделенного запятыми, например `User-Agent,Referer,Accept-Language` . Это свойство переопределяет `request.retain.headers.enabled` . Если для `request.retain.headers.enabled` установлено значение `false` , любые заголовки, указанные в свойстве `request.retain.headers` , по-прежнему устанавливаются в исходящем сообщении.
`response.retain.headers. enabled`	`true`	По умолчанию Apigee Edge всегда сохраняет все заголовки HTTP в исходящих сообщениях. Если установлено значение `true` , все заголовки HTTP, присутствующие во входящем ответе от целевой службы, устанавливаются в исходящем ответе перед его передачей в ProxyEndpoint.
`response.retain.headers`	Н/Д	Определяет конкретные заголовки HTTP из ответа, которые должны быть установлены в исходящем ответе перед его передачей в ProxyEndpoint. Например, чтобы передать заголовок `Expires` , установите для `response.retain.headers` значение `Expires` . Несколько заголовков HTTP указываются в виде списка, разделенного запятыми, например `Expires,Set-Cookie` . Это свойство переопределяет `response.retain.headers.enabled` . Если для `response.retain.headers.enabled` установлено значение `false` , все заголовки, указанные в свойстве `response.retain.headers` , по-прежнему устанавливаются в исходящем сообщении.
`retain.queryparams. enabled`	`true`	По умолчанию Apigee Edge всегда сохраняет все параметры исходящих запросов. Если установлено значение `true` , все параметры запроса, присутствующие во входящем запросе, устанавливаются в исходящем запросе к целевой службе.
`retain.queryparams`	Н/Д	Определяет конкретные параметры запроса, которые необходимо установить в исходящем запросе. Например, чтобы включить параметр запроса `apikey` из сообщения запроса, установите для параметра `retain.queryparams` значение `apikey` . Несколько параметров запроса указываются в виде списка, разделенного запятыми, например `apikey,environment` . Это свойство переопределяет `retain.queryparams.enabled` .

Свойства транспорта ProxyEndpoint

Элементы ProxyEndpoint HTTPTargetConnection определяют набор свойств транспорта HTTP. Эти свойства можно использовать для установки конфигураций транспортного уровня.

Свойства элементов ProxyEndpoint HTTPProxyConnection задаются следующим образом:

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

Дополнительную информацию о виртуальных хостах см. в разделе О виртуальных хостах .

Спецификация транспортного свойства ProxyEndpoint

Имя свойства	Значение по умолчанию	Описание
`X-Forwarded-For`	`false`	Если установлено значение `true` , IP-адрес виртуального хоста добавляется к исходящему запросу как значение заголовка HTTP `X-Forwarded-For` .
`request.streaming. enabled`	`false`	По умолчанию ( `false` ) полезные данные HTTP-запроса считываются в буфер, а политики, которые могут работать с полезными данными, работают должным образом. В случаях, когда полезные данные превышают размер буфера (10 МБ), вы можете установить для этого атрибута значение `true` . Если `true` , полезные данные HTTP-запроса не считываются в буфер; они передаются как есть в поток запросов TargetEndpoint. В этом случае все политики, которые работают с полезными данными в потоке запросов ProxyEndpoint, игнорируются. См. также Потоковая передача запросов и ответов .
`response.streaming. enabled`	`false`	По умолчанию ( `false` ) полезные данные ответа HTTP считываются в буфер, и политики, которые могут работать с полезными данными, работают должным образом. В случаях, когда полезные данные превышают размер буфера (10 МБ), вы можете установить для этого атрибута значение `true` . Если `true` , полезные данные HTTP-ответа не считываются в буфер; они передаются клиенту как есть. В этом случае любые политики, которые работают с полезными данными в потоке ответов ProxyEndpoint, игнорируются. См. также Потоковая передача запросов и ответов .
`compression.algorithm`	Н/Д	По умолчанию Apigee Edge учитывает установленный тип сжатия для любого полученного сообщения. Например, когда клиент отправляет запрос, использующий сжатие gzip, Apigee Edge перенаправляет запрос целевому пользователю, используя сжатие gzip. Вы можете настроить алгоритмы сжатия для явного применения, установив это свойство в TargetEndpoint или ProxyEndpoint. Поддерживаемые значения: gzip: всегда отправлять сообщения, используя сжатие gzip deflate: всегда отправлять сообщение с использованием сжатия deflate нет: всегда отправлять сообщение без сжатия См. также: Поддерживает ли Apigee сжатие/распаковку с помощью сжатия GZIP/deflate?
`api.timeout`	Н/Д	Настройте тайм-аут для отдельных прокси API Вы можете настроить прокси-серверы API, даже те, у которых включена потоковая передача , на тайм-аут через определенное время со статусом `504 Gateway Timeout` . Основной вариант использования — для клиентов, у которых есть прокси API, выполнение которых занимает больше времени. Например, предположим, что вам нужны определенные прокси, чтобы время ожидания составляло 3 минуты. Ниже показано, как использовать `api.timeout` . Во-первых, обязательно настройте балансировщик нагрузки, маршрутизатор и процессор сообщений на тайм-аут через три минуты. Затем настройте соответствующие прокси на время ожидания в три минуты. Укажите значение в миллисекундах. Например: `<Property name="api.timeout">180000</Property>` Однако обратите внимание, что увеличение системных тайм-аутов может привести к проблемам с производительностью, поскольку все прокси-серверы без параметра api.timeout используют новые, более высокие тайм-ауты балансировщика нагрузки, маршрутизатора и процессора сообщений. Поэтому настройте другие прокси-серверы API, которым не требуются более длительные таймауты, чтобы использовать более низкие таймауты. Например, следующее устанавливает время ожидания прокси-сервера API через 1 минуту: `<Property name="api.timeout">60000</Property>` Вы не можете установить это свойство с помощью переменной. Клиенты, которые не могут изменять тайм-ауты Edge, также могут настроить тайм-аут прокси-сервера API, если этот тайм-аут короче стандартного тайм-аута процессора сообщений Edge, составляющего 57 секунд. Дополнительную информацию см. в разделе Настройка io.timeout.millis и api.timeout для Edge .

Настройка io.timeout.millis и api.timeout для Edge

В Edge работа io.timeout.millis и api.timeout связана. При каждом запросе к прокси-серверу API:

Маршрутизатор отправляет значение таймаута процессору сообщений. Значение таймаута маршрутизатора — это либо значение proxy_read_timeout , установленное виртуальным хостом , который обрабатывает запрос, либо значение таймаута по умолчанию, равное 57 секундам.
Затем процессор сообщений устанавливает api.timeout :
1. Если api.timeout не установлен на уровне прокси, установите для него значение тайм-аута маршрутизатора.
2. Если api.timeout установлен на уровне прокси-сервера, установите для него на процессоре сообщений меньшее значение из тайм-аута маршрутизатора или значения api.timeout .
Значение api.timeout указывает максимальное время, в течение которого прокси-сервер API должен выполниться от запроса API до ответа.
После выполнения каждой политики в прокси-сервере API или до того, как процессор сообщений отправит запрос целевой конечной точке, процессор сообщений вычисляет ( api.timeout — время, прошедшее с начала запроса). Если значение меньше нуля, то максимальное время для обработки запроса истекло, и процессор сообщений возвращает 504 .
Значение io.timeout.millis указывает максимальное время, в течение которого целевая конечная точка должна ответить.
Перед подключением к целевой конечной точке процессор сообщений определяет меньшее из ( api.timeout — время, прошедшее с начала запроса) и io.timeout.millis . Затем он устанавливает для io.timeout.millis это значение.
- Если во время записи HTTP-запроса происходит тайм-аут, возвращается 408, Request Timeout .
- Если во время чтения ответа HTTP происходит тайм-аут, возвращается 504, Gateway Timeout .

О ScriptTarget для приложений Node.js

Элемент ScriptTarget используется для интеграции приложения Node.js в ваш прокси. Информацию об использовании Node.js и ScriptTarget см.:

О конечных точках HostedTarget

Пустой тег <HostedTarget/> указывает Edge использовать в качестве цели приложение Node.js, развернутое в среде размещенных целевых объектов. Подробности см. в обзоре размещенных целевых объектов .