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

Przeglądasz dokumentację Apigee Edge.
Przejdź do Dokumentacja Apigee X. informacje.

W tym temacie opisujemy właściwości transportu, które można ustawić w docelowych punktach końcowych i ProxyEndpoint. które pozwalają kontrolować przesyłanie wiadomości i zachowanie połączenia. Pełne pokrycie docelowego punktu końcowego i konfiguracji ProxyEndpoint znajdziesz w dokumentacji konfiguracji serwera proxy interfejsu API.

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

Element HTTPTargetConnection w konfiguracjach TargetEndpoint definiuje zbiór HTTP właściwości transportu. Możesz użyć tych właściwości do skonfigurowania konfiguracji na poziomie transportu.

Właściwości są ustawiane 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>

Właściwość transportu docelowego punktu końcowego Specyfikacja

Nazwa właściwości Wartość domyślna Opis
keepalive.timeout.millis 60000 Limit czasu bezczynności połączenia docelowego w puli połączeń. Jeśli połączenie w puli jest bezczynne powyżej określonego limitu, połączenie jest zamknięto.
connect.timeout.millis

3000

Upłynął limit czasu połączenia docelowego. Edge zwraca kod stanu HTTP 503, jeśli połączenie jest aktywne gdy minie czas oczekiwania. W niektórych przypadkach, gdy LoadBalancer może zostać zwrócony kod stanu HTTP 504 jest używany w definicji serwera docelowego. po przekroczeniu limitu czasu.

io.timeout.millis 55000

Jeśli nie ma danych do odczytu przez określoną liczbę milisekund lub jeśli gniazdo nie jest gotowy do zapisywania danych przez określoną liczbę milisekund, transakcja jest traktowany jako przekroczenie limitu czasu.

  • Jeśli podczas zapisywania żądania HTTP zostanie przekroczony limit czasu, 408, Request Timeout .
  • Jeśli podczas odczytu odpowiedzi HTTP przekroczono limit czasu, 504, Gateway Timeout .

Ta wartość powinna być zawsze 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 komunikowania się z procesorem wiadomości. Zapoznaj się z sekcją Konfigurowanie limitu czasu routera dla tych informacji: i innych.

Zobacz Ustawianie wartości io.timeout.millis i api.timeout dla Edge. aby dowiedzieć się więcej.
supports.http10 true Jeśli ma wartość true, a klient wysyła żądanie 1.0, do celu też jest wysyłana wartość 1.0 użytkownika. W przeciwnym razie do elementu docelowego wysyłane jest żądanie 1.1.
supports.http11 true Jeśli ma wartość true, a klient wyśle żądanie 1.1, do celu także zostanie wysłany kod 1.1 W przeciwnym razie do elementu docelowego zostanie wysłane żądanie 1.0.
use.proxy true Jeśli ustawiona jest wartość true, a konfiguracje proxy są określone w http.properties (tylko wdrożenia lokalne), a następnie połączenia docelowe są skonfigurowane do używania określonego serwera proxy.
use.proxy.tunneling true Jeśli ta opcja jest ustawiona na true, a konfiguracje serwerów proxy są określone w polu http.properties (tylko wdrożenia lokalne), a następnie cel są skonfigurowane tak, aby korzystały z określonego tunelu. Jeśli środowisko docelowe używa TLS/SSL, jest ignorowana, a komunikat jest zawsze wysyłany przez tunel.
enable.method.override false W przypadku określonej metody HTTP ustawia nagłówek X-HTTP-Method-Override na żądania wychodzącego do usługi docelowej. Na 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 na żądania wychodzącego. Na 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 może działać na ładunku zgodnie z oczekiwaniami. W przypadkach, gdy ładunki są większe niż rozmiaru bufora (10 MB), możesz ustawić tę wartość dla atrybutu true. Gdy zasada jest true, ładunki żądań HTTP nie są odczytywane do bufora. są jest przesyłana strumieniowo w niezmienionej formie do docelowego punktu końcowego. W tym przypadku wszystkie zasady działające na ładunek w przepływie żądania TargetEndpoint jest pomijany. Zobacz też Strumieniowe przesyłanie żądań i odpowiedzi.
response.streaming.enabled false

