Ta strona została przetłumaczona przez Cloud Translation API.

Dokumentacja właściwości punktu końcowego

Przeglądasz dokumentację Apigee Edge.
Otwórz dokumentację Apigee X. Informacje

W tym temacie opisujemy właściwości transportu, które można ustawić w konfiguracjach TargetEndpoint i ProxyEndpoint do sterowania wiadomościami i zachowaniem połączenia. Więcej informacji o konfiguracji TargetEndpoint i ProxyEndpoint znajdziesz w dokumentacji dotyczącej konfiguracji serwera proxy interfejsu API.

Właściwości transportu docelowego punktu końcowego

Element HTTPTargetConnection w konfiguracjach TargetEndpoint określa zestaw właściwości transportu HTTP. Za pomocą tych właściwości możesz określać konfiguracje na poziomie transportu.

Właściwości ustawia się w elementach TargetEndpoint HTTPTargetConnection w ten sposób:

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

Specyfikacja właściwości transportu docelowego punktu końcowego

Nazwa właściwości	Wartość domyślna	Opis
`keepalive.timeout.millis`	`60000`	Limit czasu bezczynności połączenia dla połączenia docelowego w puli połączeń. Jeśli połączenie w puli jest nieaktywne po przekroczeniu określonego limitu, połączenie jest zamknięte.
`connect.timeout.millis`	`3000`	Docelowy czas oczekiwania na połączenie. Po przekroczeniu limitu czasu połączenia Edge zwraca kod stanu HTTP `503`.
`io.timeout.millis`	`55000`	Jeśli nie ma danych do odczytania przez określoną liczbę milisekund lub gniazdo nie jest gotowe do zapisu danych przez określoną liczbę milisekund, transakcja jest traktowana jako limit czasu. Jeśli podczas zapisywania żądania HTTP limit czasu zostanie przekroczony, zwracany jest kod `408, Request Timeout`. Jeśli podczas odczytu odpowiedzi HTTP minie limit czasu, zwracana jest wartość `504, Gateway Timeout`. Ta wartość powinna zawsze być mniejsza od wartości właściwości proxy_read_timeout hosta wirtualnego. Ta wartość powinna być mniejsza niż limit czasu używany przez router do komunikacji z procesorem wiadomości. Więcej informacji znajdziesz w artykule Konfigurowanie limitu czasu routera. Więcej informacji znajdziesz w artykule Konfigurowanie ustawień io.timeout.millis i api.timeout dla Edge.
`supports.http10`	`true`	Jeśli to `true`, a klient wyśle żądanie 1.0, do miejsca docelowego zostanie również wysłane żądanie 1.0. W przeciwnym razie do celu wysyłane jest żądanie 1.1.
`supports.http11`	`true`	Jeśli to `true`, a klient wyśle żądanie 1.1, do celu wysyłane jest żądanie 1.1. W przeciwnym razie do celu wysyłane jest żądanie 1.0.
`use.proxy`	`true`	Jeśli ustawiono wartość `true`, a konfiguracje serwera proxy są określone w ustawieniu `http.properties` (tylko w przypadku wdrożeń lokalnych), połączenia docelowe są skonfigurowane tak, aby używać określonego serwera proxy.
`use.proxy.tunneling`	`true`	Jeśli ustawiona jest wartość `true`, a konfiguracje serwera proxy są określone w `http.properties` (tylko w przypadku wdrożeń lokalnych), połączenia docelowe są ustawione tak, aby korzystały z określonego tunelu. Jeśli środowisko docelowe używa TLS/SSL, ta właściwość jest ignorowana, a wiadomość jest zawsze wysyłana przez tunel.
`enable.method.override`	`false`	W przypadku określonej metody HTTP ustawia nagłówek `X-HTTP-Method-Override` w żądaniu wychodzącym dla usługi docelowej. Przykład: `<Property name="GET.override.method">POST</Property>`
`*.override.method`	Nie dotyczy	W przypadku określonej metody HTTP ustawia nagłówek `X-HTTP-Method-Override` w żądaniu wychodzącym. Przykład: `<Property name="GET.override.method">POST</Property>`
`request.streaming.enabled`	`false`	Domyślnie (`false`) ładunki żądań HTTP są odczytywane do bufora, a zasady, które mogą działać na ładunku, działają zgodnie z oczekiwaniami. W przypadku, gdy ładunki są większe niż rozmiar bufora (10 MB), możesz ustawić ten atrybut na `true`. Gdy `true`, ładunki żądania HTTP nie są odczytywane do bufora; są przesyłane do docelowego punktu końcowego w niezmienionej postaci. W tym przypadku wszystkie zasady, które działają na ładunku w przepływie żądania TargetEndpoint, są pomijane. Zapoznaj się też z sekcją Przesyłanie żądań i odpowiedzi.
`response.streaming.enabled`	`false`	Domyślnie (`false`) ładunki odpowiedzi HTTP są odczytywane do bufora, a zasady, które mogą działać na ładunku, działają zgodnie z oczekiwaniami. W przypadku, gdy ładunki są większe niż rozmiar bufora (10 MB), możesz ustawić ten atrybut na `true`. Gdy `true`, ładunki odpowiedzi HTTP nie są odczytywane do bufora; są przesyłane strumieniowo w stanie niezmienionym do przepływu odpowiedzi ProxyEndpoint. W tym przypadku wszystkie zasady, które działają na ładunku w przepływie odpowiedzi TargetEndpoint, są pomijane. Zapoznaj się też z informacjami na temat żądań i odpowiedzi dotyczących strumieniowania.
`success.codes`	Nie dotyczy	Apigee Edge domyślnie traktuje kod HTTP `4XX` lub `5XX` jako błędy, a kod HTTP `1XX`, `2XX` i `3XX` traktuje jako udany. Ta właściwość umożliwia jednoznaczne definiowanie kodów powodzenia, np. `2XX, 1XX, 505` traktuje wszystkie kody odpowiedzi HTTP `100`, `200` i `505` jako powodzenie. Ustawienie tej właściwości zastępuje wartości domyślne. Jeśli więc chcesz dodać kod HTTP `400` do listy domyślnych kodów sukcesu, ustaw tę właściwość jako: <Property name="success.codes">1XX,2XX,3XX,400</Property> Jeśli chcesz, aby jako kod powodzenia był traktowany tylko kod HTTP `400`, ustaw właściwość jako: <Property name="success.codes">400</Property> Jeśli ustawisz kod HTTP `400` jako jedyny kod powodzenia, kody `1XX`, `2XX` i `3XX` będą traktowane jako błędy.
`compression.algorithm`	Nie dotyczy	Domyślnie Apigee Edge przekazuje żądania do środowiska docelowego przy użyciu tego samego typu kompresji co żądanie klienta. Jeśli żądanie zostało odebrane z klienta przy użyciu np. kompresji gzip, Apigee Edge przekazuje żądanie do celu z użyciem kompresji gzip. Jeśli w odpowiedzi otrzymanej z miejsca docelowego zastosowano deflate, Apigee Edge przekazuje odpowiedź do klienta za pomocą deflate. Obsługiwane wartości: gzip: zawsze wysyłaj wiadomość przy użyciu kompresji gzip deflate: zawsze wysyłaj wiadomość przy użyciu kompresji deflate none (brak): zawsze wysyłaj wiadomość bez kompresji. Zobacz też: Czy Apigee obsługuje kompresję/dekompresję za pomocą programu GZIP/deflate?
`request.retain.headers. enabled`	`true`	Domyślnie Apigee Edge zawsze zachowuje wszystkie nagłówki HTTP w wiadomościach wychodzących. Gdy zasada ma wartość `true`, wszystkie nagłówki HTTP znajdujące się w żądaniu przychodzącym są ustawiane w żądaniu wychodzącym.
`request.retain.headers`	Nie dotyczy	Definiuje określone nagłówki HTTP z żądania, które należy ustawić w żądaniu wychodzącym do usługi docelowej. Aby na przykład przekazywać nagłówek `User-Agent`, ustaw wartość `request.retain.headers` na `User-Agent`. Kilka nagłówków HTTP można podać w postaci listy rozdzielanej przecinkami, np. `User-Agent,Referer,Accept-Language`. Ta właściwość zastępuje właściwość `request.retain.headers.enabled`. Jeśli `request.retain.headers.enabled` ma wartość `false`, wszystkie nagłówki określone we właściwości `request.retain.headers` będą nadal ustawione w wiadomości wychodzącej.
`response.retain.headers. enabled`	`true`	Domyślnie Apigee Edge zawsze zachowuje wszystkie nagłówki HTTP w wiadomościach wychodzących. Gdy ustawiona jest wartość `true`, wszystkie nagłówki HTTP znajdujące się w odpowiedzi przychodzącej z usługi docelowej są ustawiane w odpowiedzi wychodzącej przed jej przekazaniem do punktu ProxyEndpoint.
`response.retain.headers`	Nie dotyczy	Definiuje określone nagłówki HTTP odpowiedzi, które należy ustawić w odpowiedzi wychodzącej, zanim zostanie ona przekazana do punktu końcowego serwera proxy. Aby na przykład przekazywać nagłówek `Expires`, ustaw wartość `response.retain.headers` na `Expires`. Kilka nagłówków HTTP można podać w postaci listy rozdzielanej przecinkami, np. `Expires,Set-Cookie`. Ta właściwość zastępuje właściwość `response.retain.headers.enabled`. Jeśli `response.retain.headers.enabled` ma wartość `false`, wszystkie nagłówki określone we właściwości `response.retain.headers` będą nadal ustawione w wiadomości wychodzącej.
`retain.queryparams. enabled`	`true`	Domyślnie Apigee Edge zawsze zachowuje wszystkie parametry zapytania w żądaniach wychodzących. Gdy jest ustawiona na `true`, wszystkie parametry zapytania obecne w żądaniu przychodzącym są ustawiane w żądaniu wychodzącym do usługi docelowej.
`retain.queryparams`	Nie dotyczy	Definiuje parametry zapytania, które należy ustawić w żądaniu wychodzącym. Aby na przykład uwzględnić parametr zapytania `apikey` z wiadomości żądania, ustaw `retain.queryparams` na `apikey`. Kilka parametrów zapytania można podać w postaci listy rozdzielanej przecinkami, np. `apikey,environment`. Ta właściwość zastępuje właściwość `retain.queryparams.enabled`.

