Welche Browser können mit Content-Encoding: gzip umgehen?

Netscape 3

Dieser Browser verwendet HTTP/1.0. Er sendet keinen Accept-Encoding-Header, fordert also von einem Server keine komprimierten Inhalte an.

Der Browser unterstützt die Verarbeitung komprimierter Seiteninhalte noch nicht. Wird ihm gzip-komprimierter Inhalt ausgeliefert, dann erkennt er zwar, daß eine ihm unbekannte Kodierung gzip vorliegt (und zeigt dies dem Benutzer durch eine entsprechende Meldung an), aber anschließend gibt er den komprimierten Inhalt der Seite im Browser-Fenster aus. Für eine unbedingte Auslieferung komprimierter Inhalte (etwa von statisch vorkomprimierten Dokumenten) ist dieser Browser also nicht zu gebrauchen.

Ein Webserver, der den Accept-Encoding-Header korrekt auswertet, ist in der Lage, den Browser mit für ihn darstellbaren, unkomprimierten Daten zu versorgen.

Netscape 4

Dieser Browser verwendet HTTP/1.0. Ab der Version 4.06 sendet er den Header Accept-Encoding: gzip.

Allerdings enthält die Implementierung der Verarbeitung komprimierter Inhalte eine ganze Reihe schwerer Fehler:

In all diesen Fällen scheint Netscape 4 die empfangene, noch nicht dekomprimierte Version zu verwenden; offensichtlich wurde der Aufruf einer (zweifellos vorhandenen) Funktion zur Dekomprimierung des Inhalts an entscheidenden Stellen einfach vergessen.

Und teilweise treten die beschriebenen Fehler nur dann auf, wenn der Browser-Cache auf 0 MB gesetzt und/oder abgeschaltet wurde - es sieht also so aus, als würde Netscape 4 den Browser-Cache als Zwischenspeicher bei der Dekomprimierung verwenden ...

Netscape 6 & 7 und Mozilla 0.9.x & 1.x

Dieser Browser verwendet HTTP/1.1. Seit Netscape 6.2 (= Mozilla 0.9.4) sendet der Browser den Header Accept-Encoding: gzip, deflate, compress;q=0.9.

Mozilla 0.9.9+ und Netscape 7.0PR1 erlauben dem Anwender, sowohl die HTTP-Version als auch den Inhalt dieses Headers in seiner Konfiguration zu definieren; in Mozilla 1.1alpha ist diese Funktion nicht mehr in den Preferences sichtbar, aber über die Konfigurationsdatei defaults/pref/all.js einstellbar (unter dem Namen network.http.accept-encoding).

Die Verarbeitung komprimierter Inhalte funktioniert, wenn der Browser selbst komprimierte Inhalte angefordert hat; ist diese nicht der Fall, dann ignoriert er den HTTP-Header Content-Encoding: gzip, obwohl er den Inhalt dekomprimieren könnte.

Microsoft Internet Explorer 4.0, 5.0, 5.5 and 6.0

Dieser Browser verwendet entweder HTTP/1.0 oder HTTP/1.1, je nach Einstellung in seinen Internet-Optionen. Er sendet den Header Accept-Encoding: gzip, deflate - allerdings nur genau dann, wenn er HTTP/1.1 verwendet.

Die Verarbeitung komprimierter Inhalte funktioniert, wenn der Browser selbst komprimierte Inhalte angefordert hat; ist diese nicht der Fall, dann ignoriert er den HTTP-Header Content-Encoding: gzip, obwohl er den Inhalt dekomprimieren könnte.

Einige ältere Versionen des Internet Explorers scheinen den JavaScript-Event onLoad bereits dann zu feuern, wenn sie eine im <head>-Abschnitt referenzierte JavaScript-Datei erfolgreich empfangen haben, statt auf den erfolgreichen Abschluß der Dekomprimierung ihres Inhalts zu warten.

Opera 3 und 4

Opera 3.5 verwendet HTTP/1.0 und versteht noch keine komprimierten Inhalte.

Seit Version 4 verwendet Opera HTTP/1.1. Opera 4.0beta3 versuchte bereits, in komprimierter Form zu kommunizieren, sendete allerdings den Header TE: deflate, gzip, x-gzip, identity, trailers, d. h. es erwartete gzip-Komprimierung als Anwendung eines Transfer Encoding, nicht als Content Encoding.

Opera 5 und 6

Ab Version 5.12 (oder etwas früher) sendet Opera den Header Accept-Encoding: deflate, gzip, x-gzip, identity, *;q=0. Die Verarbeitung komprimierter Inhalte funktioniert von Version 5 aufwärts ohne bekannte Probleme.

Opera 6 dekomprimiert (als einziger bisher bekannter Browser) den gzip-komprimierten Dokumentinhalte sogar dann, wenn der Server ihn nicht durch die Lieferung des HTTP-Headers Content-Encoding: gzip darauf aufmerksam gemacht hat.

Lynx

Lynx unterstützt gzip-komprimierte Kommunikation seit Version 2.6.

Die ersten Lynx-Versionen starteten zum Dekomprimieren das Systemkommando gzip -d in einem separaten Prozeß. Dies führt natürlich zu Problemen, falls kein gzip-Kommando verfügbar war.

Neuere Versionen von Lynx (ab 1997-08-14, laut CHANGES-Datei von Lynx 2.8.0) verwenden die zlib-Bibliothek zur Dekomprimierung und haben dieses Problem nicht mehr.

(Michael Schröpl, 2002-09-16)