nicht angemeldet
Hi Henryk,
interessante Experimente, die Du da machst - danke schön!
Eigentlich brauchst Du jetzt nur noch den HTTP-Header abzufragen:
if ($ENV {'HTTP_ACCEPT_ENCODING'} =~ /\bgzip\b/)
und dann müßte man noch irgendwie alle Ausgaben in einen Puffer umlenken.
(Kann man in Perl irgendwie STDOUT an einen eigenen Treiber binden?)
Ich sehe bei Chunked keine Probleme.
Ich schon - weil Du eben nicht nur einen einzigen nagelneuen Browser
testen darfst, sondern _alle_ testen müßtest.
Dein Mozilla 0.9.8 kann ja auch schon "AuthType: Digest" ...
Content-Encoding: gzip
Transfer-Encoding: chunked
Fein. Dasselbe jetzt bitte noch mit Netscape 4.5 und M$IE 5.0 (mindestens)
testen, dann wird die Aussage wahrscheinlich schon ziemlich interessant.
Da die Daten scheinbar alle in einen Buffer passen, kommt nur ein
Chunk und danach der Abschluss-Chunk mit der Länge 0.
Fällt dir vielleicht ein Weg ein, wie man bei diesem Fall das doch
recht sinnfreie Chunking abschalten kann?
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).
Falls dies alles zutrifft und er Chunking verwendet, kann den HTTP-Header
schon vor der Ausführung des Skripts erzeugen - daß er dann auch den Son-
derfall mit nur einem Chunk produziert, muß "im Etat drin" sein. Er kann
ja schlecht in die Zukunft sehen und prüfen, ob er das Chunking brauchen
wird oder nicht ...
HTTP/1.1 200 OK
Danach kommen die gezippten Daten, ungechunkt (weil Chunked bei HTTP
1.0-Clients nicht zwangsweise unterstützt werden muss).
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'?)
Viele Grüße
Michael