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

Wyświetlasz dokumentację Apigee Edge.
Przejdź do dokumentacji Apigee X. info

Z tego artykułu dowiesz się, jak ustawić właściwości transportu, które można skonfigurować w TargetEndpoint i ProxyEndpoint , aby kontrolować zachowanie związane z przesyłaniem wiadomości i połączeniami. Pełne informacje o konfiguracji TargetEndpoint i ProxyEndpoint znajdziesz w artykule Konfiguracja serwera proxy interfejsu API.

Właściwości transportu TargetEndpoint

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

Właściwości są ustawiane w elementach HTTPTargetConnection TargetEndpoint w sposób pokazany poniżej:

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

Nazwa właściwości Wartość domyślna Opis
keepalive.timeout.millis 60000 Czas oczekiwania na nieaktywne połączenie docelowe w puli połączeń. Jeśli połączenie w puli jest nieaktywne dłużej niż określony limit, zostanie zamknięte.
connect.timeout.millis

3000

Czas oczekiwania na połączenie docelowe. Jeśli wystąpi przekroczenie limitu czasu połączenia, Edge zwróci kod stanu HTTP 503. W niektórych przypadkach, gdy w definicji TargetServer używany jest element LoadBalancer i wystąpi przekroczenie limitu czasu, może zostać zwrócony kod stanu HTTP 504.

io.timeout.millis 55000

Jeśli przez określony czas (w milisekundach) nie ma danych do odczytania lub jeśli gniazdo jest niegotowe do zapisu danych przez określony czas (w milisekundach), transakcja jest traktowana jako przekroczenie limitu czasu.

  • Jeśli podczas zapisywania żądania HTTP nastąpi przekroczenie limitu czasu, zwracany jest kod 408, Request Timeout.
  • Jeśli podczas odczytywania odpowiedzi HTTP nastąpi przekroczenie limitu czasu, 504, Gateway Timeout jest zwracany.

Ta wartość powinna być zawsze mniejsza niż wartość właściwości proxy_read_timeout hosta wirtualnego .

Ta wartość powinna być mniejsza niż czas oczekiwania używany przez router do komunikacji z procesorem komunikatów. Więcej informacji znajdziesz w artykule Konfigurowanie czasu oczekiwania routera.

Więcej informacji znajdziesz w artykule Ustawianie io.timeout.millis i api.timeout w Edge.
supports.http10 true Jeśli ta wartość to true i klient wysyła żądanie 1.0, do celu również wysyłane jest żądanie 1.0 żądanie. W przeciwnym razie do celu wysyłane jest żądanie 1.1.
supports.http11 true Jeśli ta wartość to true i klient wysyła żądanie 1.1, do celu również wysyłane jest żądanie 1.1 . W przeciwnym razie do celu wysyłane jest żądanie 1.0.
use.proxy true Jeśli ta wartość jest ustawiona na true i konfiguracje serwera proxy są określone w http.properties (tylko w przypadku wdrożeń lokalnych), połączenia docelowe są ustawione tak, aby korzystać z określonego serwera proxy.
use.proxy.tunneling true Jeśli ta wartość jest ustawiona na 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ć z określonego tunelu. Jeśli cel używa protokołu 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 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 w żądaniu wychodzącym. 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 mogą działać na ładunku, działają zgodnie z oczekiwaniami. Jeśli ładunki są większe niż rozmiar bufora (10 MB), możesz ustawić ten atrybut na true. Gdy wartość to true, ładunki żądań HTTP nie są odczytywane do bufora. Są one przesyłane strumieniowo do punktu końcowego docelowego. W takim przypadku wszystkie zasady, które działają na ładunku w przepływie żądania TargetEndpoint, są pomijane. Zobacz też Przesyłanie strumieniowe żą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. Jeśli ładunki są większe niż rozmiar bufora (10 MB), możesz ustawić ten atrybut na true. Gdy wartość to true, ładunki odpowiedzi HTTP nie są odczytywane do bufora. Są one przesyłane strumieniowo do przepływu odpowiedzi ProxyEndpoint. W takim przypadku wszystkie zasady, które działają na ładunku w przepływie odpowiedzi TargetEndpoint, są pomijane. Zobacz też Przesyłanie strumieniowe żądań i odpowiedzi.
success.codes Nie dotyczy

Domyślnie Apigee Edge traktuje kod HTTP 4XX lub 5XX jako błąd, a kod HTTP 1XX, 2XX, 3XX jako sukces. Ta właściwość umożliwia wyraźne zdefiniowanie kodów sukcesu. Na przykład, 2XX, 1XX, 505 traktuje wszystkie kody odpowiedzi HTTP 100, 200 i 505 jako sukces.

Ustawienie tej właściwości powoduje zastąpienie wartości domyślnych. Jeśli więc chcesz dodać kod HTTP 400 do listy domyślnych kodów sukcesu, ustaw tę właściwość w ten sposób:

<Property name="success.codes">1XX,2XX,3XX,400</Property>

