Source Code zippen - Welche Browser unterstützen das?
Sebastian Adam
- browser
Hallo,
ich habe gehört, dass man bei neueren Browsern den HTML-Code zippen kann, bevor er übertragen wird. Der komprimierte Code wird dann vom Browser automatisch erkannt und entpackt bevor er dargestellt wird.
Kann mir jemand sagen, welche Browser(versionen) diese Technologie unterstützen - weiss es bis jetzt nur von Mozilla.
Thx for any support
Sebastian
Moin Moin !
Hallo,
ich habe gehört, dass man bei neueren Browsern den HTML-Code zippen kann, bevor er übertragen wird. Der komprimierte Code wird dann vom Browser automatisch erkannt und entpackt bevor er dargestellt wird.
Ja, aber nicht mit dem PKZIP-Algorithmus, sondern mit dem GNU-ZIP-Algorithmus (gzip).
Kann mir jemand sagen, welche Browser(versionen) diese Technologie unterstützen - weiss es bis jetzt nur von Mozilla.
Das können auch andere. Und sie sagen sogar, ob sie es können.
Lies mal http://schroepl.net/projekte/gzip_cnc/
Alexander
Hi,
ich habe gehört, dass man bei neueren Browsern den HTML-Code zippen kann, bevor er übertragen wird. Der komprimierte Code wird dann vom Browser automatisch erkannt und entpackt bevor er dargestellt wird.
Kann mir jemand sagen, welche Browser(versionen) diese Technologie unterstützen - weiss es bis jetzt nur von Mozilla.
Diejenigen, die dies dem Webserver in HTTP_ACCEPT_ENCODING mit dem Teilstring "gzip" mitteilen.
Nur wenn das der Fall ist, darf der Webserver gzip verwenden...
cu,
Andreas
Diejenigen, die dies dem Webserver in HTTP_ACCEPT_ENCODING mit dem Teilstring "gzip" mitteilen.
Thx, die Frage ist, wie überprüfe ich das? Gibt es nicht irgendwo im Netz eine Liste?
Gruß
Sebastian
Hi,
Diejenigen, die dies dem Webserver in HTTP_ACCEPT_ENCODING mit dem Teilstring "gzip" mitteilen.
Thx, die Frage ist, wie überprüfe ich das?
Indem Du von Deinem Script eben diesen Wert angucken läßt?
Gibt es nicht irgendwo im Netz eine Liste?
Ich kann Dir nur sagen, was meine Browser machen:
gzip in HTTP_ACCEPT_ENCODING: IE 5.5, Mozilla 1.2.1, Opera 6.03, Opera 6.05, Netscape 4.76, Lynx 2.8.2
KEIN gzip (weil kein HTTP_ACCEPT_ENCODING): IE 6.0
(der IE 6.0 vom Kollegen [identische Version] schickt aber diesen header mit und da steht auch gzip drin...)
Aber selbst wenn Du weißt, daß der Browser X das prinzipiell kann, darfst Du nur dann gzip-Komprimiert senden, wenn der Browser X Dir das über HTTP_ACCEPT_ENCODING auch mitgeteilt hat.
cu,
Andreas
Hi Sebastian,
Diejenigen, die dies dem Webserver in HTTP_ACCEPT_ENCODING mit dem Teilstring "gzip" mitteilen.
Thx, die Frage ist, wie überprüfe ich das?
http://www.schroepl.net/cgi-bin/http_trace.pl
Gibt es nicht irgendwo im Netz eine Liste?
http://www.schroepl.net/projekte/mod_gzip/browser.htm
Viele Grüße
Michael
Hi MudGuard,
Kann mir jemand sagen, welche Browser(versionen) diese Technologie unterstützen - weiss es bis jetzt nur von Mozilla.
Diejenigen, die dies dem Webserver in HTTP_ACCEPT_ENCODING mit dem Teilstring "gzip" mitteilen.
naja - das kommt darauf an, wie Du "unterstützen" interpretierst:
http://www.schroepl.net/projekte/mod_gzip/browser.htm#Netscape4
Nur wenn das der Fall ist, darf der Webserver gzip verwenden...
Streiche "darf", setze "sollte". Laut RFC2616 _darf_ der Webserver durchaus auch ein nicht unterstütztes Encoding ausliefern; es ist allerdings guter Stil, Negotiation zu machen, wenn der Browser entsprechende Angaben in seinem "Accept-Encoding:"-Header liefert.
Viele Grüße
Michael
hi
naja - das kommt darauf an, wie Du "unterstützen" interpretierst:
http://www.schroepl.net/projekte/mod_gzip/browser.htm#Netscape4
wenn man sich ansieht, was manche Browser so mit RFCs anstellen, weiß man nicht, ob man lachen oder weinen soll. Es ist ja bekanntlich für uns Menschen schwer, nicht mehr zu behaupten, als wirklich da ist, aber muss das Software - insbesondere Browser unbedingt nachmachen?
Grüße aus Bleckede
Kai
Hi Sebastian,
Kann mir jemand sagen, welche Browser(versionen) diese Technologie unterstützen - weiss es bis jetzt nur von Mozilla.
http://www.schroepl.net/projekte/mod_gzip/browser.htm
Und beim M$IE hängt es von dessen Konfiguration ab:
http://www.schroepl.net/projekte/msie/
Viele Grüße
Michael
Hi,
Und beim M$IE hängt es von dessen Konfiguration ab:
http://www.schroepl.net/projekte/msie/
Danke, das erklärt, warum mein IE 6 nicht wollte und der des Kollegen schon - meiner hat nen Proxy, aber HTTP1.1 für Proxies abgeschaltet...
cu,
Andreas
ich habe gehört, dass man bei neueren Browsern den HTML-Code zippen kann, bevor er übertragen wird. Der komprimierte Code wird dann vom Browser automatisch erkannt und entpackt bevor er dargestellt wird.
Kann mir jemand sagen, welche Browser(versionen) diese Technologie unterstützen - weiss es bis jetzt nur von Mozilla.
So gut wie alle halbwegs weit verbreiteten. Und zwar seit Jahren. Die Funktionsweise gehört zum HTTP-Standard.
Du benötigst dazu allerdings entweder gzip (nicht WinZip), um die Dateien vorzukomprimieren, oder alternativ (beim Apache) mod_gzip im Server zur automatischen Komprimierung.
Vorkomprimierte Dateien legst Du mit der zusätzlichen Endung .gz neben die unkomprimierte Dateiversion und schaltest in der Serverkonfiguration mit "options +multiviews" die Inhaltsverhandlung ein. Der Server wählt dann automatisch die richtige (genauer gesagt: kleinste) Datei zur URL. Allerdings wird dieser Mechanismus nur in Gang gesetzt, wenn die URL _nicht_ auf eine existierende Datei zeigt. Du mußt also entweder alle Verweise von beispielsweise "seite.html" in "seite" ändern oder den Dateinamen der unkomprimierten Seite von "seite.html" in "seite.html.html" ändern.
Gruß,
soenk.e
Hi Sönke,
Du benötigst dazu allerdings entweder gzip (nicht WinZip), um die Dateien vorzukomprimieren, oder alternativ (beim Apache) mod_gzip im Server zur automatischen Komprimierung.
... oder ein beliebiges anderes System zur Herstellung dieser Dateien, etwa
http://www.schroepl.net/projekte/gzip_cnc/
Allerdings wird dieser Mechanismus nur in Gang gesetzt, wenn die URL _nicht_ auf eine existierende Datei zeigt. Du mußt also entweder alle Verweise von beispielsweise "seite.html" in "seite" ändern oder den Dateinamen der unkomprimierten Seite von "seite.html" in "seite.html.html" ändern.
Bei mod_gzip ist das nicht notwendig (das macht seine Negotiation auf Wunsch selbst, und dann zwischen "seite.html" und "seite.html.<endung>", letztere ist konfigurierbar).
Die (aktuelle Version 1.3.26.1a von) mod_gzip ist übrigens in der Lage, die statisch vorkomprimierte Version automatisch zu aktualisieren, wenn sich die unkomprimierte Version geändert hat - genau wie gzip_cnc.
Viele Grüße
Michael
hi
ich habe gehört, dass man bei neueren Browsern den HTML-Code zippen kann, bevor er übertragen wird. Der komprimierte Code wird dann vom Browser automatisch erkannt und entpackt bevor er dargestellt wird.
Kann mir jemand sagen, welche Browser(versionen) diese Technologie unterstützen - weiss es bis jetzt nur von Mozilla.
erklären wir das Ganze mal grob (vermutlich wird jetzt einiges wiederholt..)
Es gibt 2 Wege hierso, einen automatischen über ein Apache-Modul (mod_gzip), das die Dateien wahlweise komprimiert vorhält, oder beim Versenden komprimiert und einen manuellen, über selbstkomprimierte Dateien und Content-Negotiation (oder irgendwelche Scripte, die dies erledigen). Die Bedingungen an den Browser sind die gleichen:
1. er muss sagen, dass er kompromierte Daten verträgt (accept=gzip)
2. er muss sie wirklich verstehen
....wie so oft bei Browsern, sind diese beiden Punkte nur in der Theorie voneinander abhängig.
Typ 1, der hamlose: Browser kann weniger, als er sagt
Hierzu muss bei der manuellen Lösung die Datei zusätzlich unkomprimiert vorliegen, bei der automatischen muss man sich um nichts kümmern. Ist also nur ärgerlich, wenn man damit Platz sparen wollte.
Ein Beispiel für dieses Verhalten ist der MSIE6, wieso wissen die Götter.
Typ 2, der schwachsinnige: Browser, die meinen sie könnten
Viel ärgerlicher ist dieser Typ, denn der Browser sagt dem Server ausdrücklich, er will komprimierte Daten haben, ist dann aber zu doof sie zu verarbeiten. Ein besonderes Glanzlicht dabei ist Netscape 4 (siehe Michaels Link), der grob gesagt keine Zusatzdateien (CSS, JS) dekomprimieren kann. Ähnlich dämlich soll sich der Browser des QNX-Systems anstellen, der meint zwar, er könne, aber der kann nun gar nichts mit den Daten anfangen.
Die Netscape 4-Probleme sind nur bei einigen Versionen, Probleme, die seit 4.5 gefixt sind, kann man imho völlig ignorieren, die erst seit 4.7 weg sind, sollte man zumindest bedenken. Das QNX-Wunder kann man ignorieren (die User kennen das und wer den Kram nicht von 'nem Proxy ausfiltern läßt, dem ist auch nimma zu helfen). Apropos Proxy: diese Dinger machen auch gerne viel Mist - einige werfen auch gleich den gesamten accept=-Kram raus - aus Serversicht kann der Browser dann gar nix :)
Grüße aus Bleckede
Kai
Hallo Kai,
Typ 1, der hamlose: Browser kann weniger, als er sagt
...
Ein Beispiel für dieses Verhalten ist der MSIE6, wieso wissen die Götter.
ich vermute, die M$-Programmierer betrachten Content Encoding als HTTP-1.1-Konzept (was es nicht ist, siehe http://www.freesoft.org/CIE/RFC/1945/52.htm), und unterstützen es deshalb nur in diesem Betriebsmodus. Selber schuld ...
Ein besonderes Glanzlicht dabei ist Netscape 4 (siehe Michaels Link), der grob gesagt keine Zusatzdateien (CSS, JS) dekomprimieren kann.
Das wäre ja noch nicht schlimm - das kann man ja serverseitig berücksichtigen (beispielsweise, indem man solche Dateien mit SSI einbindet).
Viel schlimmer finde ich, daß er komprimiertes HTML zwar rendern kann, nicht aber drucken - mach Du _das_ mal einem Kunden klar ...
Die Netscape 4-Probleme sind nur bei einigen Versionen
Ich kenne _kein_ Netscape-4-Problem bezüglich gzip, das ich nicht auch in 4.8 reproduzieren könnte.
Apropos Proxy: diese Dinger machen auch gerne viel Mist - einige werfen auch gleich den gesamten accept=-Kram raus - aus Serversicht kann der Browser dann gar nix :)
Schluchz ... wir haben diverse Kunden, die ihren Netzwerkzugang an Fremdfirmen outgesourced haben, welche ihre Proxies entsprechend restriktiv eingestellt haben. :-(
Und das Problem
http://www.schroepl.net/projekte/mod_gzip/firewalls.htm
macht die Sache leider auch nicht einfacher ...
Viele Grüße
Michael