nicht angemeldet
IMHO ist das aber kein Grund, aufwendige Javascript/Session/Sonstwas-Abbruchkonstruktionen zu basteln. Denn _sowas_ führt meiner Erfahrung nach nur zu mehr Problemen als das es welche löst. Wie Du bereits sagtest: es gibt "zuviele Clients als das man sich [..] auf irgendetwas verlassen könnte" - da nehme ich doch lieber den einfachsten Weg.
Ich fand das den einfachsten Weg (den über Sessions)
Wenn Du etwas Einfacheres hast: nur raus damit!
Ich wäre der Letzte, der sowas nicht begrüßen würde.
Wie gesagt, mod_fastcgi spuckt ein Signal aus, wenn versucht wird, in eine bereits geschlossene Verbindung zu schreiben. Damit kann man zwar leider nicht exakt synchron mit dem Ereignis selber beenden, aber ein Leerzeichen alle x Durchläufe (oder was auch immer das Skript macht) tut IMHO niemandem weh.
Wer unbedingt die Rechenleistung braucht, die in diesen wenigen Sekunden Verzögerung vom Skript "nutzlos" verbraten wird, sollte sich vielleicht Gedanken darüber machen, ob er die richtige Hardware für sein Vorhaben auf dem Tisch stehen hat.
Das Problem bei TCP ist nur, das die Verbindung _aktiv_ geschlossen werden muß.
Ansonsten kann nur ein Timeout greifen.
Keine Ahnung auf welchen Timeout Du Dich beziehst, aber spätestens wenn Du versuchst, in eine geschlossene Verbindung zu schreiben, kriegst Du ein's auf den Deckel. Man muß diesen, oben bereits beschrieben "Test" also nur serverseitig entsprechend realisieren. Sollte nicht so schwer sein.
HTTP hat mit der darunterliegenden Netzwerkverbindung TCP absolut garnichts zu tun. HTTP sieht keinen "Befehl" zum unerwarteten Beenden einer Verbindung vor, das stimmt. Das ist auch nicht nötig, weil man einfach die Netzwerkverbindung (TCP) beendet.
Schön, aber wie machst Du es mit einem Browser?
Stopp drücken oder Seite wechseln. Wenn ich eine riesige Datei runterlade und mittendrin Stopp drücke, hört die Übertragung sofort auf und meine Mikro-Firewall zeigt die Verbindung als geschlossen an (genauer: zeigt sie nicht mehr an) -> Ziel erreicht.
Was ist denn daran so schwierig?
So ist es auch in der HTTP-Spezifikation dokumentiert und mit mehr oder weniger unerwartet abbrechenden Verbindungen sollte im übrigen jede Netzwerkapplikation schon von Natur aus rechnen.
Ja, und? Die Verbindung zwischen Webserver und -client besteht nunmal aus der _Einheit_ TCP und HTTP. HTTP führt übrigens kein Eigenleben, es wird vom Browser angewendet. Insofern kann es sich nicht garicht "für irgendetwas interessieren", der einzige Interessierte ist der Browser, und der sieht sowohl seine HTTP-Anfrage als auch seine Netzwerkverbindung.
Nein, er nutzt die Netzverbindung nur, er sieht sie aber nicht.
HTTP braucht zur Funktion nur einen Gegenspieler und eine Verbnindung dazu, kein spezielles Netz.
Du kannst also sagen, das HTTP eine Verbindung braucht. Wie diese aussieht, ist aber völlig egal, Postkarten würden reichen.
Mit Verlaub, das ist als Begründung für einen aufwendigen CGI-Abbruch über Sessionprüfungen etwas sehr weit aus der Theorie hergeholt.
Es würde mich doch ein wenig wundern, wenn irgendeine HTTP-Anwendung allen Ernstes so geschrieben wurde, daß die HTTP-Schicht keine Ahnung von der Transportschicht hat und insbesondere nichts vom Beenden der Transportverbindung mitbekommen würde.
Es wäre doch völliger Quatsch, wenn man Kontrollnachrichten der Transportschicht nicht verarbeitet bzw. in die Bearbeitung bei der HTTP-Schicht mit einbezieht.
Diese Vorgehensweise hätte etwas von einem Auto, in dem die Insassen erst mitbekommen, daß sie wegen leerem Tank wohl nicht am Ziel ankommen werden, nachdem die Karre zehn Minuten lang regungslos auf der Autobahn gestanden hat..
Anderes Praxisbeispiel:
Wenn ich mich per telnet an einen HTTP-Server klemme, dann sagt telnet mir automatisch und ohne Zeitverzögerung, daß die Verbindung getrennt wurde, sobald der Server seine Antwort geschickt hat.
So. Wo ist denn bitte da die relevante Eieruhr, um die Du Dich sorgst? Für mich sieht das jedenfalls so aus, als wenn telnet, das ja nun unwiderlegbar keinerlei Ahnung davon hat, daß ich es für HTTP mißbrauche, von dem Verbindungsabbruch von Seiten des Webservers auf irgendeine Art und Weise informiert wurde, und zwar innerhalb weniger Zehntelsekunden.
Warum soll das mit anderen Anwendungen nicht auch funktionieren?
Aus RFC 793, 3.5, "Closing a [TCP] connection", lese ich davon mal abgesehen, daß TCP durchaus eine geordnete Möglichkeit vorsieht, eine Verbindung zu beenden, namentlich mittels FIN- und CLOSE-Segmenten, nicht mittels "seit fünf Minuten kein Bit auf der Leitung".
Somit sollte es für den TCP-Stack (zumindest theoretisch) kein Problem sein, die Anwendung von einer geschlossenen Verbindung unverzüglich zu informieren und diese sollte daraufhin auch in der Lage sein, ihre Aktivitäten unverzüglich zu beenden. Das hat mit HTTP letztenendes garnichts mehr zu tun.
Also ich sehe das Zeitproblem immernoch nicht.
Gruß,
soenk.e