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 vielen Versionen 4.x werden Cascading Style Sheets, welche durch den HTML-tag
<link rel="stylesheet" type="text/css" href="dateiname" />
aus einer separaten Datei hinzu geladen werden, nicht dekomprimiert und damit nicht ausgewertet.
In vielen Versionen 4.x wird JavaScript-Code, welcher durch den HTML-tag
<script type="text/javascript" src="dateiname" />
aus einer separaten Datei hinzu geladen werden, nur dann dekomprimiert und ausgewertet, wenn im Browser ein Cache aktiviert ist.
(Bei aktiviertem JavaScript im Browser kann dieses Problem zusätzlich zu JavaScript-Fehlermeldungen führen, falls im HTML-Quelltext Bezug auf Definitionen des eingebundenen JavaScript-Codes genommen wird.)
In vielen Versionen 4.x wird vor dem Drucken des Seiteninhalts der HTML-Code des Dokuments nur dann dekomprimiert, wenn im Browser ein Cache aktiviert ist; dasselbe gilt für die Darstellung des Seiteninhalts im Print-Preview-Modus.
In vielen Versionen 4.x arbeitet die Darstellung des HTML-Quelltextes des aktuellen Dokuments nur dann korrekt, wenn im Browser ein Cache aktiviert ist. Andernfalls wird statt des Quelltextes ein leerer Bildschirm angezeigt
In vielen Versionen 4.x kann (unter schwer reproduzierbaren Umständen) die korrekte Verarbeitung von gzip-komprimierten Bildern fehlschlagen. (Allerdings sollten Bilder ohnehin manuell optimiert werden, etwa durch Auswahl des geeignetsten Dateiformats, Verwendung einer kleinstmöglichen Farbtiefe etc. - die gzip-Komprimierung eines bereits komprimierten Dateiformats bewirkt keine nennenswerte Einsparung mehr.)
In den Versionen 4.06 bis 4.08 gibt es sogar Probleme mit der Verarbeitung von JavaScript-Code innerhalb des <head>-Abschnitts komprimierter HTML-Seiten selbst.

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.

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)

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