Referenz für Endpunktattribute

<ph type="x-smartling-placeholder"></ph> Sie sehen die Dokumentation zu Apigee Edge.
Gehen Sie zur Apigee X-Dokumentation. Weitere Informationen

In diesem Thema werden Transportattributen beschrieben, die in TargetEndpoint- und ProxyEndpoint-Konfigurationen festgelegt werden können, um das Nachrichten- und Verbindungsverhalten zu steuern. Weitere Informationen zur TargetEndpoint- und ProxyEndpoint-Konfiguration finden Sie in der Referenz zur API-Proxykonfiguration.

Zielendpunkt-Transportattribute

Das Element "HTTPTargetConnection" in TargetEndpoint-Konfigurationen definiert eine Reihe von HTTP-Transportattributen. Sie können diese Attribute verwenden, um Konfigurationen auf Transportebene festzulegen.

Attribute werden für TargetEndpoint HTTPTargetConnection-Elemente festgelegt, wie unten dargestellt:

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

Property-Name Standardwert Beschreibung
keepalive.timeout.millis 60000 Zeitlimit bei Inaktivität für die Zielverbindung im Verbindungspool. Wenn die Verbindung im Pool über das angegebene Limit hinaus inaktiv ist, wird die Verbindung beendet.
connect.timeout.millis

3000

Zeitlimit für Zielverbindung. Edge gibt einen HTTP-503-Statuscode zurück, wenn eine Verbindung eine Zeitüberschreitung auftritt. In einigen Fällen wird ein HTTP 504-Statuscode zurückgegeben, wenn LoadBalancer wird in der TargetServer-Definition verwendet und es tritt eine Zeitüberschreitung auf.

io.timeout.millis 55000

Wenn für die angegebene Anzahl von Millisekunden keine Daten zum Lesen vorhanden sind oder der Socket nicht bereit ist, Daten für die angegebene Anzahl von Millisekunden zu schreiben, wird die Transaktion als Zeitüberschreitung behandelt.

  • Wenn beim Schreiben der HTTP-Anfrage eine Zeitüberschreitung auftritt, wird 408, Request Timeout zurückgegeben.
  • Wenn beim Lesen der HTTP-Antwort eine Zeitüberschreitung auftritt, wird 504, Gateway Timeout zurückgegeben.

Dieser Wert sollte immer kleiner als der Wert des Attributs proxy_read_timeout des virtuellen Hosts sein.

Dieser Wert sollte kleiner sein als das vom Router für die Kommunikation mit dem Message Processor. Weitere Informationen finden Sie unter Router-Zeitlimit konfigurieren für mehr.

Weitere Informationen finden Sie unter io.timeout.millis und api.timeout für Edge festlegen. finden Sie weitere Informationen.
supports.http10 true Wenn dies true ist und der Client eine Anfrage mit dem Wert 1.0 sendet, wird am Ziel ebenfalls der Wert 1.0 gesendet. Andernfalls wird die 1.1-Anfrage an das Ziel gesendet.
supports.http11 true Wenn dies true ist und der Client eine Anfrage des Typs 1.1 sendet, erhält das Ziel ebenfalls den Wert 1.1. -Anforderung, andernfalls wird eine 1.0-Anfrage an das Ziel gesendet.
use.proxy true Wenn true festgelegt ist und Proxykonfigurationen in http.properties angegeben werden (nur lokale Bereitstellungen), werden Zielverbindungen so eingerichtet, dass der angegebene Proxy verwendet wird.
use.proxy.tunneling true Wenn true festgelegt ist und Proxykonfigurationen in http.properties angegeben werden (nur lokale Bereitstellungen), werden Zielverbindungen so eingerichtet, dass der angegebene Tunnel verwendet wird. Wenn das Ziel TLS/SSL verwendet, wird dieses Attribut ignoriert und die Nachricht immer über einen Tunnel gesendet.
enable.method.override false Legt für die angegebene HTTP-Methode einen X-HTTP-Method-Override-Header für die ausgehende Anfrage an den Zieldienst fest. z. B. <Property name="GET.override.method">POST</Property>.
*.override.method – Legt für die angegebene HTTP-Methode einen X-HTTP-Method-Override-Header für die ausgehende Anfrage fest. z. B. <Property name="GET.override.method">POST</Property>.
request.streaming.enabled false

