gzip ersetzen?

[Florian]

Hi,

wie kriege ich einen Server dazu, eine vorher schon gezippte HTML-Datei mit dem richtigen Header oder so auszuliefern dass übliche Browser damit klarkommen?

Irgendetwas wie AddType text/x-gzip .gz, weil encoding wird ja nicht mehr benötigt?

Gruß,
Florian

[Michael Schröpl]

Hi Florian,

wie kriege ich einen Server dazu, eine vorher schon gezippte HTML-Datei mit dem richtigen Header oder so auszuliefern dass übliche Browser damit klarkommen?
Irgendetwas wie AddType text/x-gzip .gz, weil encoding wird ja nicht mehr benötigt?

IMHO doch. Denn der Dokumenttyp ändert sich ja nicht dadurch, daß er mit einer "Schale" umgeben ist, welche seine schnellere Übertragung bewirken soll. Das Encoding ist genau das richtige Mittel für die gzip-Komprimierung - wenn Du sie als Schale betrachtest, und nicht als Eigenschaft der Ressource selbst!

Wenn der Browser die HTML-Datei anzeigen soll, mußt Du ihm das über den Content-Type klar machen; verbiegst Du den Content-Type, dann verbiegst Du die (konfigurierbare) Browser-Reaktion, wirst also vermutlich bei vielen Besuchern erreichen, daß die (komprimierte) HTML-Datei zum Speichern auf der Festplatte angeboten wird (oder was auch immer), was wahrscheinlich nicht Deine Absicht war.

mod_gzip hätte Dein Problem übrigens automatisch gelöst und selbst die entsprechenden HTTP-Header zu Deiner statisch vorkomprimierten Datei berechnet.

Viele Grüße
      Michael

[Andreas-Lindig]

Hallo Michael,

mod_gzip hätte Dein Problem übrigens automatisch gelöst und selbst die entsprechenden HTTP-Header zu Deiner statisch vorkomprimierten Datei berechnet.

wie funktioniert das eigentlich mit diesem mod_gzip? Das wird ja hier auch gemacht nicht? Also in der PHP-Doku kommt dieser Begriff nicht vor. Jedenfalls spuckt meine Suche da nichts aus. Kann man das mit PHP überhaupt machen?

Gruß, Andreas

[Michael Schröpl]

Hi Andreas-Lindig,

mod_gzip hätte Dein Problem übrigens automatisch gelöst und selbst die entsprechenden HTTP-Header zu Deiner statisch vorkomprimierten Datei berechnet.
wie funktioniert das eigentlich mit diesem mod_gzip?

http://www.schroepl.net/projekte/mod_gzip/

Das wird ja hier auch gemacht nicht?

Ja. (http://www.schroepl.net/cgi-bin/http_trace.pl?url=http%3A%2F%2Fselfaktuell.teamone.de%2F&method=GET&version=HTTP%2F1.1)

Also in der PHP-Doku kommt dieser Begriff nicht vor.

In der Apache-Dokumentation auch nicht. ;-)

Jedenfalls spuckt meine Suche da nichts aus. Kann man das mit PHP überhaupt machen?

Man kann "es" - limitiert auf PHP-Dateien - auch mit PHP alleine machen (http://www.php-resource.de/manual.php?p=function.ob-gzhandler).

mod_gzip ist im Vergleich dazu das 'Rundum-Sorgenfrei-Komfort-Paket'. ;-)

Viele Grüße
      Michael

[Cyx23]

Hallo Michael,

mod_gzip hätte Dein Problem übrigens automatisch gelöst und selbst die entsprechenden HTTP-Header zu Deiner statisch vorkomprimierten Datei berechnet.
wie funktioniert das eigentlich mit diesem mod_gzip?

http://www.schroepl.net/projekte/mod_gzip/

ist ja ne schöne Sache, aber nach Besuch deiner Seite stellt sich mir dann doch noch die Frage "wie funktioniert das eigentlich mit diesem mod_gzip".
Es erfordert wohl die Einbindung über die Server-Konfiguration, oder lässt sich da auch ein Modul per htaccess nachladen?

Grüsse

Cyx23

[Michael Schröpl]

Hi Cyx23,

Es erfordert wohl die Einbindung über die Server-Konfiguration,

ja.

oder lässt sich da auch ein Modul per htaccess nachladen?

nein.

Lesetip auch für Dich: http://www.schroepl.net/projekte/gzip_cnc/

Viele Grüße
      Michael

[Calocybe]

Moin moin!

