[php] Flush() in Tabellen

[Stefan Roehrich]

On 2002-05-12 20:15:26, Jens Benecke wrote:
> Hm. Ich habe es bisher immer als größeren Vorteil gesehen,
> Content-Encoding: gzip zu benutzen und dafür die zusätzliche Sekunde am
> Anfang zu warten, bis der Output komplett vorhanden ist und gesendet
> werden kann.

Wenn Du dazu die PHP-Funktionen benutzt, wird auch nur unter gewissen
(seltenen) Umständen ein Content-Length-Header benutzt. Normalerweise
wird auch bei zlib.output_compression nicht gewartet, bis alles da
ist, sondern bis der output buffer voll ist, der dann komprimiert und
zum Client geschickt wird, dann wird ebenso mit dem nächsten Happen
verfahren.

> > Wenn man nun kein chunked transfer encoding hätte, wären keine
> > persistende Verbindungen zwischen HTTP-Client und -Server möglich;
> HTTP ist doch sowieso zustandslos, sonst bräuchten wir den ganzen Krampf
> mit Sessions usw. nicht.

Zum Zustandspeichern sind persistene Verbindungen auch nicht gedacht.

> Hm. Dazu wieder - die Browser, die ich kenne (Konqueror, Mozilla, IE)
> machen sowieso anscheinend mehrere Sockets parallel auf und fangen schon
> an Bilder zu ziehen, sobald die <img...>-Tags vollständig drüben sind,
> und nicht erst wenn die HTML-Datei komplett da ist.

Aber auch das ist oft in der Anzahl begrenzt. Und Verbindungsaufbau
ist schon ein Overhead (denk Dir dann z.B. noch SSL dazu ...), zumal
Du ja noch TCP-Slowstart oder ähnliches hast. Die Vorteile der
persistenten Verbindungen kannst Du Dir in Section 8.1.1 von RFC 2616
anschauen ;-).

Außerdem, so aufwendig ist chunked encoding nicht zu implementieren ;-).

Tschüs
  Stefan

-- 
Stefan Röhrich               stefan_(at)_roehri.ch, sr_(at)_linux.de
                                 http://www.roehri.ch/~sr/