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

Вы просматриваете документацию по 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 и происходит тайм-аут.

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 как ошибки, а коды 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.
  • none – всегда отправлять сообщение без сжатия;

Также ознакомьтесь со статьей Поддерживает ли 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.
  • none – всегда отправлять сообщение без сжатия;

Также ознакомьтесь со статьей Поддерживает ли Apigee сжатие и распаковку с помощью алгоритмов GZIP и deflate?
api.timeout Н/Д

Как настроить время ожидания для отдельных прокси API

Вы можете настроить прокси API, даже если в них включена потоковая передача, так, чтобы по истечении определенного времени они возвращали статус 504 Gateway Timeout. Основная сфера применения – клиенты, у которых есть прокси API, выполнение которых занимает больше времени. Например, вам нужно, чтобы определенные прокси-серверы отключались через три минуты. Ниже показано, как использовать api.timeout.

  1. Сначала настройте балансировщик нагрузки, маршрутизатор и процессор сообщений так, чтобы время ожидания истекало через три минуты.
  2. Затем настройте соответствующие прокси-серверы так, чтобы время ожидания составляло три минуты. Укажите значение в миллисекундах. Пример: <Property name="api.timeout">180000</Property>.
  3. Однако увеличение системных тайм-аутов может привести к проблемам с производительностью, поскольку все прокси-серверы без настройки api.timeout используют новые, более высокие тайм-ауты балансировщика нагрузки, маршрутизатора и процессора сообщений. Поэтому настройте другие прокси API, которым не требуются более длительные тайм-ауты, на использование более коротких тайм-аутов. Например, следующий код задает для прокси-сервера API время ожидания в одну минуту:
    <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:

  1. Маршрутизатор отправляет значение времени ожидания обработчику сообщений. Значение времени ожидания маршрутизатора – это либо значение proxy_read_timeout, заданное виртуальным хостом, который обрабатывает запрос, либо значение времени ожидания по умолчанию, равное 57 секундам.
  2. Затем Message Processor задает значение api.timeout:
    1. Если параметр api.timeout не задан на уровне прокси, установите для него значение времени ожидания маршрутизатора.
    2. Если api.timeout задано на уровне прокси, установите для него на Message Processor значение, равное меньшему из двух: времени ожидания маршрутизатора или значению api.timeout.

  3. Значение api.timeout определяет максимальное время выполнения прокси-сервера API от запроса к API до ответа.

    После выполнения каждого правила в прокси-сервере API или до того, как Message Processor отправит запрос в целевую конечную точку, Message Processor рассчитывает значение api.timeout (время, прошедшее с начала запроса). Если значение меньше нуля, максимальное время обработки запроса истекло и Message Processor возвращает 504.

  4. Значение io.timeout.millis указывает максимальное время, в течение которого целевая конечная точка должна ответить.

    Перед подключением к целевой конечной точке Message Processor определяет меньшее из двух значений: (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, развернутое в среде Hosted Targets. Подробнее о размещенных целевых объектах…