Jeśli chcesz, aby tylko kod HTTP 400 był traktowany jako kod sukcesu, ustaw tę właściwość w ten sposób:

<Property name="success.codes">400</Property>

Ustawiając kod HTTP 400 jako jedyny kod sukcesu, kody 1XX, 2XX, i 3XX są traktowane jako błędy.
compression.algorithm Nie dotyczy Domyślnie Apigee Edge przekazuje żądania do celu, używając tego samego typu kompresji co żądanie klienta. Jeśli żądanie zostanie odebrane od klienta, np. przy użyciu kompresji gzip Apigee Edge przekazuje żądanie do celu przy użyciu kompresji gzip. Jeśli odpowiedź otrzymana z celu używa kompresji deflate, Apigee Edge przekazuje odpowiedź do klienta przy użyciu kompresji 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: zawsze wysyłaj wiadomość bez kompresji

Zobacz też: Czy Apigee obsługuje kompresję/dekompresję za pomocą kompresji GZIP/deflate?
request.retain.headers.
enabled		 true Domyślnie Apigee Edge zawsze zachowuje wszystkie nagłówki HTTP w wiadomościach wychodzących. Gdy ta wartość jest ustawiona na true, wszystkie nagłówki HTTP obecne w żądaniu przychodzącym są ustawiane w żądaniu wychodzącym.
request.retain.headers Nie dotyczy Określa konkretne nagłówki HTTP z żądania, które powinny być ustawione w żądaniu wychodzącym do usługi docelowej. Aby na przykład przekazać User-Agent nagłówek, ustaw wartość request.retain.headers na User-Agent. Wiele nagłówków HTTP jest określonych jako lista rozdzielona przecinkami, np. User-Agent,Referer,Accept-Language. Ta właściwość zastępuje request.retain.headers.enabled. Jeśli request.retain.headers.enabled jest ustawiona na false, wszystkie nagłówki określone we właściwości request.retain.headers są nadal ustawiane 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 ta wartość jest ustawiona na true, wszystkie nagłówki HTTP obecne w odpowiedzi przychodzącej z usługi docelowej są ustawiane w odpowiedzi wychodzącej, zanim zostanie ona przekazana do ProxyEndpoint.
response.retain.headers Nie dotyczy Określa konkretne nagłówki HTTP z odpowiedzi, które powinny być ustawione w odpowiedzi wychodzącej zanim zostanie ona przekazana do ProxyEndpoint. Aby na przykład przekazać nagłówek Expires, ustaw wartość response.retain.headers na Expires. Wiele nagłówków HTTP jest określonych jako lista rozdzielona przecinkami, np. Expires,Set-Cookie. Ta właściwość zastępuje response.retain.headers.enabled. Jeśli response.retain.headers.enabled jest ustawiona na false, wszystkie nagłówki określone we właściwości response.retain.headers są nadal ustawiane w wiadomości wychodzącej.
retain.queryparams.
enabled		 true Domyślnie Apigee Edge zawsze zachowuje wszystkie parametry zapytania w żądaniach wychodzących. Gdy ustawiono na true, wszystkie parametry zapytania obecne w żądaniu przychodzącym są ustawiane w żądaniu wychodzącym do usługi docelowej.
retain.queryparams Nie dotyczy Określa konkretne parametry zapytania, które mają być ustawione w żądaniu wychodzącym. Aby na przykład uwzględnić parametr zapytania apikey z wiadomości żądania, ustaw retain.queryparams na apikey. Wiele parametrów zapytania jest określonych jako lista rozdzielona przecinkami, np. apikey,environment. Ta właściwość zastępuje retain.queryparams.enabled.

Właściwości transportu ProxyEndpoint

Elementy HTTPTargetConnection ProxyEndpoint określają zestaw właściwości transportu HTTP. Za pomocą tych właściwości możesz ustawić konfiguracje na poziomie transportu.

Właściwości są ustawiane w elementach HTTPProxyConnection ProxyEndpoint 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 o hostach wirtualnych znajdziesz w artykule Hosty wirtualne.

Specyfikacja właściwości transportu ProxyEndpoint

Nazwa właściwości Wartość domyślna Opis
X-Forwarded-For false Gdy ta wartość 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. Jeśli ładunki są większe niż rozmiar bufora (10 MB), możesz ustawić ten atrybut na true. Gdy wartość to true, ładunki żądań HTTP nie są odczytywane do bufora. Są one przesyłane strumieniowo do przepływu żądania TargetEndpoint. W takim przypadku wszystkie zasady, które działają na ładunku w przepływie żądania ProxyEndpoint, są pomijane. Zobacz też Przesyłanie strumieniowe żą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. Jeśli ładunki są większe niż rozmiar bufora (10 MB), możesz ustawić ten atrybut na true. Gdy wartość to true, ładunki odpowiedzi HTTP nie są odczytywane do bufora. Są one przesyłane strumieniowo do klienta. W takim przypadku wszystkie zasady, które działają na ładunku w przepływie odpowiedzi ProxyEndpoint, są pomijane. Zobacz też Przesyłanie strumieniowe żądań i odpowiedzi.
compression.algorithm Nie dotyczy