Standardmäßig (false) werden HTTP-Anfragenutzlasten in einen Zwischenspeicher eingelesen und Richtlinien, die wie erwartet mit der Nutzlast arbeiten. In Fällen, in denen die Nutzlast größer ist als der Puffergröße (10 MB) haben, können Sie auf true. Wenn true, werden die Nutzlasten von HTTP-Anfragen nicht in einen Zwischenspeicher gelesen. sie sind unverändert an den Zielendpunkt gestreamt werden. In diesem Fall werden alle Richtlinien, die auf die Nutzlast im TargetEndpoint-Anfrageablauf angewendet werden, umgangen. Siehe auch Streaminganfragen und -antworten.
response.streaming.enabled false

Standardmäßig (false) werden Nutzlasten von HTTP-Antworten in einen Zwischenspeicher eingelesen und Richtlinien, die wie erwartet mit der Nutzlast arbeiten. In Fällen, in denen die Nutzlast größer ist als der Puffergröße (10 MB) haben, können Sie auf true. Wenn true, werden die Nutzlasten von HTTP-Antworten nicht in einen Zwischenspeicher gelesen. sie sind unverändert an den ProxyEndpoint-Antwortablauf gestreamt werden. In diesem Fall werden alle Richtlinien, die an der Nutzlast des TargetEndpoint-Antwortablaufs arbeiten, umgangen. Siehe auch Streaminganfragen und Antworten.
success.codes –

Standardmäßig behandelt Apigee Edge den HTTP-Code 4XX oder 5XX als Fehler und behandelt HTTP-Code. 1XX, 2XX, 3XX als erfolgreich abgeschlossen. Diese Eigenschaft ermöglicht eine explizite Definition von Erfolgscodes für Beispiel: 2XX, 1XX, 505 behandelt alle HTTP-Antwortcodes 100, 200 und 505 wie Erfolg haben.

Wenn Sie diese Eigenschaft festlegen, werden die Standardwerte überschrieben. Wenn Sie also HTTP-Code 400 zur Liste der Standarderfolgscodes hinzufügen möchten, legen Sie dieses Attribut so fest:

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

Wenn nur HTTP-Code 400 als Erfolgscode behandelt werden soll, setzen Sie das Attribut so:

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

Wenn Sie den HTTP-Code 400 als einzigen Erfolgscode festlegen, werden die Codes 1XX, 2XX und 3XX als Fehler behandelt werden.
compression.algorithm – Standardmäßig leitet Apigee Edge Anfragen an das Ziel mit demselben Komprimierungstyp wie die Clientanfrage weiter. Wenn die Anfrage vom Client mit der gzip-Komprimierung empfangen wird, leitet Apigee Edge die Anfrage über die gzip-Komprimierung an das Ziel weiter. Wenn die vom Ziel empfangene Antwort deflate verwendet, leitet Apigee Edge die Antwort mithilfe von deflate an den Client weiter. Unterstützte Werte:
  • gzip: Nachrichten immer mit gzip-Komprimierung senden
  • deflate: Nachrichten immer mit deflate-Komprimierung senden
  • none: Die Nachricht wird immer ohne Komprimierung gesendet

Siehe auch: Unterstützt Apigee die Komprimierung/Dekomprimierung mit GZIP/Deflate-Komprimierung?
request.retain.headers.
enabled		 true Standardmäßig behält Apigee Edge alle HTTP-Header in ausgehenden Nachrichten bei. Wenn true festgelegt ist, werden alle HTTP-Header, die in der eingehenden Anfrage enthalten sind, für die ausgehende Anfrage festgelegt.
request.retain.headers – Definiert bestimmte HTTP-Header aus der Anfrage, die für die ausgehende Anfrage an den Zieldienst festgelegt werden soll. Wenn Sie beispielsweise den User-Agent-Header "durchreichen" möchten, setzen Sie den Wert von User-Agent auf request.retain.headers Mehrere HTTP-Header werden als durch Kommata getrennte Liste angegeben, z. B. User-Agent,Referer,Accept-Language. Dieses Attribut überschreibt request.retain.headers.enabled. Wenn request.retain.headers.enabled auf false gesetzt ist, werden alle Header, die im Attribut request.retain.headers angegeben sind, für die ausgehende Nachricht festgelegt.
response.retain.headers.
enabled		 true Standardmäßig behält Apigee Edge alle HTTP-Header in ausgehenden Nachrichten bei. Wenn dieser Wert auf true gesetzt ist, werden alle HTTP-Header, die in der eingehenden Antwort vom Zieldienst vorhanden sind, auf die ausgehende Antwort festgelegt, bevor sie an den ProxyEndpoint übergeben wird.
response.retain.headers – Definiert spezifische HTTP-Header aus der Antwort, die auf die ausgehende Antwort festgelegt werden sollten, bevor sie an den ProxyEndpoint übergeben wird. Für Passthrough gilt beispielsweise Folgendes: Expires-Headers den Wert von response.retain.headers auf Expires Mehrere HTTP-Header werden als durch Kommas getrennte Liste angegeben, für Beispiel: Expires,Set-Cookie. Dieses Attribut überschreibt response.retain.headers.enabled. Wenn response.retain.headers.enabled ist auf false gesetzt, alle Header die in der Eigenschaft response.retain.headers angegeben sind, ausgehende Nachricht.
retain.queryparams.
enabled		 true Standardmäßig behält Apigee Edge alle Abfrageparameter für ausgehende Anfragen bei. Wenn true festgelegt ist, werden alle Abfrageparameter, die in der eingehenden Anfrage enthalten sind, für die ausgehende Anfrage an den Zieldienst festgelegt.
retain.queryparams – Definiert bestimmte Abfrageparameter, die für die ausgehende Anfrage festgelegt werden sollen. Wenn Sie beispielsweise den Abfrageparameter apikey aus der Anfragenachricht einschließen möchten, legen Sie für retain.queryparams den Wert apikey fest. Mehrere Abfrageparameter werden als Kommata getrennte Liste angegeben, z. B. apikey,environment. Dieses Attribut überschreibt retain.queryparams.enabled.

