Diese Seite wurde von der Cloud Translation API übersetzt.

Referenz für Endpunktattribute

Sie sehen die Dokumentation zu Apigee Edge.
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>

Attribut „TargetEndpoint-Transport“ Spezifikation

Eigenschaftsname	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-Statuscode `503` zurück, wenn eine Verbindungszeitüberschreitung auftritt.
`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 als das Zeitlimit sein, das vom Router für die Kommunikation mit dem Message Processor verwendet wird. Weitere Informationen finden Sie unter Router-Zeitlimit konfigurieren. Weitere Informationen finden Sie unter io.timeout.millis und api.timeout für Edge festlegen.
`supports.http10`	`true`	Wenn der Wert `true` ist und der Client eine 1.0-Anfrage sendet, wird auch eine 1.0-Anfrage an das Ziel gesendet. Andernfalls wird die 1.1-Anfrage an das Ziel gesendet.
`supports.http11`	`true`	Wenn der Wert `true` ist und der Client eine 1.1-Anfrage sendet, wird ebenfalls eine 1.1-Anfrage an das Ziel gesendet. 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 Nutzlasten von HTTP-Anfragen in einen Zwischenspeicher eingelesen und Richtlinien, die mit der Nutzlast arbeiten können, funktionieren wie erwartet. Falls die Nutzlasten die Puffergröße (10 MB) überschreiten, können Sie dieses Attribut auf `true` setzen. Bei `true` werden Nutzlasten von HTTP-Anfragen nicht in einen Zwischenspeicher eingelesen, sondern unverändert an den Zielendpunkt gestreamt. 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 Puffer eingelesen und Richtlinien, die mit der Nutzlast arbeiten können, funktionieren wie erwartet. Falls die Nutzlasten die Puffergröße (10 MB) überschreiten, können Sie dieses Attribut auf `true` setzen. Wenn `true`, werden HTTP-Antwortnutzlasten nicht in einen Zwischenspeicher eingelesen, sondern unverändert an den ProxyEndpoint-Antwortfluss gestreamt. In diesem Fall werden alle Richtlinien, die an der Nutzlast des TargetEndpoint-Antwortablaufs arbeiten, umgangen. Weitere Informationen finden Sie unter Streaminganfragen und -antworten.
`success.codes`	–	Standardmäßig behandelt Apigee Edge den HTTP-Code `4XX` oder `5XX` als Fehler und den HTTP-Code `1XX`, `2XX`, `3XX` als Erfolg. Dieses Attribut ermöglicht die explizite Definition von Erfolgscodes. Beispielsweise behandelt `2XX, 1XX, 505` alle HTTP-Antwortcodes `100`, `200` und `505` als Erfolg. 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: <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.
`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. Wenn Sie beispielsweise den `Expires`-Header mit Passthrough übergeben möchten, legen Sie für `response.retain.headers` den Wert `Expires` fest. Mehrere HTTP-Header werden als durch Kommas getrennte Liste angegeben, z. B. `Expires,Set-Cookie`. Dieses Attribut überschreibt `response.retain.headers.enabled`. Wenn `response.retain.headers.enabled` auf `false` gesetzt ist, werden alle im Attribut `response.retain.headers` angegebenen Header weiterhin für die ausgehende Nachricht festgelegt.
`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-Transport-Attribute

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

Eigenschaftsname	Standardwert	Beschreibung
`X-Forwarded-For`	`false`	Wenn `true` festgelegt ist, wird die IP-Adresse des virtuellen Hosts der ausgehenden Anfrage als Wert des HTTP-Headers `X-Forwarded-For` hinzugefügt.
`request.streaming. enabled`	`false`	Standardmäßig (`false`) werden Nutzlasten von HTTP-Anfragen in einen Zwischenspeicher eingelesen. Richtlinien, die mit der Nutzlast arbeiten können, funktionieren wie erwartet. Falls die Nutzlasten die Puffergröße (10 MB) überschreiten, können Sie dieses Attribut auf `true` setzen. Bei `true` werden Nutzlasten von HTTP-Anfragen nicht in einen Zwischenspeicher eingelesen, sondern unverändert an den TargetEndpoint-Anfragefluss gestreamt. 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 Puffer eingelesen und Richtlinien, die mit der Nutzlast arbeiten können, funktionieren wie erwartet. Falls die Nutzlasten die Puffergröße (10 MB) überschreiten, können Sie dieses Attribut auf `true` setzen. Bei `true` werden Nutzlasten von HTTP-Antworten nicht in einen Zwischenspeicher eingelesen, sondern unverändert an den Client gestreamt. 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, deren Ausführung länger dauert. Angenommen, Sie benötigen bestimmte Proxy-Zeitüberschreitungen nach 3 Minuten. So verwenden Sie `api.timeout`. Konfigurieren Sie zuerst den Load-Balancer, den Router und den Nachrichtenprozessor für eine Zeitüberschreitung nach drei Minuten. 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>` 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-Zeitüberschreitungen nicht ändern können, können auch ein API-Proxy-Zeitlimit konfigurieren, solange das Zeitlimit kürzer als das Standardzeitlimit des Edge-Nachrichtenprozessors von 57 Sekunden ist. Weitere Informationen finden Sie unter io.timeout.millis und api.timeout für Edge festlegen.

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

In Edge sind der Vorgang von io.timeout.millis und api.timeout verwandt. Bei jeder Anfrage an einen API-Proxy:

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.
Der Message Processor 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.
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 oder bevor der Message Processor die Anfrage an den Zielendpunkt sendet, berechnet der Message Processor (api.timeout – verstrichene Zeit ab dem Beginn der Anfrage). Wenn der Wert kleiner als null ist, ist die maximale Zeit für die Bearbeitung der Anfrage abgelaufen und der Message Processor gibt 504 zurück.
Der Wert von io.timeout.millis gibt an, wie lange der Zielendpunkt antworten muss.

Bevor eine Verbindung zu einem Zielendpunkt hergestellt wird, ermittelt der Message Processor den kleineren Wert von (api.timeout – verstrichene Zeit ab dem 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.

ScriptTarget für Node.js-Anwendungen

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

Informationen zu HostedTarget-Endpunkten

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