# Einstellungen für On Demand Router

Verwenden Sie diesen Artikel, um eine erweiterte Konfiguration für einen On Demand Router (ODR) durchzuführen. Mit ODR-Einstellungen können Sie das Verhalten des ODR optimieren. Sie können die Verbindungen und Anforderungen für den Anwendungsserver konfigurieren, Caching aktivieren, die Anforderungen konfigurieren, die zurückgewiesen werden müssen, die Verarbeitung von Fehlerantworten definieren und die Position der ODR-Protokolle festlegen.

Nach der Erstellung erkennt der ODR-Server die Umgebung und kann Anforderungen an WebSphere Application Server weiterleiten. Sie können den ODR weitergehend konfigurieren, um ihn an die Anforderungen Ihrer spezifischen Umgebung anzupassen. Die Konfiguration des ODR in der DMZ wird nicht unterstützt.

Klicken Sie zum Anzeigen dieser Seite der Administrationskonsole auf Server > Servertypen > On Demand Router > ODR-Name > Eigenschaften für On Demand Router > Einstellungen für Demand Router.

Zum Ändern der ODR-Einstellungen benötigen Sie Administrator- oder Konfigurationsverwaltungsberechtigungen.

Auf der Registerseite Konfiguration können Sie Einstellungen für den ODR editieren.

## Content-Server-Verbindung

Basisparameter für die HTTP-Verbindung zwischen dem Proxy-Server und Content-Servern konfigurieren.

Zeitlimit für abgehende Anforderungen
  Diese Einstellung legt fest, wie lange (in Sekunden) der ODR standardmäßig auf Antworten von Content-Servern wartet. Gehen Sie beim Ändern des Wertes sorgfältig vor.

Zeitlimit für abgehende Verbindungen
  Die Anzahl der Millisekunden, die der ODR auf die Verbindungsherstellung zu einem Server wartet. Nach Ablauf dieser Zeit versucht der ODR, eine Verbindung zu einem anderen Server herzustellen. Wenn keine anderen verfügbaren Server vorhanden sind, überschreitet die Anforderung das zulässige Zeitlimit. Der Wert "0" gibt an, dass der ODR den Zeitlimitwert des Betriebssystemkernels verwenden soll.

Verbindungspools für Content-Server erstellen
  Diese Optimierungsoption ermöglicht, Verbindungen zum Server in einem Pool verwalten zu können. Indem Sie dem ODR erlauben, die Verbindungen in einem Pool zu verwalten und wiederzuverwenden, entfällt die Notwendigkeit, ständig Socket-Verbindungen zum Server zu erstellen und zu trennen. Der Standardwert für die maximal zulässige Verbindungsanzahl pro Server ist 0, d. h., die Anzahl der Verbindung kann sich je nach Bedarf erhöhen.

Maximale Anzahl Verbindungen pro Server
  Die maximale Anzahl an Verbindungen, die für einen Content-Server in den Pool gestellt werden. Die angepassten Eigenschaften des ODR, die Verbindungen zu Content-Servern beeinflussen, sind im Folgenden aufgeführt:
  - key=http.maxTargetReconnects: Gibt an, wie oft Anforderung an den Ziel-Content-Server maximal wiederholt wird. Der Standardwert ist 5.
  - key=http.maxTargetRetries: Gibt an, wie oft der ODR maximal versucht, einen neuen Ziel-Content-Server für eine Anforderung auszuwählen. Der Standardwert ist 5.
  - key=http.routing.sendReverseProxyNameInHost: Legt fest, ob der ODR-Name für Inhalte, die für die Content-Server von WebSphere Application Server nicht spezifisch sind, in den Host-Header aufgenommen wird. Die gültigen Optionen sind `true` und `false`. Es wird nicht zwischen Groß-/Kleinschreibung unterschieden. Die Standardeinstellung ist false.
  - key=http.compliance.disable: Legt fest, ob die Konformität mit HTTP Version 1.1 in Verbindungen zwischen ODR und Content-Servern umgesetzt wird. Die gültigen Optionen sind `true` und `false`. Es wird nicht zwischen Groß-/Kleinschreibung unterschieden. Die Standardeinstellung ist false.
  - key=http.compliance.via: Der Wert des Header via, der für die HTTP-Konformität an Anforderungen und Antworten angefügt wird. Wenn der Wert null ist, wird kein Header via angefügt. Wenn der Wert true ist, wird ein via-Standardwert angefügt. Andernfalls wird die als via-Wert angegebene Zeichenfolge angefügt. Der Standardwert ist null.

