nicht angemeldet
Hi Henryk,
hm ... das ist nicht so einfach.
Hmm, bei PHP scheint das aber durchaus einfach zu sein :) (s.u.)
Die beschränken sich halt auf einen stark reduzierten Einsatzfall.
Und wer behauptet, daß das Verfahren in jedem Fall funktioniert?
Schick doch mal ein mit PHP generiertes JavaScript an einen Netscape4 ...
Die Request-Header sollten in einem Skript doch wohl zu bekommen sein?
Klar.
Wenn da ein Header
Accept-Encoding: gzip
gesendet wird, dann versichert mir der Client das er diese Kodierung
versteht und bereit ist sie zu aktzeptieren. Wenn er das nicht ist,
dann ist es so, dass er entweder a) lügt oder b) kein HTTP kann.
Netscape 4.06-4.79 lügt, daß sich die Balken biegen.
Auch einige M$IE verhalten sich in gewissen Fällen "kreativ".
Was HTML oder nicht-HTML angeht: Spielt das denn überhaupt eine Rolle?
Ja, leider.
Diese Kodierung ist doch nur für die Übertragung da, und wird nach dem
Empfang sofort wieder entfernt.
Was auch immer hinter dem HTTP-Teil des Clients liegt, sollte davon
nichts mehr mitkriegen.
Tja, sag das mal den Programmierern der Browser.
Schau einfach mal in den Browser-Cache, wenn Du komprimierte Sachen saugst.
Allenfalls die Nutzlosigkeit des gzippens von JPEG-Daten erscheint mir
problematisch,
Sofern dabei die Daten nicht unbrauchbar werden (auch solche Browser gibt
es), ist das lediglich Zeitverschwendung.
Auch da sehe ich ein Problem nicht. Lass den Server tun, was er
normalerweise tut. Er kennt doch auch sonst einen Weg die Daten
irgendwie zum Client zu schaffen, auch wenn das Skript nicht
komprimiert.
Den darf er aber leider nicht bedenkenlos verwenden.
Der einzige Unterschied ist a) die Daten sind anders (das geht den
Server aber nichts an, da er sich die Daten normalerweise auch nicht
anschaut) und b) es muß _ein_ zusätzlicher Header gesendet werden:
Content-Encoding: gzip
und auch da mischt sich der Server doch normalerweise nicht ein?
Ja. Aber Du müßtest wissen, ob Du den Header senden darfst. Das weißt Du
nur dann sicher, wenn Du selbst der Webserver bist (siehe unten).
Das mit der Länge muss der Server so halten, wie immer:
a) HTTP/1.1, dann geht in jeden Fall Tranfer-Encoding: chunked
Theoretisch erlaubt HTTP natürlich die gleichzeitige Verwendung von Trans-
fer- und Content-Encoding, ja. Theoretisch erlaubt es auch die Verwendung
von beliebig vielen Content-Encodings (man darf sie also schachteln).
Aber kennst Du einen Browser, der das überlebt?
mod_gzip buffert die gesamten Chunks und faßt sie zu einem Paket zusammen.
(Natürlich nur, wenn man das in der Konfiguration so eingestellt hat; an-
dernfalls läßt es die Finger von allem, was irgend ein Encoding besitzt.)
Das alles geht das Skript aber nichts an, da es ja einfach bloß Daten
liefern muß.
Wäre es nicht schön, wenn der Browser diese Daten auch lesen könnte?
(Und dabei nicht abstürzt?)
if(preg_match("/gzip/", $HTTP_SERVER_VARS["HTTP_ACCEPT_ENCODING"])) {
// Herausfinden, ob der Client komprimierte Daten will
header("Content-Encoding: gzip");
echo gzencode($content); // Komprimieren und senden
} else echo $content;
Tja, damit wirst Du den einen oder anderen Browser nicht glücklich machen.
Aber falls das nicht wichtig ist, würde es so funktionieren.
Und du willst mir doch wohl nicht erzählen dass ein fest kompiliertes
Modul, dass sich nur über die Serverkonfigurationsdatei konfigurieren
lässt, flexibler ist, als etwas dass du selbst in den Scriptcode
schreibst?
mod_gzip versendet ja nicht nur die Daten Deines einen Skripts, von dem
Du zufällig gerade weißt, was es versendet.
mod_gzip versucht, für Dutzende verschiedener Arten von Daten, Übertra-
gungsmodalitäten, Erzeugungsmethoden usw. das 'Richtige' zu tun, eben
damit niemand alles umschreiben muß.
In Perl müsste das alles ähnlich oder äquivalent gehen, auch wenn ich
keinen blassen Schimmer hätte, wie ich etwas ähnliches wie die Output-
bufferingfunktionen implementieren sollte.
In diesem Bereich wüßte ich aus dem Kopf auch nichts Passendes.
Die Probleme sehe ich aber woanders - und einige davon kann auch mod_gzip
nicht lösen.
Was hältst Du denn z. B. von Caching von gzipped content in Proxies?
Ich habe bei Deinem Skript oben keinen "Vary:"-Header gesehen ...
Sicherlich kannst Du ein Perl-Skript einfach komprimierte Daten versenden
lassen. Und vielleicht verstehen das auch die meisten der modernen Browser.
Viele Grüße
Michael