HTTP-Request abbrechen

[Christoph Zurnieden]

Hallo,

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.

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).

Ja, ist genauso, da Linux später eigentlich auch nur die BSD Implementation übernommen hat.
Mit einigen Änderungen, aber das würde hier dann doch zu weit führen ;-)

Das Problem bei TCP ist nur, das die Verbindung _aktiv_ geschlossen werden muß.
Ansonsten kann nur ein Timeout greifen.

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.

Schön, aber wie machst Du es mit einem Browser?

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, geht aber alles nur über Timeout.

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?

Er fragt zumindest nach, ob sie noch besteht. TCP ist genau so ein Hin und Her, wie HTTP. An dieser Stelle mußten die Schreiber von HTTP sehr abstrahieren, so daß sich TCP und HTTP hier ein wenig beißen.

Es gibt nun mal Kompromisse, die sind nicht die zweitbeste Lösung, sondern weit darunter. TCP ist einer davon.
IPv6 übrigens ein weiterer *grmpf*

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).

Hatte ich nicht erwähnt, das der Vergleich stark hinkt? Und hier ist die Schadensstelle. TCP ist nur das Protokoll, das in Deinem Bild die elektomagnetischen Wellen beschreiben würde. Die Leitung legen andere.

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 :/

Mir schien, das Du Dich damit gut auskennst. Zumindest machten Deine Einwürfe den Eindruck, daß Dir beide Protokolle gut geläufig sind. Daraus folgt natürlich dann, daß Dir auch die Wiedersprüche zwischen TCP und HTTP geläufig sind. Das ist oft genug diskutiert worden. Ergo hatte ich mir erlaubt, nur darauf hinzuweisen, ohne langatmige Erklärungen.

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.

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.
Selbst TCP ist abstrakt genug, auch hier würden Postkarten reichen.

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.

Das Dumme ist nur, das das alles über Timouts geregelt wird, falls die Verbindung wirklich abgebrochen wird und nicht regulär beendet.

Um in Deinem Bild zu bleiben:

• Der eine legt einfach auf, der andere bekommt das nicht mit, irgendwann wird's ihm aber zu bunt und er legt auch auf.
• Der eine sagt:"Denn mal bis die Tage" und legt auf, der andere bekommt das nicht mit, irgendwann wird's ihm aber zu bunt und er legt auch auf.
• Der eine legt auf, es klackt und tutet beim anderen, das sagt ihm, das der eine aufgelegt hat, flucht einmal kurz über die Unsitten der Jugend und legt selber auf.

so short

Christoph Zurnieden