## Caching

Der ODR kann so konfiguriert werden, dass der Inhalt von Servern zwischengespeichert wird.

Das Caching von Inhalten ist standardmäßig aktiviert. Die folgenden Eigenschaften gelten nur, wenn das Caching aktiviert ist:

Caching aktivieren
  Aktiviert das Caching-Gerüst für den ODR und das Caching statischer Inhalte gemäß der Spezifikation HTTP 1.1.

Name der Cacheinstanz
  Die Cacheinstanz des dynamischen Objektcaches, die unter Ressourcen > Cacheinstanzen > Objektcacheinstanzen konfiguriert ist und für die Zwischenspeicherung aller statischen und dynamischen Inhaltsantworten verwendet wird. Diese Objektcacheinstanz muss für die Unterstützung neuer E/A-APIs konfiguriert werden.

SSL-Inhalt zwischenspeichern
  Bestimmt, ob die Antworten für SSL-Verbindungen zwischen dem Client und dem ODR, die vom ODR beendet werden, zwischengespeichert werden.

Aggressives Caching
  Aktiviert das Caching für HTTP-Antworten, die normalerweise nicht zwischengespeichert werden. Caching-Regeln, die nach HTTP 1.1 definiert wurden, können gebrochen werden, um eine Cacheoptimierung zu erzielen.

Dynamischen Inhalt zwischenspeichern
  Bestimmt, ob dynamischer Inhalt, der von WebSphere Application Servern Version 6.02 oder höher generiert wird, zwischengespeichert wird. Das Zwischenspeichern dynamischer Inhalte, die von Content-Servern vor WebSphere Application Server Version 6.02 generiert werden, wird nicht unterstützt.

URI für Cacheaktualisierung
  Wenn Sie dynamische Inhalte zwischenspeichern, ist dies der relative URI einer installierten Content-Server-Anwendung, die verwendet wird, um zwischengespeicherte Einträge ungültig zu machen.

## Komprimierungsrichtlinie

Aktiviert die Komprimierung des Hauptteils von HTTP-Anforderungsnachrichten, bevor diese an den Client gesendet werden.

gzip-only
  Die Antwort wird mit dem Komprimierungsmechanismus "gzip" komprimiert. Die Antwort wird nur komprimiert, wenn sie gemäß Anforderungsheader "Accept-Encoding" für den Client akzeptabel ist.

deflate-only
  Die Antwort wird mit dem Komprimierungsmechanismus "deflate" komprimiert. Die Antwort wird nur komprimiert, wenn sie gemäß Anforderungsheader "Accept-Encoding" für den Client akzeptabel ist.

auto-only
  Je nach Festlegung in den Clientvorgaben wird der Komprimierungsmechanismus "gzip", der Komprimierungsmechanismus "deflate" oder keine Komprimierung verwendet.

## Ausschlüsse

Der ODR untersucht jede eingehende Anforderung. Sie können bestimmte Ausschlussmethoden definieren. Falls die angeforderte HTTP-Methode mit einer der konfigurierten Ausschlussmethoden übereinstimmt, weist der ODR die Anforderungen mit einem Fehler METHOD DISALLOWED zurück.

Inaktivierte HTTP-Methoden
  Standardmäßig sind die Methoden CONNECT, PUT und DELETE inaktiviert.

## Protokollierung

