Sie können HTTP- und SOAP-Knoten so konfigurieren, dass sie beim Senden und Empfangen von Nachrichten die HTTP-Komprimierung und -Dekomprimierung verwenden.
Die Knoten können konfiguriert werden, um Anforderungsnachrichten zu komprimieren, Antworten zu akzeptieren und zu dekomprimieren und Eingabenachrichten zu dekomprimieren.
Der HTTP-Transport ermöglicht das Senden komprimierter Daten. Bestimmte Felder im HTTP-Header zeigen an, dass die Daten komprimiert sind und welche Komprimierungstechnik verwendet wurde. Wenn ein HTTP-Client eine HTTP-Anforderung ausgibt, kann er festlegen, dass er komprimierte Antworten annimmt und welche Art von komprimierten Daten er akzeptiert. Die drei vom HTTP-Transport unterstützten Komprimierungstechniken sind GZIP, deflate und compress.
Das Feld Accept-Encoding (Verschlüsselung akzeptieren) in einer HTTP-Anforderung zeigt an, welche Verschlüsselungen in einer Antwortnachricht auf die Anforderung akzeptiert werden. In diesem Feld werden die Werte gzip, deflate, compress und identity angegeben, wobei die Groß-/Kleinschreibung nicht beachtet werden muss. Der Wert identity gibt an, dass die Daten nicht komprimiert werden dürfen. Der Platzhalter * gibt an, dass jede beliebige Verschlüsselung akzeptiert wird. Wenn das Feld Accept-Encoding leer bleibt, bedeutet dies, dass keine Verschlüsselung akzeptiert wird.
Das Headerfeld Content-Encoding bezeichnet die Verschlüsselung der Daten und kann die Token gzip, deflate und compress, nicht jedoch identity enthalten. Bei der Komprimierung der Daten für eine HTTP-Nachricht enthält das Feld Content-Encoding den Namen der verwendeten Komprimierungstechnik, damit der Empfänger das Komprimierungsschema identifizieren und die Nachrichtendaten korrekt dekomprimieren kann.
Das Headerfeld TE in einem Anforderungsheader zeigt an, welche Übertragungsverschlüsselungen für Erweiterungen in einer Antwort akzeptiert werden. Dies ist ähnlich wie im Feld Accept-Encoding.
Das Feld Transfer-Encoding hat eine ähnliche Funktion wie das Feld Content-Encoding, abgesehen davon, dass es eine Eigenschaft der Nachricht, nicht der Entität, bezeichnet. Mit dem Feld Transfer-Encoding wird vor allem darauf hingewiesen, dass eine Antwortnachricht in Blöcke aufgeteilt ist. Möglicherweise wird ein Transfer-Encoding-Header mit anderen Übertragungsverschlüsselungen wie zum Beispiel "chunked, gzip" empfangen. In diesem Fall bezieht sich gzip auf die Übertragung der Daten, nicht auf die Daten selbst.
WebSphere Message Broker unterstützt die Komprimierung und Dekomprimierung bei HTTP- und SOAP-Knoten und verwendet die Felder Accept-Encoding und Content-Encoding dabei wie folgt:
Bei der Komprimierung einer HTTP-Anforderungsnachricht überprüft der Knoten im Feld Content-Encoding, ob die Nachrichtendaten bereits komprimiert wurden. Wenn die Daten bereits im angegebenen Schema komprimiert wurden, ist keine weitere Komprimierung erforderlich. Wenn die vorhandenen Daten jedoch mit einer Verschlüsselung komprimiert wurden, die nicht in den Knoteneigenschaften festgelegt wurde, komprimiert der Knoten den bereits komprimierten Bitstrom wiederum mit der für ihn angegebenen Verschlüsselung. Der Wert des Feldes Content-Encoding wird aktualisiert und zeigt die zusätzliche Verschlüsselung der Daten an. Der Wert deflate,gzip im Feld Content-Encoding zeigt beispielsweise an, dass die Nachricht zunächst mit 'deflate' und anschließend mit 'gzip' dekomprimiert werden muss.
Die HTTP- und SOAP-Knoten unterstützen keine Qualitätswerte im Feld Accept-Encoding, mit denen ein Benutzer eine bevorzugte Gewichtung von Komprimierungsarten für Antworten angeben kann. Alle angegebenen Qualitätswerte im Feld Accept-Encoding werden ignoriert.
Die Anforderungsknoten können komprimierte Antworten anfordern und verarbeiten. Sie können die Anforderungsknoten konfigurieren, um die erlaubte Komprimierung in Antworten anzuzeigen und eine automatische Dekomprimierung einer komprimierten Antwort durch den Knoten zu ermöglichen. Im Header Accepts-Encoding wird festgelegt, dass die Komprimierungstechniken GZIP und deflate akzeptiert werden. Wenn der Header Accept-Encoding bereits festgelegt wurde, wird er vom Knoten nicht überschrieben.
Wenn ein Anforderungs- oder ein AsyncResponse-Knoten eine mit GZIP oder deflate komprimierte Antwort erhalten, wird diese dekomprimiert und alle Hinweise im Header, dass die Nachricht komprimiert ist, werden entfernt. Wenn die Knoten eine nicht gültig komprimierte Antwort empfangen oder eine nicht erkannte Komprimierungsfunktion erhalten, tritt eine Ausnahmebedingung auf, die angibt, dass die Daten nicht dekomprimiert werden konnten.
Die Anforderungsknoten können auch komprimierte Anforderungen senden. In der Konfiguration des Knotens können Sie angeben, welche Komprimierungstechnik für die gesendeten komprimierten Anforderungen verwendet werden soll. Der festgelegte Wert im Header Content-Encoding zeigt an, welche Komprimierung verwendet wurde. Diesen Wert können Sie in der lokalen Umgebung für eine einzelne Nachricht überschreiben. Wenn Sie die lokale Umgebung durch einen Wert überschreiben, den der Knoten nicht erkennt, wird der vorhandene Wert für die zu verwendende Komprimierung eingesetzt.