Domyślnie (false) ładunki odpowiedzi HTTP są odczytywane do bufora, a zasady, które może działać na ładunku zgodnie z oczekiwaniami. W przypadkach, gdy ładunki są większe niż rozmiaru bufora (10 MB), możesz ustawić tę wartość dla atrybutu true. Jeśli zasada jest ustawiona na true, ładunki odpowiedzi HTTP nie są odczytywane do bufora. są jest przesyłana strumieniowo w niezmienionej formie do przepływu odpowiedzi ProxyEndpoint. W tym przypadku wszelkie zasady, które na ładunku w przepływie odpowiedzi TargetEndpoint są pomijane. Zobacz też Żądania strumieniowania odpowiedzi.
success.codes Nie dotyczy

Domyślnie Apigee Edge traktuje kod HTTP 4XX lub 5XX jako błędy i traktuje kod HTTP 1XX, 2XX, 3XX. Ta właściwość umożliwia jednoznaczne zdefiniowanie kodów powodzenia w przypadku na przykład kod 2XX, 1XX, 505 traktuje wszystkie kody odpowiedzi HTTP 100, 200 i 505 jako .

Ustawienie tej właściwości powoduje zastąpienie wartości domyślnych. Jeśli więc chcesz dodać Kod HTTP 400 na listę domyślnych kodów powodzenia, ustaw tę właściwość jako:

&lt;Property name="success.codes">1XX,2XX,3XX 400</Usługa>

Jeśli chcesz, aby jako kod powodzenia był traktowany tylko kod HTTP 400, ustaw właściwość jako:

&lt;Property name="success.codes">400</Właściwość>

Jeśli ustawisz kod HTTP 400 jako jedyny kod powodzenia, kody 1XX, 2XX i 3XX zostaną traktowanych jako niepowodzenia.
compression.algorithm Nie dotyczy Domyślnie Apigee Edge przekierowuje żądania do celu przy użyciu tego samego typu kompresji. zgodnie z prośbą klienta. Jeśli żądanie zostało odebrane od klienta za pomocą np. programu gzip , a potem Apigee Edge przekaże żądanie do celu przy użyciu kompresji gzip. Jeśli odpowiedź otrzymana z celu używa deflate, a Apigee Edge przekazuje odpowiedź do za pomocą Deflate. Obsługiwane wartości to:
  • gzip: zawsze wysyłaj wiadomość przy użyciu kompresji gzip
  • deflate: zawsze wysyłaj wiadomości przy użyciu kompresji deflate (deflate).
  • none:wysyłaj wiadomości zawsze bez kompresji.

Zobacz też: Czy Apigee obsługuje kompresję i dekompresję za pomocą GZIP / dekompresji?
request.retain.headers.
enabled		 true Domyślnie Apigee Edge zawsze zachowuje wszystkie nagłówki HTTP w wiadomościach wychodzących. Po ustawieniu na true, wszystkie nagłówki HTTP występujące w żądaniu przychodzącym są ustawione na stronie żądania wychodzącego.
request.retain.headers Nie dotyczy Definiuje konkretne nagłówki HTTP z żądania, które powinny być ustawione dla ruchu wychodzącego do usługi docelowej. Na przykład, aby przekazywać User-Agent nagłówek, ustaw wartość request.retain.headers na User-Agent. Możesz podać wiele nagłówków HTTP w postaci listy rozdzielanej przecinkami, na przykład User-Agent,Referer,Accept-Language Ta usługa zastępuje request.retain.headers.enabled Jeśli request.retain.headers.enabled jest ustawiona na false, wszystkie nagłówki podane w Właściwość request.retain.headers jest nadal ustawiona 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. Po ustawieniu do true, wszystkie nagłówki HTTP obecne w odpowiedzi przychodzącej z celu są ustawiane w odpowiedzi wychodzącej przed przekazaniem jej do punktu końcowego ProxyEndpoint.
response.retain.headers Nie dotyczy Definiuje konkretne nagłówki HTTP z odpowiedzi, które powinny być ustawione w danych wychodzących przed przekazaniem jej do punktu końcowego serwera proxy. Na przykład, aby przekazywać parametr Nagłówek Expires, ustaw wartość response.retain.headers na Expires Nagłówki HTTP należy podać w postaci listy rozdzielanej przecinkami, przykład: Expires,Set-Cookie. Ta usługa zastępuje response.retain.headers.enabled Jeśli Pole response.retain.headers.enabled jest ustawione na false, wszystkie nagłówki określone we właściwości response.retain.headers są nadal ustawione na wiadomości wychodzące.
retain.queryparams.
enabled		 true Domyślnie Apigee Edge zawsze zachowuje wszystkie parametry zapytań w żądaniach wychodzących. Kiedy ma wartość true, wszystkie parametry zapytania występujące w żądaniu przychodzącym są ustawione na żądania wychodzącego do usługi docelowej.
retain.queryparams Nie dotyczy Definiuje konkretne parametry zapytania, które należy ustawić w żądaniu wychodzącym. Aby na przykład: dołącz parametr zapytania apikey z komunikatu z żądaniem, ustaw retain.queryparams do apikey. Zastosowanie kilku parametrów zapytania podana w postaci listy rozdzielanej przecinkami, np. apikey,environment. Ten zastępuje retain.queryparams.enabled.