ProxyEndpoint-Transportattribute

ProxyEndpoint HTTPTargetConnection-Elemente definieren eine Reihe von HTTP-Transportattributen. Mit diesen Attributen können Konfigurationen auf Transportebene festgelegt werden.

Attribute werden für ProxyEndpoint HTTPProxyConnection-Elemente wie folgt festgelegt:

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

Weitere Informationen zu virtuellen Hosts finden Sie unter Informationen zu virtuellen Hosts.

ProxyEndpoint-Transportattribut Spezifikation

Property-Name Standardwert Beschreibung
X-Forwarded-For false Wenn true festgelegt ist, wird die IP-Adresse des virtuellen Hosts der ausgehenden Anfrage als -Wert des HTTP-X-Forwarded-For-Headers.
request.streaming.
enabled		 false Standardmäßig (false) werden Nutzlasten von HTTP-Anfragen in einen Zwischenspeicher eingelesen und Richtlinien, die wie erwartet mit der Nutzlast arbeiten. In Fällen, in denen die Nutzlasten größer sind als die (10 MB) haben, können Sie dies auf true. Wenn true, werden die Nutzlasten von HTTP-Anfragen nicht in einen Zwischenspeicher gelesen. sie sind unverändert an den TargetEndpoint-Anfrageablauf gestreamt werden. In diesem Fall werden alle Richtlinien, die auf die Nutzlast im ProxyEndpoint-Anfrageablauf angewendet werden, umgangen. Siehe auch Streaminganfragen und -antworten.
response.streaming.
enabled		 false Standardmäßig (false) werden Nutzlasten von HTTP-Antworten in einen Zwischenspeicher eingelesen und Richtlinien, die wie erwartet mit der Nutzlast arbeiten. In Fällen, in denen die Nutzlast größer ist als der Puffergröße (10 MB) haben, können Sie auf true. Wenn true, werden die Nutzlasten von HTTP-Antworten nicht in einen Zwischenspeicher gelesen. sie sind unverändert an den Kunden gestreamt werden. In diesem Fall werden alle Richtlinien, die auf die Nutzlast im ProxyEndpoint-Antwortablauf angewendet werden, umgangen. Siehe auch Streaminganfragen und -antworten.
compression.algorithm –

Standardmäßig berücksichtigt Apigee Edge den Komprimierungstyp für alle empfangenen Nachrichten. Wenn ein Client beispielsweise eine Anfrage mit gzip-Komprimierung sendet, leitet Apigee Edge die Anfrage über die gzip-Komprimierung an das Ziel weiter. Sie können Komprimierungsalgorithmen konfigurieren, die explizit angewendet werden. Dazu legen Sie dieses Attribut auf dem TargetEndpoint oder Proxy fest. Unterstützte Werte:

  • gzip: Nachrichten immer mit gzip-Komprimierung senden
  • deflate: Nachrichten immer mit deflate-Komprimierung senden
  • none: Die Nachricht wird immer ohne Komprimierung gesendet

Siehe auch: Unterstützt Apigee die Komprimierung/Dekomprimierung mit GZIP/Deflate-Komprimierung?
api.timeout –

Zeitlimit für einzelne API-Proxys konfigurieren