Właściwości transportu ProxyEndpoint

Elementy HTTPTargetConnection ProxyEndpoint definiują zestaw właściwości transportu HTTP. Tych właściwości można używać do ustawiania konfiguracji na poziomie transportu.

Właściwości elementu ProxyEndpoint HTTPProxyConnection w taki sposób:

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

Więcej informacji o hostach wirtualnych znajdziesz w artykule Informacje o hostach wirtualnych.

Specyfikacja właściwości transportu ProxyEndpoint

Nazwa właściwości	Wartość domyślna	Opis
`X-Forwarded-For`	`false`	Gdy jest ustawiona na `true`, adres IP hosta wirtualnego jest dodawany do żądania wychodzącego jako wartość nagłówka HTTP `X-Forwarded-For`.
`request.streaming. enabled`	`false`	Domyślnie (`false`) ładunki żądań HTTP są odczytywane do bufora, a zasady, które mogą działać na ładunku, działają zgodnie z oczekiwaniami. W przypadku, gdy ładunki są większe niż rozmiar bufora (10 MB), możesz ustawić ten atrybut na `true`. Gdy `true`, ładunki żądania HTTP nie są odczytywane do bufora; są przesyłane strumieniowo w stanie niezmienionym do przepływu żądania TargetEndpoint. W takim przypadku wszystkie zasady, które działają na ładunku w przepływie żądania ProxyEndpoint, są pomijane. Zapoznaj się też z sekcją Przesyłanie żądań i odpowiedzi.
`response.streaming. enabled`	`false`	Domyślnie (`false`) ładunki odpowiedzi HTTP są odczytywane do bufora, a zasady, które mogą działać na ładunku, działają zgodnie z oczekiwaniami. W przypadku, gdy ładunki są większe niż rozmiar bufora (10 MB), możesz ustawić ten atrybut na `true`. Gdy `true`, ładunki odpowiedzi HTTP nie są odczytywane do bufora; są przesyłane do klienta w niezmienionej postaci. W tym przypadku wszystkie zasady działające na ładunku w przepływie odpowiedzi ProxyEndpoint są pomijane. Zapoznaj się też z sekcją Przesyłanie żądań i odpowiedzi.
`compression.algorithm`	Nie dotyczy	Domyślnie Apigee Edge rozpoznaje typ kompresji ustawiony dla każdej otrzymanej wiadomości. Jeśli na przykład klient przesyła żądanie korzystające z kompresji gzip, Apigee Edge przekazuje żądanie do celu z użyciem kompresji gzip. Możesz skonfigurować algorytmy kompresji, aby były stosowane bezpośrednio, ustawiając tę właściwość w punkcie końcowym TargetEndpoint lub ProxyEndpoint. Obsługiwane wartości to: gzip: zawsze wysyłaj wiadomość przy użyciu kompresji gzip deflate: zawsze wysyłaj wiadomość przy użyciu kompresji deflate none (brak): zawsze wysyłaj wiadomość bez kompresji. Zobacz też: Czy Apigee obsługuje kompresję/dekompresję za pomocą programu GZIP/deflate?
`api.timeout`	Nie dotyczy	Konfigurowanie limitu czasu dla poszczególnych serwerów proxy interfejsu API Możesz skonfigurować serwery proxy interfejsu API, nawet te z włączonym strumieniem strumieniowym, aby po określonym czasie oczekiwania miały stan `504 Gateway Timeout`. Główny przypadek użycia dotyczy klientów korzystających z serwerów proxy interfejsu API, których wykonanie trwa dłużej. Załóżmy na przykład, że określone serwery proxy muszą przekraczać limit czasu po 3 minutach. Oto jak należy używać `api.timeout`. Najpierw skonfiguruj system równoważenia obciążenia, router i procesor wiadomości tak, aby przekraczały limit czasu po 3 minutach. Następnie skonfiguruj odpowiednie serwery proxy, aby przekraczały limit czasu po 3 minutach. Określ wartość w milisekundach. np.: `<Property name="api.timeout">180000</Property>` Pamiętaj jednak, że zwiększenie limitów czasu oczekiwania może spowodować problemy z wydajnością, ponieważ wszystkie serwery proxy bez ustawienia api.timeout korzystają z nowego, wyższego systemu równoważenia obciążenia, routera i procesora wiadomości. Skonfiguruj więc inne serwery proxy interfejsu API, które nie wymagają dłuższych limitów czasu, aby używały krótszych limitów czasu. Poniższy przykład ustawia na przykład limit czasu serwera proxy interfejsu API po minucie: `<Property name="api.timeout">60000</Property>` Nie możesz ustawić tej właściwości za pomocą zmiennej. Klienci, którzy nie mogą zmieniać limitów czasu oczekiwania na Edge, mogą też skonfigurować limit czasu serwera proxy interfejsu API, o ile będzie on krótszy niż standardowy czas oczekiwania procesora wiadomości brzegowych wynoszący 57 sekund. Więcej informacji znajdziesz w artykule Konfigurowanie ustawień io.timeout.millis i api.timeout dla Edge.