Właściwości transportu punktu końcowego serwera proxy

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

Właściwości są ustawiane w elementach ProxyEndpoint HTTPProxyConnection w ten 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 na temat hostów wirtualnych znajdziesz w artykule Informacje o hostach wirtualnych.

Właściwość transportu ProxyEndpoint Specyfikacja

Nazwa właściwości Wartość domyślna Opis
X-Forwarded-For false Jeśli zasada ma wartość true, adres IP hosta wirtualnego jest dodawany do żądania wychodzącego jako 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 zgodnie z oczekiwaniami. W przypadkach, gdy ładunki są większe niż (10 MB), możesz ustawić dla atrybutu true. Gdy zasada jest true, ładunki żądań HTTP nie są odczytywane do bufora. są jest przesyłana strumieniowo w niezmienionej formie do przepływu żądania TargetEndpoint. W tym przypadku wszystkie zasady działające dla ładunku w procesie żądania ProxyEndpoint są pomijane. Zobacz też Strumieniowe przesyłanie żądań i odpowiedzi.
response.streaming.
enabled		 false Domyślnie (false) ładunki odpowiedzi HTTP są odczytywane do bufora, a zasady, które może działać na ładunku zgodnie z oczekiwaniami. W przypadkach, gdy ładunki są większe niż rozmiaru bufora (10 MB), możesz ustawić tę wartość dla atrybutu true. Jeśli zasada jest ustawiona na true, ładunki odpowiedzi HTTP nie są odczytywane do bufora. są jest przesyłane do klienta w takiej postaci, w jakiej jest. W tym przypadku wszystkie zasady, które działają na ładunku w Przepływ odpowiedzi punktu końcowego serwera proxy jest pomijany. Zobacz też Strumieniowe przesyłanie żądań i odpowiedzi.
compression.algorithm Nie dotyczy

Domyślnie Apigee Edge obsługuje typ kompresji ustawiony dla każdej odebranej wiadomości. Dla: Jeśli na przykład klient przesyła żądanie wykorzystujące kompresję gzip, Apigee Edge przekierowuje żądanie do celu przy użyciu kompresji gzip. Możesz skonfigurować kompresję do zastosowania wprost przez ustawienie tej właściwości dla elementu TargetEndpoint lub ProxyEndpoint. Obsługiwane wartości to:

  • gzip: zawsze wysyłaj wiadomość przy użyciu kompresji gzip
  • deflate: zawsze wysyłaj wiadomości przy użyciu kompresji deflate (deflate).
  • none:wysyłaj wiadomości zawsze bez kompresji.

Zobacz też: Czy Apigee obsługuje kompresję i dekompresję za pomocą GZIP / dekompresji?
api.timeout Nie dotyczy

Konfigurowanie czasu oczekiwania dla poszczególnych serwerów proxy interfejsu API