Domyślnie Apigee Edge uwzględnia typ kompresji ustawiony dla każdej otrzymanej wiadomości. Jeśli na przykład klient przesyła żądanie, które używa kompresji gzip, Apigee Edge przekazuje żądanie do celu przy użyciu kompresji gzip. Możesz skonfigurować algorytmy kompresji , które mają być stosowane w sposób jawny, ustawiając tę właściwość w TargetEndpoint lub ProxyEndpoint. 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: zawsze wysyłaj wiadomość bez kompresji

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

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

Możesz skonfigurować serwery proxy interfejsu API, nawet te z przesyłaniem strumieniowym włączonym, tak aby po określonym czasie przekraczały limit czasu ze stanem 504 Gateway Timeout. Głównym przypadkiem użycia jest sytuacja, gdy klienci mają serwery proxy interfejsu API , których wykonanie trwa dłużej. Załóżmy na przykład, że chcesz, aby określone serwery proxy przekraczały limit czasu po 3 minutach. Oto jak używać api.timeout.

  1. Najpierw skonfiguruj moduł równoważenia obciążenia, router i procesor wiadomości tak, aby przekraczały limit czasu po 3 minutach.
  2. Następnie skonfiguruj odpowiednie serwery proxy tak, aby przekraczały limit czasu po 3 minutach. Określ wartość w milisekundach. Na przykład: <Property name="api.timeout">180000</Property>
  3. Pamiętaj jednak, że zwiększenie limitów czasu systemu może spowodować problemy z wydajnością, ponieważ wszystkie serwery proxy bez ustawienia api.timeout będą używać nowych, dłuższych limitów czasu modułu 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, tak aby używały krótszych limitów czasu. Na przykład poniższy kod ustawia serwer proxy interfejsu API tak, aby przekraczał limit czasu po 1 minucie:
    <Property name="api.timeout">60000</Property>

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

Klienci, którzy nie mogą modyfikować limitów czasu Edge, mogą też skonfigurować limit czasu serwera proxy interfejsu API , o ile jest on krótszy niż standardowy limit czasu procesora wiadomości Edge wynoszący 57 sekund.

Więcej informacji znajdziesz w artykule Ustawianie io.timeout.millis i api.timeout w Edge.

Ustawianie io.timeout.millis i api.timeout w Edge

W Edge działanie io.timeout.millis i api.timeout jest powiązane. W przypadku każdego żądania do serwera proxy interfejsu API:

  1. Router wysyła wartość limitu czasu do procesora komunikatów. Wartość limitu czasu routera to wartość proxy_read_timeout ustawiona przez hosta wirtualnego obsługującego żądanie, lub domyślna wartość limitu czasu wynosząca 57 sekund.
  2. Procesor komunikatów ustawia następnie api.timeout:
    1. Jeśli api.timeout nie jest ustawiony na poziomie serwera proxy, ustaw go na limit czasu routera.
    2. Jeśli api.timeout jest ustawiony na poziomie serwera proxy, ustaw go w procesorze komunikatów na mniejszą z wartości limitu czasu routera lub api.timeout.

  3. Wartość api.timeout określa maksymalny czas, jaki proxy interfejsu API ma na wykonanie od żądania do interfejsu API do odpowiedzi.

    Po wykonaniu każdej zasady w proxy interfejsu API, lub przed wysłaniem żądania do punktu końcowego docelowego przez procesor komunikatów, procesor komunikatów oblicza wartość (api.timeout – czas, który upłynął od początku żądania). Jeśli wartość jest mniejsza od zera, oznacza to, że upłynął maksymalny czas obsługi żądania, a procesor komunikatów zwraca kod 504.

  4. Wartość io.timeout.millis określa maksymalny czas, jaki punkt końcowy docelowy ma na odpowiedź.

    Przed połączeniem z punktem końcowym docelowym procesor komunikatów określa mniejszą z wartości (api.timeout – czas, który upłynął od początku żądania) i io.timeout.millis. Następnie ustawia io.timeout.millis na tę wartość.

    • Jeśli podczas zapisywania żądania HTTP nastąpi przekroczenie limitu czasu, zwracany jest kod 408, Request Timeout.
    • Jeśli podczas odczytywania odpowiedzi HTTP nastąpi przekroczenie limitu czasu, zwracany jest kod 504, Gateway Timeout.

Informacje o ScriptTarget w przypadku aplikacji Node.js

Element ScriptTarget służy do integrowania aplikacji Node.js z serwerem proxy. Więcej informacji o używaniu Node.js i ScriptTarget znajdziesz w tych artykułach:

Informacje o punktach końcowych HostedTarget

Pusty tag <HostedTarget/> informuje Edge, że ma używać jako celu aplikacji Node.js wdrożonej w środowisku Hosted Targets. Więcej informacji znajdziesz w artykule Omówienie Hosted Targets.