Sie können API-Proxys konfigurieren, auch solche mit aktiviertem Streaming, um eine bestimmte Zeit mit dem Status 504 Gateway Timeout zu warten. Der primäre Anwendungsfall ist für Kunden mit API-Proxys vorgesehen deren Ausführung länger dauert. Angenommen, Sie benötigen bestimmte Proxy-Zeitüberschreitungen nach 3 Minuten. So verwenden Sie api.timeout.

  1. Konfigurieren Sie zuerst den Load-Balancer, den Router und den Nachrichtenprozessor für eine Zeitüberschreitung nach drei Minuten.
  2. Konfigurieren Sie anschließend die relevanten Proxy-Zeitüberschreitungen nach 3 Minuten. Geben Sie den Wert in Millisekunden an. Beispiel: <Property name="api.timeout">180000</Property>
  3. Beachten Sie jedoch, dass das Erhöhen der Systemzeitüberschreitungen zu Leistungsproblemen führen kann, da alle Proxys ohne die Einstellung api.timeout den neuen, höheren Load-Balancer, Router und Nachrichtenprozessorzeitüberschreitungen. Konfigurieren Sie daher andere API-Proxys, die keine längeren Zeitüberschreitungen erfordern, um niedrigere Zeitüberschreitungen zu verwenden. Im folgenden Beispiel wird festgelegt, dass ein API-Proxy nach einer Minute mit einer Zeitüberschreitung abläuft:
    <Property name="api.timeout">60000</Property>

Sie können dieses Attribut nicht mit einer Variable festlegen.

Kunden, die die Edge-Zeitlimits nicht ändern können, können auch einen API-Proxy konfigurieren Zeitüberschreitung, solange das Zeitlimit kürzer ist als der Standard-Edge-Nachrichtenprozessor Zeitüberschreitung von 57 Sekunden.

Weitere Informationen finden Sie unter io.timeout.millis und api.timeout für Edge festlegen. finden Sie weitere Informationen.

io.timeout.millis und api.timeout für Edge festlegen

In Edge: Der Betrieb von io.timeout.millis und api.timeout zusammengehören. Bei jeder Anfrage an einen API-Proxy:

  1. Der Router sendet sein Zeitlimit an den Nachrichtenprozessor. Der Zeitüberschreitungswert des Routers ist entweder der Wert von proxy_read_timeout, der von dem virtuellen Host festgelegt wird, der die Anfrage verarbeitet, oder der Standardwert für die Zeitüberschreitung von 57 Sekunden.
  2. Der Nachrichtenprozessor legt dann api.timeout fest:
    1. Wenn api.timeout nicht auf Proxyebene festgelegt ist, legen Sie es auf das Router-Zeitlimit fest.
    2. Wenn api.timeout auf Proxyebene festgelegt ist, setzen Sie sie im Nachrichtenprozessor auf einen geringeren Wert als die Router-Zeitüberschreitung oder den Wert von api.timeout.

  3. Der Wert von api.timeout gibt die maximale Zeit an, die ein API-Proxy von der API-Anfrage an die Antwort ausgeführt werden muss.

    Nachdem jede Richtlinie im API-Proxy ausgeführt wurde, bevor der Message Processor die Anfrage an den Zielendpunkt sendet, berechnet der Message Processor (api.timeout – verstrichene Zeit ab Beginn der Anfrage). Wenn der Wert kleiner als null ist, ist die maximale Zeit für die Bearbeitung der Anfrage abgelaufen und gibt der Message Processor 504 zurück.

  4. Der Wert von io.timeout.millis gibt an, wie lange der Zielendpunkt antworten muss.

    Vor dem Herstellen einer Verbindung zu einem Zielendpunkt ermittelt der Message Processor, je nachdem, welcher Wert (api.timeout: verstrichene Zeit seit Beginn der Anfrage) und io.timeout.millis. Dann wird io.timeout.millis auf diesen Wert gesetzt.

    • Wenn beim Schreiben der HTTP-Anfrage eine Zeitüberschreitung auftritt, wird 408, Request Timeout zurückgegeben.
    • Wenn beim Lesen der HTTP-Antwort eine Zeitüberschreitung auftritt, wird 504, Gateway Timeout zurückgegeben.

Über ScriptTarget für Node.js-Anwendungen

Das ScriptTarget-Element wird verwendet, um eine Node.js-Anwendung in Ihren Proxy zu integrieren. Für Informationen zur Verwendung von Node.js und ScriptTarget finden Sie unter:

Informationen zu HostedTarget-Endpunkten

Ein leeres <HostedTarget/>-Tag weist Edge an, Node.js als Ziel zu verwenden. Anwendung, die in der Umgebung "Gehostete Ziele" bereitgestellt wird. Weitere Informationen finden Sie unter Gehostete Ziele – Übersicht