Anmerkung zu einem Teil:

2020-03-25T18:29:54 Gustl

Aber eigentlich wollte ich folgendes erreichen:

* HTML Code ausgeben
* Danach gibt er ja den Status 200 zurück
* Dann soll er die restlichen Subroutinen quasi "abarbeiten", ohne das der Browser noch warten muss.
* Quasi dann im Hintergrund, nach der HTML-Antwort

Die Reihenfolge der ersten zwei ist anders herum:
Zuerst wird der Status ausgegeben.

Dann folgen die Header-Felder.

Danach kommt dann der Datenstrom als HTML oder was auch immer geliefert werden sollte.

Ein Beispiel ist beispielsweise dort zu sehen: https://en.wikipedia.org/wiki/Hypertext_Transfer_P...


In dem Beispiel steht in der Response die Zeile "Connection: Close".
Die Erklärung dazu unter dem Beispiel darunter klang vielversprechend, hat aber hier beim Testen nicht gebracht.

Wenn ich im Firefox über das Netzwerk-Tool mitlese, ist zu erkennen, dass die Response erst dann rausgeht, wenn das Skript nach dem sleep() beendet wird.

Wenn ich neben STDOUT auch STDERR schließe, erfolgt die Auslieferung schneller; aber dann wird das Skript leider auch vorzeitig gekillt ;-)
Wahrscheinlich, weil der Webserver dann bemerkt, dass weder via STDOUT noch via STDERR Daten vom Skript kommen können (Die Kanäle wurden ja vom Skript geschlossen). Daher macht es für ihn keinen Sinn, das Skript weiter laufen zu lassen...


Wie schon zuvor vermutet, müsste das irgendwie im Webserver konfiguriert werden, dass er die Ausgabe zum Client schon schicken darf, sobald STDOUT geschlossen wurde. Oder dass er nicht puffern soll, sondern einfach rausschicken soll, bis STDOUT geschlossen wird.

Und er darf/soll das Skript aber solange weiterlaufen lassen, bis entweder ein Timeout überschritten wird (beschränkte Laufzeit für CGI-Skripte) oder eben STDERR geschlossen wird (entweder weil das Skript fertig ist und sich beendet, oder weil das Skript den Kanal selber schließt (und es dann gekillt würde)).
Last edited: 2020-03-26 01:03:33 +0100 (CET)