Welche Browser können mit 'Content-Encoding: gzip' umgehen?
Author: Michael Schröpl
Description: Eine Beschreibung des Verhaltens der verbreitetsten Web-Browser bezüglich komprimierter Seiteninhalte
Keywords: Browser, HTTP, Kodierung, gzip, Komprimierung

# 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.

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)