HTTP Kompression verstehen

Seite komprimiert ausliefern

Die Theorie ist klar: Komprimierte Webseiten sind offensichtlich ein Muss. Nun ist es gut und schön dass sich HTML prima komprimieren lässt . doch wie macht man das konkret? Einfach nur gzip oder WinZip anwerfen und Dateien vor dem Hochladen zum Webserver komprimieren reicht leider nicht aus . und dummerweise werfen komprimiert ausgelieferte Seiten auch das ein oder andere Problem auf. Es steht also auch ein bisschen Ärger an.

Zunächst einmal muss man wissen dass die Auslieferung von HTML Seiten in kodierter Form generell kein Problem darstellt. Dabei kann es sich im Prinzip um eine beliebige Kodierung handeln . die Kompression ist nur eine Spezialform der Kodierung. Um genau zu sein ist sogar die ganze normale Plaintext Form nur eine Spezialform der Kodierung, nämlich die Spezialform Ohne besondere Kodierung.

Beim Kodieren einer Webseite unterscheidet man zwischen dem Content-Encoding und dem Transfer-Encoding. Beim Content-Encoding geht es darum den Inhalt vor der Auslieferung zu kodieren, während beim Transfer-Encoding der Inhalt im Zuge der Übertragung kodiert wird. Für die Komprimierung von Webseiten hat diese Unterscheidung in der Praxis aber keine Auswirkung, da die viele Webseiten ohnehin dynamisch erzeugt werden wenn man sie abruft. Eine Unterscheidung zwischen dem Zustand vor und während der Auslieferung wird da etwas schwierig. Aus diesem Grund wird im Folgenden auch immer von Transfer-Encodinggesprochen, auch wenn es sich in einigen der angesprochenen Fälle eigentlich um ein Content-Encoding handelt.

Beim Transfer Encoding ist es gleichgültig ob die Kodierung nun eine Verschlüsselung, eine Komprimierung oder irgendein anderes Verfahren darstellt. Wichtig ist allerdings dass der Client (also der Browser des Surfers) im Zuge des Requests mitgeteilt hat, dass er eine bestimmte Form des Encodings verarbeiten kann.

Die Komprimierungsverfahren

Für die Komprimierung gibt es ein extra standardisiertes Verfahren . eigentlich sogar zwei, die die Namen gzip beziehungsweise deflate tragen. Beide sind Teil des HTTP 1.1 Standards, der von allen gängigen Browsern unterstützt wird. Um genau zu sein unterstützen zumindest alle gängigen Browser Transfer-Encoding im gzip Format über HTPP 1.1. Wie das bei Browsern immer so ist gibt es natürlich Probleme. Zum Beispiel behaupten einige ältere Browser mit HTTP 1.1 klarzukommen, tun das aber nicht. Im Wesentlichen ist es aber so, dass praktisch alle Microsoft Browser ab dem Internet Explorer 4.0 und alle Netscapes der Version 3.0 das Protokoll unterstützen. Um auch auf etwas ausgefallenere Browser einzugehen: Sogar der textbasierte Lynx-Browser kommt mit Transfer-Enconding in HTTP 1.1 Verbindungen prima klar. Es gibt allerdings einen Sonderfall der zu beachten ist, doch dazu später mehr.

br>

Beide http 1.1 Optionen müssen im IE eingeschaltet sein.

Meldet sich hingegen ein Browser als HTTP 1.0 kompatibler Client am Server an, braucht der Server einfach nur weniger zu tun. Im Wesentlichen muss dann der Komprimierungsschritt entfallen, so dass die Seite dann in ihrer normalen Form ausgeliefert wird.

Das war das Stichwort: Komprimierungsschritt. Es drängt sich natürlich immer mehr die Frage auf, wie man die Komprimierung eigentlich einrichtet. Auf diese Frage gibt es natürlicher- und unumgänglicherweise mehrere Antworten, und welche Antwort auf einen gegebenen Server zutrifft ist davon abhängig, welcher Webserver zum Einsatz kommt. Im Folgenden finden Sie daher zwei Erklärungen: Eine für den IIS 5/6 von Microsoft und eine weitere für den Apache 1.3.x.