Sönke Tesch: HTTP-Request abbrechen

Beitrag lesen

Viel zu aufwendig. Eine TCP-Verbindung lässt sich ohne weiteres mittendrin abbrechen und der Eigentümer (hier: der Webserver) der Verbindung wird darüber automatisch informiert.

Da würde ich jetzt aber gerne wissen, wie Du die Ausführung des TCP unterbrechen willst und zwar ohne Eingriffe in's OS oder den Stecker raus zu ziehen.

Indem man die Verbindung schließt, ganz einfach, zum Beispiel mit close() oder socket_close()

Aber es geht hier um die Clientseite. Da gibt es zuviele Clients als das man sich Serverseitig auf irgendetwas verlassen könnte.

Verlassen kann man sich nie auf sowas. Das hatte ich ja versucht, mit dem Hinweis auf möglicherweise zwischengeschaltete Caches zu verdeutlichen.

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.

Du musst nur dafür sorgen, daß Dein Skript auf dieses Ereignis reagiert.

Nun ist aber nach dem Absenden des Requests schon Ende.

[..]

Doch, es ist dann Ende. Er kann nur die (fehlende) Response ignorieren und einen weiteren Request schicken.
Es ist auch nicht möglich ohne Nachfrage festzustellen, ob die Verbindung gekappt wurde, oder nur dauert.

Ich kenne mich nicht mit jedem einzelnen TCP-Stack aus, aber soweit mir bekannt, wird eine von der Gegenstelle geschlossene Verbindung dem Prozess vom TCP-Stack signalisiert. So war es zumindest bei der Amiga-Implementation des BSD-Stacks. Hab jetzt keine Lust, die Linux-Dokus durchzuwühlen, aber ich könnte mir vorstellen, daß auch dort eine geschlossene Verbindung signalisiert wird, beispielsweise indem select() oder andere Funktionen einen End-Of-File- oder Broken-Pipe-Fehler liefern (wie es FastCGI beim Verbindungsabbruch macht).

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.

Und wie machst Du das sauber(!) mit einem Browser?

Was meinst Du mit sauber? Für mich ist es sauber genug, wenn ich meine TCP-Verbindung mit der dafür vorgesehenen Systemfunktion ordentlich schließe. Fertig.
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.

Diese TCP-Verbindung steht (sofern sie nicht abgebrochen wird) während des gesamten Austauschs von Anfrage und Antwort und, bei keep-alive-HTTP-Verbindungen, auch noch für weitere Anfrage/Antwort-Pärchen, ähnlich einem Telefongespräch.

Bitte mit einem mehr oder minder kurzem Zitat aus RFC 2616 belegen, danke.

Was soll ich belegen? Sorry, aber ich verstehe im Moment wirklich nicht, was Du meinst. Die Netzwerkverbindung besteht während der gesamten Abwicklung von HTTP-Anfrage/Antwort. Das muß sie auch, denn wie soll der Server bitte die Antwort schicken, wenn der Client die Netzwerkverbindung schließt, nachdem er seine Anfrage geschickt hat? Du behauptest doch wohl nicht etwa, daß der Server dann seinerseits eine eigene Netzwerkverbinung zum Client aufbaut?

Um's mit dem Telefonbeispiel darzustellen: Deiner Ansicht nach rufst Du also Deine Freundin an, stellst eine Frage, legst auf und dann ruft Deine Freundin Dich an, um Dir zu antworten?! Mit Verlaub, das ist doch Unfug. Und auch ein Gespräch ist doch wohl für Dich nicht beendet, wenn Du Deine letzte Frage gestellt hast, sondern erst dann, wenn Du zur Frage die Antwort bekommen hast (oder der Gesprächspartner das Zimmer verlässt).

Und jetzt auch noch aus RFC 1122
Aha, dacht' ich mir ;-)

Bitte drück dich etwas klarer aus und beschreibe, wie Du das Zusammenspiel von TCP und HTTP zwischen Server und Client siehst, danke. Die "Ich weiß es man besser, aber ich sag's Dir nicht, ätschibätsch"-Schiene finde ich jedenfalls nicht sehr erhellend :/

Ich hoffe Du kannst jetzt nachvollziehen, warum sich manch'

Nein, solange Du in Rätseln sprichst, kann ich Deine Sicht der Dinge nicht nachvollziehen.

Du stellst also erst die Verbindung her, indem Du den Telefonhörer abhebst und wählst, und wenn die Verbindung steht (bis hier hin TCP), kommunizierst Du mit der "Gegenstelle" (HTTP). Die "HTTP-Verbindung" kannst Du zu jeder beliebigen Zeit abbrechen, indem Du den Telefonhörer auflegst.

Aha, hier hakt das Bild. Nach HTTP würdest Du einfach mit dem Sprechen aufhören. Ob Du auflegst interessiert HTTP nicht mehr. Das muß der Browser (Im HTTP heißt er ganz allgemein "User Agent", kann ja auch LWP::Simple sein, o.ä.) bzw der Server dann erledigen.

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.

So, und noch zwei der gewünschten Zitate aus RFC 2616, 8.1.4, "Practical Considerations":

"A client, server, or proxy MAY close the transport connection at
   any time."

"This means that clients, servers, and proxies MUST be able to
   recover from asynchronous close events."

Alles andere wäre vom Design her auch ganz großer Mist, dazu sind solche Verbindungen einfach zu unsicher.

Gruß,
  soenk.e