mod_gzip hätte Dein Problem übrigens automatisch gelöst und selbst die entsprechenden HTTP-Header zu Deiner statisch vorkomprimierten Datei berechnet.
wie funktioniert das eigentlich mit diesem mod_gzip?

http://www.schroepl.net/projekte/mod_gzip/

Hmm, da steht, es wird anhand der Browserkonfiguration die richtige Sprache fuer mich ausgesucht. Allerdings wird mir die Seite in Deutsch angezeigt, obwohl ich den Header
  Accept-Language: en,de;q=0.5
sende. Erst wenn ich [de] ganz verbiete, bekomme ich die englischen Seiten.
Ich denke, das muss an der Serverkonfiguration liegen. Mein lokaler Apache reagiert naemlich korrekt.

So long

[Michael Schröpl]

Hi Calocybe,

Hmm, da steht, es wird anhand der Browserkonfiguration die richtige Sprache fuer mich ausgesucht.
Ich denke, das muss an der Serverkonfiguration liegen.

angeboten wird "deutsch" und "default" (was dann die englische Version enthält).

Für "englisch" müßte ich die "Default"-Seiten mit anderen Endungen doppelt halten, fürchte ich (ich verwende keine typemaps) - das habe ich bisher nicht für erforderlich gehalten. (Soll ich?)

Viele Grüße
      Michael

[Calocybe]

Moin moin!

Hmm, da steht, es wird anhand der Browserkonfiguration die richtige Sprache fuer mich ausgesucht.
Ich denke, das muss an der Serverkonfiguration liegen.

angeboten wird "deutsch" und "default" (was dann die englische Version enthält).

Oh. Das heisst, der quality-of-source factor fuer die englische Version wird von vornherein schon mal auf 1/1000 runtergesetzt. Klar, dass das dann nicht mehr ausgewaehlt wird, sobald Deutsch vom Client mit q > 0.001 akzeptiert wird.

Für "englisch" müßte ich die "Default"-Seiten mit anderen Endungen doppelt halten, fürchte ich (ich verwende keine typemaps) - das habe ich bisher nicht für erforderlich gehalten. (Soll ich?)

Sicher willst Du die 406-Antwort vermeiden, falls ein Browser weder [en] noch [de] explizit akzeptiert. Die Apache-Doku schlaegt fuer diesen Fall tatsaechlich das zusaetzliche Vorhalten einer Default-Version ohne Language-Attribut vor. Symlinks entschaerfen das Problem zwar ein bisschen. Waere aber schon schoen, wenn man das mit einer zusaetzlichen Direktive einfach konfigurieren koennte. Ich hatte dasselbe Problem auch. Hab mich dann dafuer entschieden, keine Default-Version anzubieten, sodass es ggf. eine 406 gibt. Deine Zielgruppe ist jedoch etwas internationaler, daher waere das wohl kaum angemessen.

Letztlich ist das ganze wohl nicht so schlimm. (Ich les mir von mir aus auch die deutsche Version durch. ;-) ) Es werden ja lediglich die q-Parameter nicht beachtet, wenn jemand sowohl [en] als auch [de] zulaesst. Und wer [de] in der Config erlaubt, wird in den meisten Faellen Deutsch tatsaechlich verstehen, denke ich mal. *g*

So long

[Michael Schröpl]

Hi Calocybe,

Symlinks entschaerfen das Problem zwar ein bisschen.

die habe ich unter Windows 98 bzw NT4 leider nicht.

Bisher funktioniert alles identisch auf meinem Webspace und meinem lokalen Apache (daheim und im Büro) ... ich kann durch Datei-Synchronisation (TotalCommander) die Stände abgleichen und fertig.

Die symbolic links dagegen müßte ich jedesmal manuell setzen (schlimmer noch: Vom Büro aus geht durch die Firewall zwar FTP, nicht aber SSH - ich könnte meine Homepage also nur noch von daheim zuverlässig aktualisieren) und könnte deshalb leicht vergessen, dies konsistent zu tun.

Und wer [de] in der Config erlaubt, wird in den meisten Faellen Deutsch tatsaechlich verstehen, denke ich mal. *g*

Das war auch meine Hoffnung - deshalb war ich gespannt, ob Du schlagende Argumente für die Lösung mit dem expliziten englischen Angebot hast.

Außerdem vermute ich, daß meine deutsche Version sprachlich besser ist als meine englische ... :-\

Viele Grüße
      Michael

[Florian]

Hi Michael,

IMHO doch. Denn der Dokumenttyp ändert sich ja nicht dadurch, daß er mit einer "Schale" umgeben ist, welche seine schnellere Übertragung bewirken soll. Das Encoding ist genau das richtige Mittel für die gzip-Komprimierung - wenn Du sie als Schale betrachtest, und nicht als Eigenschaft der Ressource selbst!