HTTP-Anforderungen werden in einem von drei Protokollen aufgezeichnet: Proxy, Cache oder lokal. Derzeit ist keine lokale Protokollkonfiguration in der Administrationskonsole verfügbar, sondern nur unter ${SERVER_LOG_ROOT}local.log. Geben Sie die Position des Protokolls mit der angepassten Eigenschaft "http.log.localFileName" an. Für die Formatierung der Protokolle wird das allgemeine Protokollformat NCSA (National Center for Supercomputing Applications Common Log) verwendet.

Zugriffsprotokollierung aktivieren
  Wählen Sie diese Option aus, um die Protokollierung zu aktivieren.

Maximale Größe des Zugriffsprotokolls
  Die maximale Protokollgröße in Megabytes (MB). Die Standardeinstellung sind 25 MB.

Proxy-Zugriffsprotokoll
  In diesem Protokoll werden Antworten von fernen Servern aufgezeichnet.

Cachezugriffsprotokoll
  In diesem Protokoll werden Antworten aufgezeichnet, die aus dem lokalen Cache bereitgestellt werden.

Lokales Zugriffsprotokoll
  Enthält den Namen des lokalen Protokolls. Der Wert `NULL` zeigt an, dass das Standardprotokoll `${SERVER_LOG_ROOT}/local.log` verwendet wird. In diesem Protokoll werden alle Antworten aufgezeichnet, die nicht aus dem lokalen Cache bereitgestellt werden, z. B. Umleitungen (Redirects) und interne Fehler. Dieser Inhalt stammt nicht aus dem ODR-Cache.

## Sicherheit

In diesem Abschnitt können Sie Sicherheitsoptionen konfigurieren.

Anerkannte Sicherheits-Proxy-Server
  In einigen Topologien ist oberhalb des ODR eine weitere Weiterleitungsschicht aktiviert. Beispielsweise lesen Webserver die eingehenden Anforderungen, um den ODR zu ermitteln, an den die Anforderungen weitergeleitet werden. Mit dieser Konfiguration können andere zwischengeschaltete Stationen als der ODR die Anforderung verarbeiten, indem der ODR explizit angewiesen wird, diesen Stationen zu vertrauen. Sie können eine IP-Adresse oder einen vollständig qualifizierten Hostnamen angeben.

## Proxy-Richtlinie für Plug-in-Konfiguration

Plug-in-Konfiguration generieren
  Dieser Parameter unterstützt die Generierung einer ODR-Plug-in-Konfigurationsdatei, die in einem Webserver verwendet werden kann, der dem ODR vorgeschaltet ist. Mit dieser Konfigurationsdatei ist das Plug-in in der Lage, den URI zu bestimmen, an dem der ODR stellvertretend für den Anwendungsserver Anforderungen bearbeitet. Außerdem kann das Plug-in den Endpunkt und die Grenzen des ODR bestimmen, um die empfangenen Anforderungen ordnungsgemäß an den ODR weiterzuleiten. Dieses Feature ist hilfreich, wenn Sie einen bewährten Webserver in der Demilitarized Zone (DMZ) implementieren möchten, der die Funktionen des ODR vollständig nutzen kann. Beachten Sie, dass die Konfiguration des ODR in der DMZ nicht unterstützt wird.

  Sie können eine Stufe definieren, auf der das Plug-in generiert werden soll. Für die Zellenebene generiert der ODR eine Plug-in-Konfiguration, die alle URIs enthält, die von allen ODRs in der Zelle verwaltet werden können. Für den Geltungsbereich "Knoten" enthält die Plug-in-Konfigurationsdatei alle URIs, die von den URIs verwaltet werden, die auf demselben Knoten definiert sind wie der ODR, der das Plug-in generiert. Außerdem wird der gesamte Datenverkehr, der von der Plug-in-Konfigurationsdatei weitergeleitet wird, ausschließlich über die ODRs weitergeleitet, die sich auf demselben Knoten befinden wie dieser ODR. Für den Geltungsbereich "Server" enthält die Plug-in-Konfigurationsdatei alle URIs, die ausschließlich von dem ODR verwaltet werden, der das Plug-in generiert. Der gesamte Datenverkehr, der von der Plug-in-Konfigurationsdatei weitergeleitet wird, wird ausschließlich über diesen ODR weitergeleitet.