Konfigurowanie ustawień io.timeout.millis i api.timeout dla Edge

W przeglądarce Edge operacje io.timeout.millis i api.timeout są powiązane. Przy każdym żądaniu wysyłanym do serwera proxy interfejsu API:

Router wysyła wartość czasu oczekiwania do procesora wiadomości. Wartość limitu czasu routera to albo wartość proxy_read_timeout ustawiona przez hosta wirtualnego, który obsługuje żądanie, albo domyślny limit czasu wynoszący 57 sekund.
Następnie procesor wiadomości ustawia api.timeout:
1. Jeśli zasada api.timeout nie jest ustawiona na poziomie serwera proxy, ustaw limit czasu routera.
2. Jeśli api.timeout jest ustawiony na poziomie serwera proxy, ustaw go w procesorze wiadomości na mniejszą wartość limitu czasu oczekiwania routera lub wartość api.timeout.
Wartość api.timeout określa maksymalny czas wykonania serwera proxy interfejsu API od żądania do interfejsu API do odpowiedzi.

Po wykonaniu każdej zasady w serwerze proxy interfejsu API lub przed wysłaniem żądania do docelowego punktu końcowego przez podmiot przetwarzający wiadomości (api.timeout – czas, jaki upłynął od rozpoczęcia żądania). Jeśli wartość jest mniejsza niż 0, oznacza to, że upłynął maksymalny czas obsługi żądania, a procesor wiadomości zwraca wartość 504.
Wartość io.timeout.millis określa maksymalny czas, jaki musi na odpowiedź docelowy punkt końcowy.

Przed nawiązaniem połączenia z docelowym punktem końcowym podmiot przetwarzający wiadomości określa mniejszą z tych wartości (api.timeout – czas, jaki upłynął od rozpoczęcia żądania) oraz io.timeout.millis. Następnie ustawia tę wartość dla parametru io.timeout.millis.
- Jeśli podczas zapisywania żądania HTTP limit czasu zostanie przekroczony, zwracany jest kod 408, Request Timeout.
- Jeśli podczas odczytu odpowiedzi HTTP minie limit czasu, zwracana jest wartość 504, Gateway Timeout.

Informacje o obiekcie ScriptTarget dla aplikacji Node.js

Element ScriptTarget służy do integrowania aplikacji Node.js z serwerem proxy. Informacje o korzystaniu z Node.js i ScriptTarget znajdziesz w tych artykułach:

Informacje o punktach końcowych HostedTarget

Pusty tag <HostedTarget/> sprawia, że przeglądarka Edge ma używać jako środowiska docelowego aplikacji Node.js wdrożonej w środowisku hostowanych obiektów docelowych. Więcej informacji znajdziesz w artykule Omówienie hostowanych celów.