danke, habs jetzt mal mit type+encoding getestet, läuft offenbar. Die minimale Verzögerung bei der Anzeige liegt vermutlich am Browser?

mod_gzip hätte Dein Problem übrigens automatisch gelöst und selbst die entsprechenden HTTP-Header zu Deiner statisch vorkomprimierten Datei berechnet.

Wie gehts überhaupt mit mod_gzip, und könnte auch html als suffix wie für normale html-Dateien genommen werden?
Der Traffic beim Provider wäre wohl nur bei vorkomprimierter Quelle geringer, und geht es denn überhaupt bei einfachen Paketen ohne PHP oder gar ohne CGI?

Gruß,
Florian

[Michael Schröpl]

Hi Florian,

danke, habs jetzt mal mit type+encoding getestet, läuft offenbar. Die minimale Verzögerung bei der Anzeige liegt vermutlich am Browser?

ein unkomprimiertes Dokument kann vom Browser inkrementell angezeigt werden - ein komprimiertes muß erst komplett empfangen und entpackt werden.
Ob dies zu einer Verzögerung führt oder nicht, das hängt von vielen Faktoren ab - insbesondere vom Verhältnis zwischen Dateigröße und Leitungsgeschwindigkeit: Bei großen Dateien über langsame Leitungen wirst Du eine deutlich verbesserte Antwortgeschwindigkeit erleben, bei kleinen (bzw. leicht zu rendernden) Dateien über eine schnelle Leitung kann es insgesamt tatsächlich langsamer werden.

mod_gzip hätte Dein Problem übrigens automatisch gelöst und selbst die entsprechenden HTTP-Header zu Deiner statisch vorkomprimierten Datei berechnet.
Wie gehts überhaupt mit mod_gzip

http://www.schroepl.net/projekte/mod_gzip/

und könnte auch html als suffix wie für normale html-Dateien genommen werden?

Ja. (Als HTML-Seiten-Gestalter merkst Du von der Existenz von mod_gzip überhaupt nichts.)

Der Traffic beim Provider wäre wohl nur bei vorkomprimierter Quelle geringer,

Der Traffic wird beim Einsatz von Komprimierung _immer_ geringer.

Vorkomprimierung verwendet man dann, wenn man den Preis für diese Reduzierung, nämlich den CPU-Aufwand zur Komprimierung, niedrig halten will und die (statische) Natur des zu übertragenden Inhalts dies erlaubt. Ausgaben etwa von PHP- bzw. CGI-Skripten oder Server Side Includes, die erst zur Laufzeit entstehen, können natürlich auch erst danach dynamisch komprimiert werden.

und geht es denn überhaupt bei einfachen Paketen ohne PHP oder gar ohne CGI?

mod_gzip ist eine Erweiterung direkt im Apache-Server - das ist nichts, was ein Anwender selbst hinzufügen könnte.

PHP bzw. CGI erlauben, bestimmte Teile (!) der mod_gzip-Funktionalität selbst zu realisieren; http://www.schroepl.net/projekte/gzip_cnc/ ist ein Beispiel dafür, wie man mit Hilfe von Perl über die CGI-Schnittstelle einen Apache-Handler einbinden könnte, der Deinen Vorstellungen vermutlich recht nahe kommt.

Viele Grüße
      Michael

[Sönke Tesch]

wie kriege ich einen Server dazu, eine vorher schon gezippte HTML-Datei mit dem richtigen Header oder so auszuliefern dass übliche Browser damit klarkommen?

Irgendetwas wie AddType text/x-gzip .gz, weil encoding wird ja nicht mehr benötigt?

Die Kodierungsangabe wird sehr wohl benötigt, schließlich ist Deine Datei doch schon (gzip-)kodiert. Du brauchst also eine AddEncoding-Angabe für .gz ("AddEncoding x-gzip .gz") sowie die AddType-Angabe für .html.
Eigentlich sollte beides schon im Server eingestellt sein, von daher wundert es mich etwas, daß Du damit ein Problem hast. Was passiert denn, wie hast Du die Dateien benannt, wie rufst Du sie ab? Beispiel-URL?

Gruß,
  soenk.e

[Florian]

Hi,

Die Kodierungsangabe wird sehr wohl benötigt, schließlich ist Deine Datei doch schon (gzip-)kodiert. Du brauchst also eine AddEncoding-Angabe für .gz ("AddEncoding x-gzip .gz") sowie die AddType-Angabe für .html.