Możesz skonfigurować serwery proxy interfejsów API, nawet jeśli włączone strumieniowe przesyłanie danych, na przekroczenie limitu czasu po upływie określonego czasu ze stanem 504 Gateway Timeout. Podstawowy przypadek użycia jest przeznaczony dla klientów, którzy korzystają z serwerów proxy interfejsów API których realizacja trwa dłużej. Załóżmy na przykład, że potrzebujesz określonych serwerów proxy, aby osiągnąć limit czasu o 3 godzinach. min. Poniżej opisujemy, jak możesz użyć usługi api.timeout.

  1. Po pierwsze, skonfiguruj system równoważenia obciążenia, router i procesor komunikatów, przekroczy limit czasu po trzech minutach.
  2. Następnie skonfiguruj odpowiednie serwery proxy tak, aby przekroczyły limit czasu po 3 minutach. Podaj wartość w milisekund. Na przykład: <Property name="api.timeout">180000</Property>
  3. Pamiętaj jednak, że wydłużenie czasu oczekiwania systemu może spowodować problemy z wydajnością, ponieważ wszystkie serwery proxy bez ustawienia api.timeout używają nowego, większego obciążenia w przypadku systemów równoważenia obciążenia, routera i procesora komunikatów. Skonfiguruj więc inne serwery proxy interfejsów API, nie wymagają dłuższych limitów czasu oczekiwania Na przykład poniższy tag ustawia wartość Serwer proxy interfejsu API zostanie przekroczony po 1 minucie:
    <Property name="api.timeout">60000</Property>

Nie można ustawić tej właściwości za pomocą zmiennej.

Klienci, którzy nie mogą zmienić limitów czasu oczekiwania na krawędziach, mogą też skonfigurować serwer proxy interfejsu API limit czasu, o ile limit ten jest krótszy niż standardowy procesor wiadomości Edge po 57 sekundach.

Zobacz Ustawianie wartości io.timeout.millis i api.timeout dla Edge. aby dowiedzieć się więcej.

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

Na Edge działanie io.timeout.millis i api.timeout są powiązane. Przy każdym żądaniu do serwera proxy interfejsu API:

  1. Router wysyła wartość limitu czasu do procesora komunikatów. Wartość czasu oczekiwania routera to wartość parametru proxy_read_timeout ustawiona przez hosta wirtualnego który obsługuje żądanie, albo domyślny limit czasu to 57 sekund.
  2. Następnie procesor wiadomości ustawia api.timeout:
    1. Jeśli zasada api.timeout nie jest ustawiona na poziomie serwera proxy, ustaw limit czasu oczekiwania routera.
    2. Jeśli api.timeout jest ustawiony na poziomie serwera proxy, w procesorze wiadomości ustaw go na mniejsza wartość limitu czasu routera lub wartość api.timeout.

  3. Wartość api.timeout określa maksymalny czas działania serwera proxy interfejsu API który ma być wykonywany od żądania API do odpowiedzi.

    Po wykonaniu każdej zasady na serwerze proxy interfejsu API lub przed wysłaniem żądania do docelowego punktu końcowego przez procesor wiadomości, obliczany przez procesor wiadomości (api.timeout – czas, który upłynął od rozpoczęcia żądania). Jeśli wartość jest mniejsza od zera, oznacza to, że upłynął maksymalny czas obsługi żądania i procesor wiadomości zwraca wartość 504.

  4. Wartość io.timeout.millis określa maksymalny czas, przez jaki docelowy punkt końcowy musi zareagować.

    Przed nawiązaniem połączenia z docelowym punktem końcowym procesor wiadomości określa mniejszą z (api.timeout – czas, który upłynął od rozpoczęcia żądania) i io.timeout.millis. Następnie ustawia tę wartość w polu io.timeout.millis.

    • Jeśli podczas zapisywania żądania HTTP zostanie przekroczony limit czasu, 408, Request Timeout .
    • Jeśli podczas odczytu odpowiedzi HTTP przekroczono limit czasu, 504, Gateway Timeout .

Informacje o ScriptTarget dla aplikacji Node.js

Element ScriptTarget służy do integracji aplikacji Node.js z serwerem proxy. Dla: informacje o korzystaniu z Node.js i ScriptTarget znajdziesz tutaj:

Informacje o punktach końcowych HostedTarget

Pusty tag <HostedTarget/> informuje przeglądarkę Edge, aby używała środowiska docelowego Node.js aplikacja wdrożona w środowisku hostowanych celów. Więcej informacji: Omówienie hostowanych celów.