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

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

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

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

Транспортные свойства TargetEndpoint

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

Свойства элементов TargetEnpoint 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, если в определении TargetServer используется `LoadBalancer` и происходит истечение времени ожидания. Примечание: В некоторых случаях 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-транспорта. Эти свойства можно использовать для настройки конфигураций на уровне транспорта.

Свойства элементов ProxyEnpoint 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, развернутое в среде Hosted Targets. Подробнее см. в разделе «Обзор Hosted Targets» .