Google verwendet KI-Technologie, um Inhalte in Ihre bevorzugte Sprache zu übersetzen. KI-Übersetzungen können Fehler enthalten.

Referenz für Endpunktattribute

Sie lesen gerade die Dokumentation zu Apigee Edge.
Zur Dokumentation zuApigee X wechseln. info

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.

Attribute von TargetEndpoint Transport

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>

Spezifikation des TargetEndpoint Transport-Attributs

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 den HTTP-`503` Statuscode zurück, wenn eine Zeitüberschreitung bei der Verbindung auftritt. In einigen Fällen wird der HTTP-Statuscode 504 zurückgegeben, wenn `LoadBalancer` verwendet wird in der TargetServer-Definition und eine Zeitüberschreitung auftritt. Hinweis:In einigen Fällen wiederholt Apigee die Verbindung automatisch bis zu dreimal. Daher kann die Gesamtwiederholungszeit die für `connect.timeout.millis` konfigurierten Werte überschreiten.
`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 Zeitlimit für Router konfigurieren für weitere. Weitere Informationen finden Sie unter io.timeout.millis und api.timeout für Edge festlegen.
`supports.http10`	`true`	Wenn dieser 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 dieser Wert `true` ist und der Client eine 1.1-Anfrage sendet, wird auch eine 1.1 Anfrage an das Ziel gesendet. Andernfalls wird eine 1.0-Anfrage an das Ziel gesendet.
`use.proxy`	`true`	Wenn auf `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 dies auf `true` festgelegt ist und Proxykonfigurationen in `http.properties` angegeben werden (nur lokale Bereitstellungen), werden Ziel verbindungen 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. Beispiel: `<Property name="GET.override.method">POST</Property>`
`request.streaming.enabled`	`false`	Standardmäßig (`false`) werden HTTP-Anforderungsnutzlasten in einen Zwischenspeicher eingelesen und Richtlinien, die die Nutzlast verarbeiten können, funktionieren erwartungsgemäß. In Fällen, in denen die Nutzlasten größer als die Puffergröße (10 MB) sind, können Sie dieses Attribut auf `true` setzen. Bei Einstellung auf `true` werden die Nutzlasten von HTTP-Anfragen nicht in einen Zwischenspeicher gelesen, sondern unverändert an den Zielendpunkt gestreamt. In diesem Fall werden alle Richtlinien, die auf die Nutzlast im TargetEndpoint-Anfrageablauf angewendet werden, umgangen. Weitere Informationen finden Sie unter Anfragen und Antworten streamen.
`response.streaming.enabled`	`false`	Standardmäßig (`false`) werden HTTP-Antwortnutzlasten in einen Zwischenspeicher eingelesen und Richtlinien, die die Nutzlast verarbeiten können, funktionieren erwartungsgemäß. In Fällen, in denen die Nutzlasten größer als die Puffergröße (10 MB) sind, können Sie dieses Attribut auf `true` setzen. Bei Einstellung auf `true` werden die HTTP-Antwortnutzlasten nicht in einen Zwischenspeicher, sondern unverändert in den ProxyEndpoint-Antwortablauf gestreamt. In diesem Fall werden alle Richtlinien, die an der Nutzlast des TargetEndpoint-Antwortablaufs arbeiten, umgangen. Weitere Informationen finden Sie unter Anfragen und Antworten streamen.
`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, zum Beispiel behandelt `2XX, 1XX, 505` alle `100`, `200` und `505` HTTP-Antwortcodes als Erfolg. Wenn Sie diese Eigenschaft festlegen, werden die Standardwerte überschrieben. Wenn Sie also den 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 der 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 compression/de-Komprimierung 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 `request.retain.headers` Attribut 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 durchreichen Header `Expires` möchten, setzen Sie den Wert von `response.retain.headers` auf `Expires`. Mehrere HTTP-Header werden als durch Kommata 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 Header, die im Attribut `response.retain.headers` angegeben sind, 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 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.

Spezifikation des ProxyEndpoint Transport-Attributs

Property-Name	Standardwert	Beschreibung
`X-Forwarded-For`	`false`	Wenn dieser Wert auf `true` gesetzt ist, wird die IP-Adresse des virtuellen Hosts der ausgehenden Anfrage als der Wert des HTTP-Headers `X-Forwarded-For` hinzugefügt.
`request.streaming. enabled`	`false`	Standardmäßig (`false`) werden HTTP-Anforderungsnutzlasten in einen Zwischenspeicher eingelesen und Richtlinien, die die Nutzlast verarbeiten können, funktionieren erwartungsgemäß. In Fällen, in denen die Nutzlasten größer als die Puffergröße (10 MB) sind, können Sie dieses Attribut auf `true` setzen. Bei `true` werden Nutzlasten von HTTP-Anfragen nicht in einen Zwischenspeicher gelesen, sondern unverändert in den TargetEndpoint-Anfrageablauf gestreamt. In diesem Fall werden alle Richtlinien, die auf die Nutzlast im ProxyEndpoint-Anfrageablauf angewendet werden, umgangen. Weitere Informationen finden Sie unter Anfragen und Antworten streamen.
`response.streaming. enabled`	`false`	Standardmäßig (`false`) werden HTTP-Antwortnutzlasten in einen Zwischenspeicher eingelesen und Richtlinien, die die Nutzlast verarbeiten können, funktionieren erwartungsgemäß. In Fällen, in denen die Nutzlasten größer als die Puffergröße (10 MB) sind, können Sie dieses Attribut auf `true` setzen. Bei Einstellung auf `true` werden die HTTP-Antwortnutzlasten nicht in einen Zwischenspeicher gelesen, sondern unverändert an den Client gestreamt. In diesem Fall werden alle Richtlinien, die auf die Nutzlast im ProxyEndpoint-Antwortablauf angewendet werden, umgangen. Weitere Informationen finden Sie unter Anfragen und Antworten streamen.
`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 compression/de-Komprimierung mit GZIP/deflate Komprimierung?
`api.timeout`	–	Zeitlimit für einzelne API-Proxys konfigurieren Sie können API-Proxys konfigurieren, auch solche mit Streaming aktiviert, um nach einer bestimmten Zeit mit dem Status `504 Gateway Timeout` eine Zeitüberschreitung zu erhalten. Der primäre Anwendungsfall sind 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 standardmäßige Edge-Nachrichtenprozessor Zeitlimit 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 die Vorgänge io.timeout.millis und api.timeout miteinander verbunden. Bei jeder Anfrage an einen API-Proxy:

Der Router sendet sein Zeitlimit an den Message Processor. 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 Message Processor 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 Start der Anfrage). Wenn der Wert kleiner als null ist, ist die maximale Zeit für die Verarbeitung 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 seit dem Start 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 Element ScriptTarget wird verwendet, um eine Node.js-Anwendung in Ihren Proxy zu integrieren. Informationen zur Verwendung von Node.js und ScriptTarget finden Sie unter:

Gehostete Zielendpunkte

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