Diese Seite wurde von der Cloud Translation API übersetzt.

Referenz für Endpunktattribute

Diese Seite gilt für Apigee und Apigee Hybrid.

Apigee Edge-Dokumentation aufrufen

In diesem Thema werden Transportattribute beschrieben, die in TargetEndpoint- und ProxyEndpoint-Konfigurationen festgelegt werden können, um das Nachrichten- und Verbindungsverhalten zu steuern. Eine vollständige Beschreibung der Konfigurationsoptionen TargetEndpoint und ProxyEndpoint finden Sie in der API-Proxy-Konfigurationsreferenz.

Attribute von TargetEndpoint Transport

Das HTTPTargetConnection-Element 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-Elemente vom Typ HTTPTargetConnection festgelegt, wie in dieser Beispielkonfiguration gezeigt:

<TargetEndpoint name="default">
  <HTTPTargetConnection>
    <URL>http://mocktarget.apigee.net</URL>
    <Properties>
      <Property name="request.retain.headers">User-Agent,Referer,Accept-Language</Property>
      <Property name="retain.queryparams">apikey</Property>
    </Properties>
  </HTTPTargetConnection>
</TargetEndpoint>

TargetEndpoint Transport-Attributspezifikation

Property-Name	Standardwert	Beschreibung
`allow.post.without.content.length`	falsch	Ermöglicht das Senden von POST-Anfragen ohne Inhalt im Text.
`allow.put.without.content.length`	falsch	Ermöglicht das Senden von PUT-Anfragen ohne Inhalt im Text.
`allow.tls.session.resumption`	wahr	Bei `true` (Standard) verwenden Clients TLS-Sitzungen wieder, wenn sie neue Verbindungen zum Ziel herstellen. Legen Sie `false` fest, wenn Sie nicht möchten, dass TLS-Sitzungen wiederverwendet werden. Die Wiederverwendung von Sitzungen bedeutet in der Regel kürzere Verbindungszeiten, einige Ziele unterstützen jedoch möglicherweise die Wiederverwendung von Sitzungen nicht oder es sind Probleme damit aufgetreten.
`keepalive.timeout.millis`	60.000	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`	3.000	Zeitlimit für Zielverbindung. Apigee gibt den HTTP-Statuscode `503` zurück, wenn eine Verbindungszeitüberschreitung auftritt. In einigen Fällen wird der HTTP-Statuscode `504` zurückgegeben, wenn `LoadBalancer` in der TargetServer-Definition verwendet wird und eine Zeitüberschreitung Hinweis: In einigen Fällen wiederholt Apigee die Verbindung automatisch bis zu dreimal. Daher kann die Gesamtwiederholungszeit die für `connect.timeout.millis` konfigurierte Zeit überschreiten.
`ignore.allow.header.for.405`	wahr	Ermöglicht die Übergabe des Statuscodes 405 an den Client. Durch Aktivieren des Flags gibt Apigee 405 anstelle von 502 zurück.
`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 Lesen der HTTP-Anfrage von eingehendem Traffic eine Zeitüberschreitung auftritt, wird `408 Request Timeout` neu abgestimmt. `408 Request Timeout` wird nicht zurückgegeben, wenn beim Schreiben einer Anfrage an das Ziel eine Zeitüberschreitung auftritt. Wenn beim Schreiben der HTTP-Anfrage oder beim Lesen der HTTP-Antwort eine Zeitüberschreitung auftritt, wird `504 Gateway Timeout` zurückgegeben. Hinweis: Wenn Sie WebSocket-Verbindungen verwenden, werden Zeitüberschreitungen, die über den Standardwert von 5500 hinausgehen, mit diesem Attribut nicht berücksichtigt, wenn die WebSocket-Verbindung inaktiv ist. Die Verbindung wird nach 55 Sekunden geschlossen. Siehe io.timeout.millis und api.timeout.
`supports.http11`	wahr	Wenn dies `true` ist und der Client eine `1.1`-Anfrage sendet, sendet das Ziel auch eine `1.1`-Anfrage. Andernfalls wird eine `1.0`-Anfrage an das Ziel gesendet.
`use.proxy`	wahr	Dieses Attribut gilt nur für Apigee Hybrid. Wenn die Apigee-Hybrid-Überschreibungsdatei die Konfiguration `HTTP_PROXY` enthält, wie in Weiterleitungsproxy für API-Proxys konfigurieren beschrieben, dann verwenden Sie dieses Attribut, um zu verwalten/steuern, welche Proxys die Proxy-Konfiguration nicht verwenden sollen. Wenn diese Option auf `false` gesetzt ist, überspringt der API-Proxy die in der Apigee-Hybridüberschreibungsdatei angegebenen HTTP-Proxy-Konfigurationen für im Proxy eingestellte Zielverbindungen.
`use.proxy.tunneling`	wahr	Dieses Attribut gilt nur für Apigee Hybrid. Wenn dies auf "true" gesetzt ist und Proxy-Konfigurationen in der Überschreibungsdatei von Apigee Hybrid angegeben sind, wie in Weiterleitungsproxy für API-Proxys konfigurieren beschrieben, dann werden die Zielverbindungen so eingestellt, dass sie den angegebenen Tunnel verwenden. Wenn das Ziel TLS/SSL verwendet, wird dieses Attribut ignoriert und die Nachricht immer über einen Tunnel gesendet.
`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 Zwischenspeichergröße (10 MB in Apigee) 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 Zwischenspeichergröße (10 MB in Apigee) sind, können Sie dieses Attribut auf "true" setzen. Bei Einstellung auf `ProxyEndpoint` werden die HTTP-Antwortnutzlasten nicht in einen Zwischenspeicher, sondern unverändert in den ProxyEndpoint-Antwortablauf gestreamt. In diesem Fall werden alle Richtlinien, die auf die Nutzlast im `TargetEndpoint`-Antwortablauf angewendet werden, umgangen. Weitere Informationen finden Sie unter Anfragen und Antworten streamen.
`success.codes`	–	Standardmäßig behandelt Apigee den HTTP-Code `4XX` oder `5XX` als Fehler und behandelt 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 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 berücksichtigt Apigee den Komprimierungstyp (gzip, deflate oder no) für empfangene Nachrichten. Wenn die Anfrage vom Client mit der GZIP-Komprimierung empfangen wird, leitet Apigee 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`	wahr	Standardmäßig behält Apigee 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`	wahr	Standardmäßig behält Apigee 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 "durchreichen" möchten, setzen Sie den Wert von `Expires` auf `response.retain.headers` 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`	wahr	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-Elemente vom Typ HTTPProxyConnection festgelegt, wie in dieser Beispielkonfiguration gezeigt:

<ProxyEndpoint name="default">
  <HTTPProxyConnection>
    <BasePath>/v1/weather</BasePath>
    <Properties>
      <Property name="request.streaming.enabled">true</Property>
    </Properties>
  </HTTPProxyConnection>
</ProxyEndpoint>

Anfrageheader

Eine eingehende HTTP-Anfrage enthält die HTTP-Header, die vom Client gesendet werden. Header mit Namen, die mit dem Muster X-Apigee-* übereinstimmen, werden aus eingehenden Anfragen entfernt, wenn ein Client sie sendet. Dieses Namensmuster ist für Apigee reserviert.

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 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 Zwischenspeichergröße (10 MB in Apigee) 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 Zwischenspeichergröße (10 MB in Apigee) 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 den Komprimierungstyp (gzip, deflate oder no) für empfangene Nachrichten. Wenn ein Client beispielsweise eine Anfrage mit gzip-Komprimierung sendet, leitet Apigee die Anfrage über die gzip-Komprimierung an das Ziel weiter. Sie können Komprimierungsalgorithmen explizit konfigurieren, indem Sie dieses Attribut auf `TargetEndpoint` oder `ProxyEndpoint` festlegen. 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 (in Millisekunden) Sie können API-Proxys konfigurieren, auch solche mit aktiviertem Streaming, um eine bestimmte Zeit mit dem Status `504 Gateway Timeout` zu warten. Wichtig: Das angegebene Zeitlimit muss kürzer sein als das standardmäßige Zeitlimit für den Message Processor von 300 Sekunden. Wenn Sie beispielsweise einen Proxy so konfigurieren möchten, dass er nach 180.000 Millisekunden (drei Minuten) eine Zeitüberschreitung auslöst, fügen Sie das folgende Attribut zu `HTTPProxyConnection` hinzu: <Property name="api.timeout">180000</Property> Sie können dieses Attribut nicht mit einer Variable festlegen. Siehe io.timeout.millis und api.timeout.
`HTTPHeader.allowDuplicates`	–	Verwenden Sie diese Einstellung, um doppelte Header (für bestimmte Header) zuzulassen. <HTTPProxyConnection> <Properties> <Property name="HTTPHeader.allowDuplicates">Content-Type,Authorization</Property> </Properties> </HTTPProxyConnection>
`HTTPHeader.multiValued`	–	Verwenden Sie diese Einstellung, um doppelte Header (für bestimmte Header) zuzulassen. <HTTPProxyConnection> <Properties> <Property name="HTTPHeader.multiValued">Content-Type,Authorization</Property> </Properties> </HTTPProxyConnection>

io.timeout.millis und api.timeout festlegen

Die Vorgänge io.timeout.millis und api.timeout sind verbunden. Bei jeder Anfrage an einen API-Proxy:

Der Ingress (auch als interner Load-Balancer bezeichnet) sendet seinen Wert für die Zeitüberschreitung an den Message Processor. Der Wert für die Zeitüberschreitung beträgt standardmäßig 300 Sekunden und kann nicht konfiguriert werden.
Der Nachrichtenprozessor legt dann api.timeout fest:
1. Wenn api.timeout nicht auf Proxyebene festgelegt ist, verwenden Sie das vom Ingress festgelegte Zeitlimit.
2. Wenn api.timeout auf Proxyebene festgelegt ist, setzen Sie sie im Message Processor auf einen geringeren Wert als die Ingress-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 Nachrichtenprozessor gibt 504 Gateway Timeout zurück.
Der Wert von io.timeout.millis gibt an, wie lange der Zielendpunkt antworten muss.

Bevor eine Verbindung zu einem Ziel-Endpunkt 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 oder beim Lesen der HTTP-Antwort eine Zeitüberschreitung auftritt, wird 504 Gateway Timeout zurückgegeben.