ESP schrieb:
> wie muss man denn eine Seite aufbauen, die in mehreren Paketen geschickt
> wird?
Bei einer TCP Verbindung, wie sie von HTTP genutzt wird, weiss die
Anwendung nichts mehr von den einzelnen Packeten, sondern sieht nur den
Stream der Daten, welche diese beinhalten. Bei HTTP/1.0, falls kein
Content-Length angegeben ist, ist das Dokument zuende, wenn die
Verbindung geschlossen wird. Dies ist je nach client auch bei einem
Timeout der Fall. Wenn man in HTTP/1.0 oder HTTP/1.1 den Content-Length
header angibt, weiss der Browser, dass er alles bekommen hat, sobald er
gleich viele Bytes vom HTTP Body gelesen hat, wie im Content-Length
header stehen. Bei HTTP/1.1 gibt es noch den Transfer-Encoding: chunked
header. Wenn man diesen setzt, gibt man beim message body in hex die
länge des nächsten Chunks an daten, die man senden will, gefolgt von
\r\n, gefolgt von den Daten des chuncks, gefolgt von \r\n, und dann
nochmal das selbe mit dem nächsten chunck, usw. Und nach dem letzten
chunk kommt noch einer mit länge 0, welcher das ende markiert.
ESP schrieb:
> andere (wieder Ihone) meckern.
Was sagen sie denn? Es kann einen grosser Unterschied machen, jenachdem
ob man es mit einem Timeout, einem Connection Reset, oder etwas anderem
zutun hat.
ESP schrieb:
> Wie teile ich dem System mit, dass da noch Daten kommen und der
> Seitenaufbau eben etwas dauert?
Bei TCP gibt es TCP Keep-Alive, bei HTTP gibt es nichts brauchbares,
dort muss man Daten liefern. HTTP bietet nur die möglichkeit, bevor man
die eigentliche Response sendet, HTTP 100 Continue responses zu senden,
wenn die Antwort Serverseitig erst langwierig berechnet werden muss, und
der client kein Timeout bekommen soll. Wärend einer Response lange zu
warten ist eigentlich nicht vorgesehen, aber die Timeouts sind
nomalerweise sehr grosszügig.