AddType text/html .gz klappt leider beim IE nicht, AddType application/x-gzip .html kanns doch auch nicht sein?

Gruß,
Florian

[Michael Schröpl]

Hi Florian,

Die Kodierungsangabe wird sehr wohl benötigt, schließlich ist Deine Datei doch schon (gzip-)kodiert. Du brauchst also eine AddEncoding-Angabe für .gz ("AddEncoding x-gzip .gz") sowie die AddType-Angabe für .html.
AddType text/html .gz klappt leider beim IE nicht, AddType application/x-gzip .html kanns doch auch nicht sein?

was bedeutet "klappt nicht"? Wie schon erwähnt, hängt die richtige Konfiguration ganz wesentlich davon ab, was Du auf dem Client _erreichen_ willst - und dafür gibt es mehr als eine Möglichkeit.

Viele Grüße
      Michael

[Sönke Tesch]

Die Kodierungsangabe wird sehr wohl benötigt, schließlich ist Deine Datei doch schon (gzip-)kodiert. Du brauchst also eine AddEncoding-Angabe für .gz ("AddEncoding x-gzip .gz") sowie die AddType-Angabe für .html.

AddType text/html .gz klappt leider beim IE nicht, AddType application/x-gzip .html kanns doch auch nicht sein?

Du bringst da was durcheinander: gzip ist (in Deinem Fall) kein Datentyp, gzip ist eine Kodierung. Dementsprechend solltest Du für gzip AddEncoding benutzen (wie oben bereits geschrieben), nicht AddType.

Weiterhin: Hast Du eine _HTML_-Datei, die mit _gzip_ _kodiert_ wurde, dann mußt Du (rein logisch) der Datei beide Endungen geben, .html _und_ .gz: name.html.gz. Nur so erreichst Du, daß der Server die Datei als HTML-Datei ausliefert (.html=text/html) und dem Browser außerdem mitteilt, daß die Daten gzip-kodiert sind (.gz=gzip).

Willst Du jetzt noch, daß auch Browser das Dokument anzeigen können, die kein gzip verstehen (Suchmaschinen gehören dazu), dann solltest Du..

1. ..in der .htaccess des betreffenden Verzeichnisses die Zeile

options +multiviews

einfügen und..

2. ..die unkomprimierte Variante der Datei mit gleichem Basisnamen, aber doppelter .html-Endung (hier: name.html.html) neben die komprimierte Datei legen.

Die Adressen in Deinen Dokumenten darfst Du _nicht_ ändern!

Es passiert jetzt folgendes: Ein Browser ruft name.html ab, der Server findet keine Datei name.html und beginnt dann dank multiviews damit, gleichnamige Dateien mit weiteren Endungen zu suchen. Er findet name.html.html und name.html.gz und liefert davon automatisch diejenige aus, die dem Browser am besten passt.

Du kannst das Spielchen auch noch auf die Spitze treiben und in Deinen Dokumenten keine Adressen mehr mit Endungen angeben, statt <a href="name.html"> also <a href="name">. Das Prinzip ist dasselbe wie eben beschrieben, Du hast allerdings den Vorteil, daß Du beim Umstieg von HTML auf SHTML, PHP, CGI oder was auch immer nicht mehr sämtliche Adressen ändern mußt.

Gruß,
  soenk.e

[Florian]

Hi,

Du bringst da was durcheinander: gzip ist (in Deinem Fall) kein Datentyp, gzip ist eine Kodierung. Dementsprechend solltest Du für gzip AddEncoding benutzen (wie oben bereits geschrieben), nicht AddType.

Weiterhin: Hast Du eine _HTML_-Datei, die mit _gzip_ _kodiert_ wurde, dann mußt Du (rein logisch) der Datei beide Endungen geben, .html _und_ .gz: name.html.gz. Nur so erreichst Du, daß der Server die Datei als HTML-Datei ausliefert (.html=text/html) und dem Browser außerdem mitteilt, daß die Daten gzip-kodiert sind (.gz=gzip).

also es braucht gar keinen AddType für .gz, und dann gehts genauso auch mit CSS und JS?

Danke schonmal,
Florian

[Michael Schröpl]

Hi Florian,

also es braucht gar keinen AddType für .gz, und dann gehts genauso auch mit CSS und JS?

genau. AddType beschreibt den Content-Type nach Entfernung des Transfer-Encodings, und die im Browser eingestellte Behandlung der übertragenen Ressource soll unabhängig von der Übertragungsform erfolgen. Deshalb möchtest Du .gz als Encoding behandeln und nicht als Content-Type.

Viele Grüße
      Michael