nicht angemeldet
Moin
Eigentlich brauchst Du jetzt nur noch den HTTP-Header abzufragen:
if ($ENV {'HTTP_ACCEPT_ENCODING'} =~ /\bgzip\b/)
[X] done
und dann müßte man noch irgendwie alle Ausgaben in einen Puffer umlenken.
(Kann man in Perl irgendwie STDOUT an einen eigenen Treiber binden?)
Isch kann doch gar kein perl :) Ich bastle aber grade an einem Beispielscript dass das mehr oder weniger hinkriegt. Code kommt sobald er funktioniert.
Kann vielleicht ein Perlophile noch was dazu sagen?
Fein. Dasselbe jetzt bitte noch mit Netscape 4.5 und M$IE 5.0 (mindestens)
testen, dann wird die Aussage wahrscheinlich schon ziemlich interessant.
Ich habe solche Altgüter zwar nicht mehr auf der Platte (nicht mal ein Windows) probier das aber mal zu Hause bei meinem Vater aus.
Leider nein.
Ich vermute, der Apache weiß, daß er eine dynamisch lange Ausgabe produ-
ziert (er führt ja gerade ein CGI-Skript aus) und hofft, daß hinter ihm
niemand mehr etwas puffern muß (an ein eventuelles mod_gzip denkt er
nicht präventiv).
Wie ich grade herausgefunden habe ist der Indianer hier schlauer als man denken mag. Wenn das Skript einen Content-Length:-Header sendet, gibt er diesen an den Client weiter und spart sich das chunken. Die 1.1-Antwort an 1.0-Clients bleibt davon aber unberührt.
Hoppla - wie passen die beiden obigen Aussagen zusammen?
(Mich wundert auch, daß der Apache eine HTTP/1.0-Anfrage in HTTP/1.1 zu
beantworten versucht - ich dachte, der Server darf nur 'dümmer' antworten,
nicht aber 'schlauer'?)
Hmm, das hat mich auch gewundert. Im RFC 2616 hab ich dazu nur gefunden 'Applications that are at least conditionally compliant with this specification SHOULD use an HTTP-Version of "HTTP/1.1" in their messages, and MUST do so for any message that is not compatible with HTTP/1.0.', dass er also HTTP/1.1 verwenden muss, wenn die kommende Nachricht nicht mit 1.0 kompatibel ist. Da das hier aber nicht der Fall ist, sehe ich den Grund dafür auch nicht. Bug?
--
Henryk Plötz
Grüße aus Berlin