Script für Änderung der Plug-in-Konfiguration
  Gibt den Pfad zu einem Script an, das nach der Generierung der Plug-in-Konfiguration von WebSphere Application Server ausgeführt wird.

## Richtlinie für angepasste Fehlerseiten

Verwenden Sie dieses Feld, um die Unterstützung benutzerdefinierter Fehlerseiten zu aktivieren, die ausgegeben werden können, wenn während der Verarbeitung der Anforderung Fehler auftreten.

Standardmäßig werden keine benutzerdefinierten Fehlerseiten generiert. Die folgenden Eigenschaften aktivieren die Verwendung benutzerdefinierte Fehlerseiten beim Auftreten von Fehlern während der Anforderungsverarbeitung:

Anwendungs-URI für die Generierung von Fehlerseiten
  Wenn Sie keinen gültigen URI einer installierten Anwendung angeben, verarbeitet die Richtlinie für benutzerdefinierte Fehlerseiten keine Anforderungen.

Ferne Fehler behandeln
  Wenn Sie diese Option nicht auswählen, werden Fehlerstatuscodes für HTTP-Antworten nur verarbeitet, wenn der ODR eine Fehlerantwort generiert. Wenn Sie die Option auswählen, werden Fehlerstatuscodes für HTTP-Antworten verarbeitet, wenn der ODR eine Fehlerantwort generiert und wenn ein Anwendungsserver eine Fehlerantwort generiert. Es empfiehlt sich, eine Anwendung für Fehlerseiten auf derselben Maschine zu konfigurieren, auf der auch der ODR ausgeführt wird.

An Anwendung für Fehlerseiten weiterzuleitende Header
  Gibt zusätzliche Headerwerte aus der Clientanforderung an, die als Abfrageparameter an die Anwendung für Fehlerseiten weitergeleitet werden sollen. Neben den konfigurierten Abfrageparametern werden die Parameter responseCode und URI immer an die Anwendung für Fehlerseiten gesendet. Der Parameter responseCode gibt den HTTP-Statuscode an, der intern generiert oder vom Content-Server zurückgegeben wird. Der Parameter URI gibt den Anforderungs-URI für den Client an.
  Beispiel - Der URI für Fehlerseiten ist `/ErrorPageApp/ErrorPage`, die weiterzuleitenden Header enthalten `Host`, und ein Client sendet die folgende Anforderung:

      GET  /house/rooms/kitchen.jpg HTTP/1.1
      Host:  homeserver.companyx.com
      Die Anforderung führt zu einer Antwort HTTP 404 (lokal oder fern), und der Anforderungs-URI zur Anwendung für Fehlerseiten ist:
      /ErrorPageApp/ErrorPage?responseCode=404&uri=/house/rooms/kitchen.jpg&Host= homeserver.companyx.com

Als Fehler einzustufende HTTP-Statuscodes
  Die Statuscodes, für die die Richtlinie für Fehlerseiten eine Antwort bereitstellt. Wenn ein Statuscode angegeben ist, wird der ursprüngliche Inhalt der Antworten mit diesem Statuscode zurückgegeben. Wenn keine HTTP-Statuscodes angegeben sind, werden die Standardwerte `404` und `5XX` verwendet. Anstatt die Statuscodes einzeln anzugeben, können Sie mit der folgenden Methode einen Bereich von Statuscodes angeben:
  - `5XX: 500-599`
  - `4XX: 400-499`
  - `3XX: 300-399`
  - `2XX: 200-299`

Zugehörige Informationen:
On Demand Router
ODR-Einstellungen
Einstellungen für statische Regeln für On Demand Router
ODR-Objektcacheinstanzen
ODR-Transportketten
ODR-Konfiguration
Statische Cacheregeln für On Demand Router
Neuen On Demand Router erstellen
ODR-Cluster

Dateiname: odr_settings.html