AJAX Abbruch bei Post

[tobi85]

Hallo Zusammen,

es geht noch immer um den AJAX-Abbruch, der bereits unter nachfolgendem Link beschrieben wurde. https://forum.selfhtml.org/self/2016/may/12/ajax-bricht-ab/1667210#m1667210

Ich konnte nun mehrere Test machen und den Fehler etwas eingrenzen, allerdings gibt es noch keine Lösung.

Zu den Fakten:

Wenn die Seite längere Zeit nicht aufgerufen wird (3-5 Minuten) und man dann per Ajax wieder den Inhalt laden möchte, bricht der AJAX einfach ab.

Als jqXHR-Status bekomme ich 0 - Not connect. Verify Network.

Dieses Problem tritt auch auf, wenn ich zum Beispiel eine leere HTML Datei lade. Es ist daher ausgeschlossen, dass es an PHP oder MySQL liegt.

Nun habe ich bei AJAX Jquery die Methode auf GET geändert und siehe da - der Fehler tritt nicht mehr auf. Nun die Frage - was kann der Grund sein, dass bei Methode POST dieser AJAX-Abbruch stattfindet?

[pl]

Beim POST muss die Content-Length Angabe im Request Header bytegenau stimmen. Prüf das mal.

[tobi85]

Wie teste ich das? Also in meinem Beispiel ist es Content-Length 19. (Also bei Abbruch und beim Laden identisch)

Kurios ist ja, dass es eigentlich IMMER geht, nur dann nicht, wenn ich ein paar Minuten nicht auf der Seite war. Wenn wirklich was an der Connecntion nicht passt, dürfte es ja auch nicht bei GET funktionieren...

[dedlfix]

Tach!

Wie teste ich das? Also in meinem Beispiel ist es Content-Length 19. (Also bei Abbruch und beim Laden identisch)

Ich glaube nicht, dass das bei einer Netzwerkstörung - wonach es derzeit aussieht - von Belang ist.

Normalerweise fummelt auch niemand einen Content-Length-Header zu Fuß in einen Ajax-Request rein und sie funktionieren trotzdem hervorragend. Es ist davon auszugehen, dass die Browser das korrekt berechnen können.

Kurios ist ja, dass es eigentlich IMMER geht, nur dann nicht, wenn ich ein paar Minuten nicht auf der Seite war. Wenn wirklich was an der Connecntion nicht passt, dürfte es ja auch nicht bei GET funktionieren...

Ist da ein Proxy oder Reverse Proxy dazwischen? Wenn die Logfiles ergeben haben, dass gar kein Request am Webserver ankommt, dann ist es an der Zeit, das Netzwerk zu untersuchen.

Es ist nicht besonders clever, zum selben Thema einen neuen Thread zu eröffnen. Hier fehlen nämlich nun viele Informationen, die bereits im anderen geklärt und erfragt wurden.

dedlfix.

[tobi85]

Hallo,

da ich das Problem etwas eingrenzen konnte, dachte ich, ich erstelle nochmals ein Thread.

Wenn es am Netzwerk liegt - warum funktioniert es mit GET, aber nicht mit POST? Ich lasse per AJAX beide Dateien gleichzeitig laden, allerdings den einen mit GET und den anderen mit POST. Bei GET kein Problem und bei POST eben dieser Fehler.

[dedlfix]

Tach!

Wenn es am Netzwerk liegt - warum funktioniert es mit GET, aber nicht mit POST?

Ich sagte nicht, dass es daran liegt, sondern dass man da mal schauen kann. Solange man die Ursache nicht kennt, kann man nur Vermutungen anstellen. Zum Netzwerk zählt in gewisser Hinsicht auch ein Proxy, also mithin alles was zwischen Browser und Server ist. Auf Clientseite kann man erstmal annehmen, dass da die Probleme nicht liegen, wenn es mit verschiedenen Clients an unterschiedlichen Orten die gleichen Symptome sind.

dedlfix.

[Christian Kruse]

Hallo tobi85,

Wenn es am Netzwerk liegt - warum funktioniert es mit GET, aber nicht mit POST? Ich lasse per AJAX beide Dateien gleichzeitig laden, allerdings den einen mit GET und den anderen mit POST. Bei GET kein Problem und bei POST eben dieser Fehler.

Ich habe mir den vorherigen Thread nicht vollständig durchgelesen. Aber deine Beschreibung hört sich für mich irgendwie nach einem Caching-Problem an. Ich kann aber nicht den Finger drauf legen; das ist nur Intuition/Erfahrung. Auch die Tatsache, dass scheinbar gar kein Request abgeschickt wird.

Hast du den JS-Quelltext irgendwo, dass man ihn mal einsehen kann? Und was ist mit der Seite, die das JS enthält, wie ist die angefordert worden? Steht irgendwas in der Konsole? Geht es in anderen Browsern, etwa dem Chrome? Wenn nein, was sagt dessen Konsole? Die ist oft geschwätziger als die der Konkurrenten.

LG,
CK

[dedlfix]

Tach!

Ich habe mir den vorherigen Thread nicht vollständig durchgelesen. Aber deine Beschreibung hört sich für mich irgendwie nach einem Caching-Problem an. Ich kann aber nicht den Finger drauf legen; das ist nur Intuition/Erfahrung.

Du meinst, die Browser sparen sich Ajax-Requests und holen das Ergebnis aus dem Cache, noch dazu wenn es um POST geht, aber GET ist davon nicht betroffen? Da melde ich Zweifel an. Ich habe darüber noch nicht nachgedacht, stelle mir aber eigentlich vor, dass man Ajax-Requests vom Prinzip her nicht gecacht haben möchte und das da nicht stattfindet. Auf alle Fälle aber nicht bei POST.

Auch die Tatsache, dass scheinbar gar kein Request abgeschickt wird.

Das zu prüfen wäre ein Fall für den Leitungshai.

dedlfix.

[Christian Kruse]

Hallo dedlfix,

Du meinst, die Browser sparen sich Ajax-Requests und holen das Ergebnis aus dem Cache, noch dazu wenn es um POST geht, aber GET ist davon nicht betroffen?

Ich dachte eher an den umgekehrten Fall.

Da melde ich Zweifel an. Ich habe darüber noch nicht nachgedacht, stelle mir aber eigentlich vor, dass man Ajax-Requests vom Prinzip her nicht gecacht haben möchte und das da nicht stattfindet.

Da weicht deine Vorstellung von der Realität ab ;-)

Auch die Tatsache, dass scheinbar gar kein Request abgeschickt wird.

Das zu prüfen wäre ein Fall für den Leitungshai.

Um 100% sicher zu gehen hast du Recht, allerdings sind jqXhr.status == 0 und ein leeres LiveHTTPHeaders (das man btw lieber zu Gunsten der Entwickler-Tools aufgeben sollte) sehr starke Indizien.

LG,
CK

[MudGuard]

Hi,

Um 100% sicher zu gehen hast du Recht, allerdings sind jqXhr.status == 0 und ein leeres LiveHTTPHeaders (das man btw lieber zu Gunsten der Entwickler-Tools aufgeben sollte) sehr starke Indizien.

Und mit einem URL-Parameter, der sich immer ändert, ließe sich das auch leicht verifizieren - z.B. den Timestamp an die URL anhängen. Tritt das Problem nicht mehr auf, war's der Cache ...

cu,
Andreas a/k/a MudGuard

[dedlfix]

Tach!

Du meinst, die Browser sparen sich Ajax-Requests und holen das Ergebnis aus dem Cache, noch dazu wenn es um POST geht, aber GET ist davon nicht betroffen?

Ich dachte eher an den umgekehrten Fall.

Wenn ich jetzt nicht falsch liege, ist das aber so herum der Fall beim Probleminhaber. POST macht Probleme, GET nicht.

dedlfix.

[Christian Kruse]

Hallo dedlfix,

Du meinst, die Browser sparen sich Ajax-Requests und holen das Ergebnis aus dem Cache, noch dazu wenn es um POST geht, aber GET ist davon nicht betroffen?

Ich dachte eher an den umgekehrten Fall.

Wenn ich jetzt nicht falsch liege, ist das aber so herum der Fall beim Probleminhaber. POST macht Probleme, GET nicht.

Ja, eben. GET kommt aus dem Cache und geht deshalb, POST wird nicht gecached und bekommt deshalb einen Fehler.

LG,
CK

[dedlfix]

Tach!

Ja, eben. GET kommt aus dem Cache und geht deshalb, POST wird nicht gecached und bekommt deshalb einen Fehler.

Jetzt verstehe ich, wie du das meinst. Aber dann ist das Caching ja nicht das eigentliche Problem, sondern es verdeckt beim GET selbiges, weil da der Cache einspringt. Das ist dann eher ein zusätzliches, weil der (POST-)Request zu Server ja irgendeinen Sinn hatte und sicherlich nicht wegfallen soll.

dedlfix.

[Christian Kruse]

Hallo dedlfix,

Aber dann ist das Caching ja nicht das eigentliche Problem, sondern es verdeckt beim GET selbiges, weil da der Cache einspringt.

Klar. Deshalb meine weitergehenden Fragen :-)

LG,
CK

[pl]

Zeig Javascript

[tobi85]

Hallo,

anbei mal der Code

		$.ajax({method: "GET",url: ajaxnavi, data: ajaxvars, success: function(response){
			$("#navi").html(response);
		}});

		$.ajax({method: "POST",url: ajaxcontent, data: ajaxvars, cache: false, success: function(response){
			$("#content").html(response);
		},
	error: function (jqXHR, exception) {
        var msg = '';
        if (jqXHR.status === 0) {
            msg = 'Not connect.\n Verify Network.';
        } else if (jqXHR.status == 404) {
            msg = 'Requested page not found. [404]';
        } else if (jqXHR.status == 500) {
            msg = 'Internal Server Error [500].';
        } else if (exception === 'parsererror') {
            msg = 'Requested JSON parse failed.';
        } else if (exception === 'timeout') {
            msg = 'Time out error.';
        } else if (exception === 'abort') {
            msg = 'Ajax request aborted.';
        } else {
            msg = 'Uncaught Error.\n' + jqXHR.responseText;
        }
        console.log(msg);
	console.log(jqXHR.responseText);
	console.log(exception);
    }	
	});
	}

[pl]

gib mir mal den Ziel-URL. Ich requeste den mal, falls Du nichts dagegen hat.

[tobi85]

Hallo, also ich habe jetzt mal eine einfache Test-Seite angelegt. Bin auf Euer Feedback gespannt. Wie gesagt muss man immer kurz warten, bis der Fehler auftritt.

https://www.slewo.com/test/index.html

[dedlfix]

Tach!

https://www.slewo.com/test/index.html

Schick beim GET bitte die response zur Console, nicht in das nicht vorhandene Element mit der ID navi.

dedlfix.

[dedlfix]

Tach!

https://www.slewo.com/test/index.html

Schick beim GET bitte die response zur Console, nicht in das nicht vorhandene Element mit der ID navi.

Was ich bisher mit dem Leitungshai sehe, ist nicht viel. Es findet Verkehr mit der IP von www.slewo.com statt. Allerdings ist der verschlüsselt und ich kann nicht reinschauen und zuordnen, ob der zum GET oder POST gehört. http:// statt https:// zu nehmen, geht nicht, weil das zu https:// umgeleitet wird.

dedlfix.

[Christian Kruse]

Hallo dedlfix,

Was ich bisher mit dem Leitungshai sehe, ist nicht viel. Es findet Verkehr mit der IP von www.slewo.com statt. Allerdings ist der verschlüsselt und ich kann nicht reinschauen und zuordnen, ob der zum GET oder POST gehört. http:// statt https:// zu nehmen, geht nicht, weil das zu https:// umgeleitet wird.

Für diese Art der Analyse eignet sich der Inspektor viel besser:

LG,
CK

[dedlfix]

Tach!

Für diese Art der Analyse eignet sich der Inspektor viel besser:

Den wollte ich ja mal außen vorlassen, weil der ja Bestandteil des Browsers und damit möglicherweise auch des Problems ist.

Hmm, Fiddler geht auch nicht, da weigert sich der Chrome das jQuery nachzuladen und Firefox ignoeriert ihn (erstmal).

dedlfix.

[tobi85]

Konntet Ihr denn das Problem nachstellen? Zumindest im FF?

Fiddler geht wohl nicht wegen http/2 - oder?

[Christian Kruse]

Hallo tobi85,

Konntet Ihr denn das Problem nachstellen? Zumindest im FF?

Weder im Chrome noch im Firefox, nein.

LG,
CK

[dedlfix]

Tach!

Konntet Ihr denn das Problem nachstellen? Zumindest im FF?

Ja, POST bleibt manchmal stecken.

Fiddler geht wohl nicht wegen http/2 - oder?

Der Fiddler ist bei HTTPS ein Man in the Middle, und das mögen die Browser nicht. Man kann das zwar abnicken, dass das falsche Zertifikat akzeptiert wird, aber das wollte wohl beim Nachladen nicht.

Was ist mit meinen anderen Punkten?

dedlfix.

[tobi85]

Sorry, welcher andere Punkt und was ist am Zertifikat falsch.

Bei ssllabs.com haben wir a+

Hast Du den Fehler auch im Chrome?

[dedlfix]

Tach!

Sorry, welcher andere Punkt

Das ist der eine: https://forum.selfhtml.org/self/2016/may/18/ajax-abbruch-bei-post/1667647#m1667647. Der ist aber erledigt, wie ich gerade sehe.

Der andere ist, dass ich HTTPS nicht gescheit testen kann.

und was ist am Zertifikat falsch.

Nichts, aber der Fiddler, der sich als Proxy dazwischensetzt, kann bei HTTPS prinzipbedingt auch nur begrenzt helfen. Er verwendet zwischen Browser und sich ein selbsterstelltes Zertifikat, und das mögen die Browser nicht.

Hast Du den Fehler auch im Chrome?

Mit dem habe ich bisher (noch) nicht weiter getestet, nur den misslungenen Fiddler-Versuch.

dedlfix.

[tobi85]

Hallo,

hast Du eine Idee was man noch machen könnte, um das Problem/Fehler weiter einzugrenzen?

[dedlfix]

Tach!

hast Du eine Idee was man noch machen könnte, um das Problem/Fehler weiter einzugrenzen?

Erstmal ohne HTTPS testen, damit man im Leitungshai sehen kann, was zu welchem Request auf die Leitung geht. Dann schauen, ob es browserspezifisch ist, und dann auf dem Server weitersehen. Achja, die Frage nach dem Reverse Proxy auf dem Server ist auch noch offen.

dedlfix.

[Christian Kruse]

Hallo dedlfix,

Erstmal ohne HTTPS testen, damit man im Leitungshai sehen kann, was zu welchem Request auf die Leitung geht.

Mein Rat: schau in den Inspektor, Netzwerk-Tab. Der bietet viele Informationen mehr, als Wireshark bieten kann (Stichwort Caches). Bevor das nicht erledigt ist lohnt es sich gar nicht erst, da die Server-Konfiguration oder ähnliches zu ändern.

LG,
CK

[dedlfix]

Tach!

Mein Rat: schau in den Inspektor, Netzwerk-Tab. Der bietet viele Informationen mehr, als Wireshark bieten kann (Stichwort Caches). Bevor das nicht erledigt ist lohnt es sich gar nicht erst, da die Server-Konfiguration oder ähnliches zu ändern.

Dann sag mir mal, warum der da was mit Expires in der Vergangenheit anzeigt, wenn gar keine diesbezüglichen Cache-Header zu sehen sind. Und ich sehe aus dem Inspektor auch nicht, ob der POST-Request im Browser verreckt ist, oder doch den Weg nach draußen gefunden hat.

dedlfix.

[Christian Kruse]

Hallo dedlfix,

Dann sag mir mal, warum der da was mit Expires in der Vergangenheit anzeigt, wenn gar keine diesbezüglichen Cache-Header zu sehen sind.

Deine Screenshots sehen mir nicht aus wie die Developer-Tools, sondern wie Firebug. Schmeiss es weg. Es hat mich schon oft belogen, gerade im Bereich Netzwerk. Benutze die eingebauten Developer-Tools.

Und ich sehe aus dem Inspektor auch nicht, ob der POST-Request im Browser verreckt ist, [...]

Doch, das wird dir auch angezeigt, zumindest rudimentär; zusätzlich wird dir aber z.B. auch angezeigt, wenn ein Request aus dem Cache kommt oder wenn er forbidden ist (z.B. durch einen Adblocker hint, hint ;-), oder, oder, oder.

Ich sagte ja auch nicht, dass du nur mit dem Inspektor arbeiten sollst; aber da er so einfach verfügbar ist und so viele Informationen bietet, sollte es immer die erste Anlaufstelle sein.

LG,
CK

[dedlfix]

Tach!

Und ich sehe aus dem Inspektor auch nicht, ob der POST-Request im Browser verreckt ist, [...]

Doch, das wird dir auch angezeigt, zumindest rudimentär; zusätzlich wird dir aber z.B. auch angezeigt, wenn ein Request aus dem Cache kommt oder wenn er forbidden ist (z.B. durch einen Adblocker hint, hint ;-), oder, oder, oder.

Was gibts da zu hinten? ABP wird wohl kaum einen Blockiergrund an der Testseite finden. Und ich sehe auch mit dem Inspektor nicht, wie weit der Request gekommen ist. Der zeigt mit nur die Requestheader und einen Strich bei "Übertragen". Was sagt das nun in Bezug auf die Aktivität meiner Internetverbindung aus?

dedlfix.

[Christian Kruse]

Hallo dedlfix,

Und ich sehe auch mit dem Inspektor nicht, wie weit der Request gekommen ist. Der zeigt mit nur die Requestheader und einen Strich bei "Übertragen".

Nein, er sagt dir auch, dass der Request nicht übermittelt wurde (siehe Icon vor dem Request). Geben dir die Tabs in den Request-Details mehr Informationen?

Was sagt das nun in Bezug auf die Aktivität meiner Internetverbindung aus?

Erstmal nichts. Aber es sagt dir zumindest, dass der Request versucht wurde zu schicken (er hätte auch in der Phase vorher abgebrochen werden können, etwa durch ein Addon) und dass das fehlgeschlagen ist. Diese Information hättest du aus Wireshark nicht unbedingt heraus bekommen.

Und ich wiederhole: ich sagte nicht, dass man Wireshark wegwerfen sollte, sondern nur, dass der Inspektor in der... „Eskalations-Stufe“ unter dem Wireshark sein sollte. Er bietet mehr Informationen in Bezug auf das Ökosystem Browser und ist deutlich einfacher erreichbar.

LG,
CK

[dedlfix]

Tach!

Und ich sehe auch mit dem Inspektor nicht, wie weit der Request gekommen ist. Der zeigt mit nur die Requestheader und einen Strich bei "Übertragen".

Nein, er sagt dir auch, dass der Request nicht übermittelt wurde (siehe Icon vor dem Request).

Du meinst, aus dem grauen Punkt? Der hat im Gegensatz zu den anderen noch nicht mal einen Tooltip, um seine Bedeutung zu offenbaren.

Geben dir die Tabs in den Request-Details mehr Informationen?

Die sind leer, unwichtig (Cookie), oder im Falle des Zertifikats steht da dasselbe wie bei GET.

Was sagt das nun in Bezug auf die Aktivität meiner Internetverbindung aus?

Erstmal nichts. Aber es sagt dir zumindest, dass der Request versucht wurde zu schicken (er hätte auch in der Phase vorher abgebrochen werden können, etwa durch ein Addon) und dass das fehlgeschlagen ist. Diese Information hättest du aus Wireshark nicht unbedingt heraus bekommen.

Da sehe ich zumindest, ob da eine Aktivität ist oder nicht, das kann der Inspektor nicht wissen/zeigen. Zum Beispiel habe ich jetzt gesehen, dass da auch für den nicht erfolgreichen POST-Request Verkehr zum Server stattfand und sogar auch Antworten kamen. Das meiste ist Schlüsselverhandlung, aber auch Application Data (aus der Sicht von TLS) gingen in beide Richtungen. Was da an Payload-Verkehr ausgetauscht wurde, verschweigt auch der Inspektor.

dedlfix.

[Christian Kruse]

Hallo dedlfix,

Du meinst, aus dem grauen Punkt? Der hat im Gegensatz zu den anderen noch nicht mal einen Tooltip, um seine Bedeutung zu offenbaren.

Ja, die UI ist im Detail noch verbesserungsdürftig.

Was sagt das nun in Bezug auf die Aktivität meiner Internetverbindung aus?

Erstmal nichts. Aber es sagt dir zumindest, dass der Request versucht wurde zu schicken (er hätte auch in der Phase vorher abgebrochen werden können, etwa durch ein Addon) und dass das fehlgeschlagen ist. Diese Information hättest du aus Wireshark nicht unbedingt heraus bekommen.

Da sehe ich zumindest, ob da eine Aktivität ist oder nicht, das kann der Inspektor nicht wissen/zeigen.

Deshalb ist der Inspektor auch kein Ersatz für Wireshark ;-) Im Zweifel siehst du aber im Wireshark - nichts.

LG,
CK

[dedlfix]

Tach!

Deshalb ist der Inspektor auch kein Ersatz für Wireshark ;-) Im Zweifel siehst du aber im Wireshark - nichts.

Dann kann ich daraus aber entnehmen, dass irgendwas im Browser den Request unterdrückt. Mit dem Leitungshai habe ich nun aber noch gesehen, dass die Verbindung nicht geschlossen wird und dreimal nach jeweils einer Minute oder so noch ein bisschen Daten ausgetauscht werden, bevor dann das ordnungsgemäße Ende kommt. Auch dazu sieht man im Inspektor nichts.

Ich schließe nun daraus, dass der Browser kommuniziert, die Schlüsselaushandlung auch klappt, mithin der nginx den Request sehen muss. Ob aber der Server keine gescheite Antwort sendet, oder der Browser was nicht auf die Reihe bekommt, lässt sich nicht herausfinden. Dazu müsste man sehen, was da ausgetauscht wird, aber bei HTTP ohne S tritt der Fehler nicht auf.

Mehr Ideen habe ich momentan nicht.

dedlfix.

[Christian Kruse]

Hallo dedlfix,

Deshalb ist der Inspektor auch kein Ersatz für Wireshark ;-) Im Zweifel siehst du aber im Wireshark - nichts.

Dann kann ich daraus aber entnehmen, dass irgendwas im Browser den Request unterdrückt.

Nö, nur, dass der Fehler irgendwo im Netzwerk liegt. Wenn etwa der Host nicht erreichbar ist weil er nicht aufgelöst werden kann, dann siehst du das im Wireshark nicht. Der Inspektor liefert dir halt eine Menge Browser-relevante Informationen, die Wireshark nicht wissen kann.

Ich verstehe auch nicht so recht, warum du so dagegen hälst. Weder habe ich gesagt, dass der Inspektor der einzige Weg ist noch habe ich gesagt, dass Wireshark nicht benutzt werden sollte. Ich habe lediglich gesagt, dass der Inspektor in der Eskalations-Stufe zuerst kommen sollte, weil er viel mehr Browser-spezifische Informationen bieten kann und ganze Fehlerklassen, die man mit Wireshark gar nicht sehen kann und die im Alltag viel Wahrscheinlicher sind als Netzwerk-Probleme (wir sind hier in einem Webdeveloper-Forum) erschlagen kann.

Wenn das nichts geholfen hat: her mit Wireshark!

Ich schließe nun daraus, dass der Browser kommuniziert, die Schlüsselaushandlung auch klappt, mithin der nginx den Request sehen muss. Ob aber der Server keine gescheite Antwort sendet, oder der Browser was nicht auf die Reihe bekommt, lässt sich nicht herausfinden. Dazu müsste man sehen, was da ausgetauscht wird, aber bei HTTP ohne S tritt der Fehler nicht auf.

Ich würde aus den von dir beschriebenen Symptomen eher schliessen, dass da irgendwelche SSL-Session-Caches und deren Timeout eine Rolle spielen. Der Key, der am Anfang einer SSL-Session ausgehandelt wird, ist ja nicht unbegrenzt gültig. Und wenn es ohne SSL geht, halte ich das nicht für unwahrscheinlich, dass da irgendwas verkonfiguriert wurde.

Die Frage ist nur, warum das bei mir nicht auftritt, weder im Firefox noch im Chrome. Bist du in der Lage, das Problem im Chrome zu reproduzieren? Falls ja: chrome://net-internals/#events bietet noch einmal ein ganzes Stück mehr Debug-Informationen. Beim Firefox scheint das deutlich komplizierter zu sein.

Wobei, ha, nein, doch etwas gefunden: about:networking im Firefox. Siehe Liste Vielleicht bietet das ja weitergehende Informationen über den Grund und die Ursachen? Edit: hm, nein - das ist nicht so interessant wie die Chrome-Übersicht, leider.

LG,
CK

[dedlfix]

Tach!

Ich würde aus den von dir beschriebenen Symptomen eher schliessen, dass da irgendwelche SSL-Session-Caches und deren Timeout eine Rolle spielen. Der Key, der am Anfang einer SSL-Session ausgehandelt wird, ist ja nicht unbegrenzt gültig. Und wenn es ohne SSL geht, halte ich das nicht für unwahrscheinlich, dass da irgendwas verkonfiguriert wurde.

Wird das nicht für jede Verbindung von Grund auf neu verhandelt? Ich kenne mich da nicht aus.

Die Frage ist nur, warum das bei mir nicht auftritt, weder im Firefox noch im Chrome. Bist du in der Lage, das Problem im Chrome zu reproduzieren?

Nein.

Wobei, ha, nein, doch etwas gefunden: about:networking im Firefox.

"Diese Funktion ist sehr experimentell. Verwenden Sie sie nicht ohne erwachsene Aufsicht." - Hab ich grad keine, kann ich nicht testen.

HTTP

Hostname|Port|SPDY|SSL|Aktiv|Untätig www.slewo.com|443|true|true|0|0

Sockets

Host|Port|TCP|Aktiv|Gesendet|Empfangen 84.19.30.23|443|true|true|378|62

Der Rest ist uninteressant.

dedlfix.

[Christian Kruse]

Hallo dedlfix,

Wird das nicht für jede Verbindung von Grund auf neu verhandelt? Ich kenne mich da nicht aus.

Das ist möglich, wird heute aber eigentlich nicht mehr so benutzt. Heute werden eigentlich Sessions und Session Tickets benutzt. Das funktioniert so, dass der Server ein Session Ticket im ersten SSL-Handshake mitschickt. Dieses Ticket ist für eine bestimmte Zeit gültig und wenn der Client es in der Begrüssung mitschickt, kann der TLS-Handshake deutlich verkürzt werden. Dafür braucht man allerdings den Session Cache.

HTTP

Hostname|Port|SPDY|SSL|Aktiv|Untätig www.slewo.com|443|true|true|0|0

Sockets

Host|Port|TCP|Aktiv|Gesendet|Empfangen 84.19.30.23|443|true|true|378|62

Der Rest ist uninteressant.

Ja, das leider auch nicht wirklich... schade, der Firefox muss da echt noch etwas nachholen.

LG,
CK

[dedlfix]

Tach!

Ich hab mal einen Leitungshai-Dump zum Problem erzeugt. Vielleicht sieht da ein geübtes Auge etwas.

http://selfhtml.org/temp/slewo.pcap und http://selfhtml.org/temp/slewo.pcapng

nicht verlinkt; zweimal dasselbe; die ersten beiden Speichern-Unter-Formate vom Hai (pcap müsste tcpdump-kompatibel sein)

dedlfix.

[dedlfix]

Tach!

Ich verstehe auch nicht so recht, warum du so dagegen hälst. Weder habe ich gesagt, dass der Inspektor der einzige Weg ist noch habe ich gesagt, dass Wireshark nicht benutzt werden sollte. Ich habe lediglich gesagt, dass der Inspektor in der Eskalations-Stufe zuerst kommen sollte, weil er viel mehr Browser-spezifische Informationen bieten kann und ganze Fehlerklassen, die man mit Wireshark gar nicht sehen kann und die im Alltag viel Wahrscheinlicher sind als Netzwerk-Probleme (wir sind hier in einem Webdeveloper-Forum) erschlagen kann.

Ich halse nicht, ich halte ;) Aber abgesehen davon, geht es mir hier um einen konkreten Fall und du beschreibst eher die allgemeine Vorgehensweise. Das ist ja nicht verkehrt, aber im Moment wollte ich ganz konkrete Imformatioenn und andere, die man mit dem Inspektor finden kann, waren nicht relevant (Namensauflösung - funktioniert; Adblocker - sehr unwahrscheinlich). Der Probleminhaber sagte zum Beispiel (in dem anderen Thread), dass in seinem nginx-Logfile kein Eintrag auftaucht. Deswegen wollte ich unbedingt sehen, ob der Request rausgeht. Woran ein enventuelles Nichtrausgehen scheitert, wäre erst mein nächster Schritt gewesen. Ich springe bei der Suche gern mal hin und her, und kreise den Fehler so ein. Denn wenn ich linear vorangehe, finde ich die Ursache nach Murphy erst kurz vor dem Ende und habe eine Menge Schritte umsonst getan. Andererseits gibts garantiert eine Abwandlung des Gesetzes, die besagt, dass die Reihenfolge beim Arbarbeiten keine Rolle spielt.

dedlfix.

[Christian Kruse]

Hallo dedlfix,

Der Probleminhaber sagte zum Beispiel (in dem anderen Thread), dass in seinem nginx-Logfile kein Eintrag auftaucht.

Hört sich für mich immer mehr nach SSL-Session- oder SSL-Handshake-Problemen an. Vielleicht irgendeine race condition im Session-Handling.

Ich springe bei der Suche gern mal hin und her, und kreise den Fehler so ein.

Ich gehe da lieber nach Wahrscheinlichkeiten vor. Wie wahrscheinlich ist welcher Fehler, die mit der geringsten Wahrscheinlichkeit verfolge ich dann zuletzt. Im Schnitt dürfte ich damit ganz gut fahren.

LG,
CK

[Der Martin]

Hallo,

Wenn etwa der Host nicht erreichbar ist weil er nicht aufgelöst werden kann, dann siehst du das im Wireshark nicht.

doch, zumindest die DNS-Anfrage und die Antwort dazu würde man auch mit dem Kabeljau sehen.

Der Inspektor liefert dir halt eine Menge Browser-relevante Informationen, die Wireshark nicht wissen kann.

Das ist natürlich richtig - vor allem browser-interne Informationen.

So long,
 Martin

[Christian Kruse]

Hallo Martin,

Wenn etwa der Host nicht erreichbar ist weil er nicht aufgelöst werden kann, dann siehst du das im Wireshark nicht.

doch, zumindest die DNS-Anfrage und die Antwort dazu würde man auch mit dem Kabeljau sehen.

Ich gehe nicht davon aus, dass man Wireshark ohne Capture-Filter laufen lässt ;-)

LG,
CK

[dedlfix]

Tach!

Ich gehe nicht davon aus, dass man Wireshark ohne Capture-Filter laufen lässt ;-)

Mach ich aber. Es gibt Anzeigefilter. Den kann man ausschalten und sieht auch noch den Rest.

Den habe ich aber capture-gefiltert. Ich wusste, dass der Hai das kann, musste aber suchen, denn das ist nun recht gut versteckt.

dedlfix.

[Der Martin]

Hi,

doch, zumindest die DNS-Anfrage und die Antwort dazu würde man auch mit dem Kabeljau sehen.

Ich gehe nicht davon aus, dass man Wireshark ohne Capture-Filter laufen lässt ;-)

kommt bei mir sehr darauf an, welches Phänomen ich sehen will und ob ich es einwandfrei reproduzieren kann. Wenn ich nur eine geringe Datenmenge bzw. Aufzeichnungsdauer erwarte, spar ich mir den Aufwand, Filter zu definieren. Vor allem sehe ich dann auch Fehler in tieferen Protokollschichten, etwa ein fehlendes ACK.

Wenn es natürlich, so wie hier, um Effekte geht, die nur hin und wieder auftreten, lohnt sich ein Filter vielleicht schon, weil aufgrund der Aufzeichnungsdauer die Wahrscheinlichkeit groß ist, dass anderer Netzwerkverkehr "zufällig" auch noch mitgeschnitten wird.
Aber wenn ich ein Problem wie das beschriebene hätte, würde ich neben HTTP selbstverständlich auch DNS mit einbeziehen.

So long,
 Martin

[tobi85]

Hallo!

Unter nachfolgendem Link kannst Du es jetzt mal ohne SSL testen

84.19.30.23/index.html

Also zwischen Client und Server ist kein Proxy

[dedlfix]

Tach!

Unter nachfolgendem Link kannst Du es jetzt mal ohne SSL testen

84.19.30.23/index.html

Damit kommt der Fehler nicht. Mit HTTPS hingegen kommt er zuverlässig(er). Gib mal noch eine weitere HTTPS-Testseite, die nur den POST-Request abschickt und keinen zusätzlichen Netzwerkverkehr veranlasst.

dedlfix.

[tobi85]

Anbei der Link

https://www.slewo.com/test/index2.html

[tobi85]

Hallo dedlfix,

konntest Du nochmals testen?

Mein Admin und ich sind seit zwei Tagen am testen und können nun das Problem wenigstens etwas eingrenzen.

Das Problem tritt bei folgender Konstellation auf

• Firefox
• NGINX
• SSL
• POST

Wir hatten das Skript bei Apache gestetet - Kein Problem

Wir hatten das Skript mit verschiedenen NGINX Versionen und Server gestestet (von NGINX Version 1.9.15 - 1.10.0) - immer das selbe Problem.

Firefox Version 45 und 46 - immer das selbe Problem

Auch hatten wir bei der URL einen Random-Parameter angefügt - auch keine Lösung/Besserung.

Bei Wireshark konnte ich einen Unterschied feststellen, allerdings fehlt mir da leider das Wissen, wie ich dieses auslese soll/kann.

[dedlfix]

Tach!

konntest Du nochmals testen?

Ja, die Erkenntnisse daraus sind allerdings in dem anderen Teil-Thread ab jenem Posting eingearbeitet.

Mein Admin und ich sind seit zwei Tagen am testen und können nun das Problem wenigstens etwas eingrenzen.

Das Problem tritt bei folgender Konstellation auf

• Firefox
• NGINX
• SSL
• POST

Ja, so schaut es aus. Es betrifft aber nicht alle Firefoxe, denn der vom CK hat das nicht (liegt vielleicht am anderen Betriebssystem). Ich kann da vermutlich aber nichts weiter beitragen, weil ich mich mit dem Verschlüsslungskram nicht weiter auskenne. Und so sehe ich nicht die Ursache für das was da falsch läuft, geschweige denn, dass ich in die unverschlüsselten Daten blicken kann. Soweit ich aber weiß, kann der Kabelhai das tun, muss dazu aber den Schlüssel übergeben bekommen. Wie das geht, muss das Internet wissen.

dedlfix.

[Christian Kruse]

Hallo dedlfix,

Ja, so schaut es aus. Es betrifft aber nicht alle Firefoxe, denn der vom CK hat das nicht (liegt vielleicht am anderen Betriebssystem).

Unter Windows kann ich es inzwischen auch nachvollziehen. Auffällig ist, dass das immer dann passiert, wenn ein vollständiger SSL-Handshake stattfinden muss. Ist das nicht der Fall ist der AJAX-Aufruf erfolgreich - daher vermutlich auch die drei bis fünf Minuten. Ich verdächtige weiterhin das SSL-Session-Handling.

Soweit ich aber weiß, kann der Kabelhai das tun, muss dazu aber den Schlüssel übergeben bekommen. Wie das geht, muss das Internet wissen.

Ja, Klartext zu bekommen wäre auch mein nächster Schritt, zusammen mit den höchstmöglichen Debug-Ausgaben im Nginx. Ggfls würde ich mich auch mal mit dtrace oder strace an den Nginx hängen und schauen, was da passiert.

Edit: als Workaround würde ich den Request einmal wiederholen wenn er fehlgeschlagen ist.

LG,
CK

[Christian Kruse]

Hallo tobi85,

Hallo, also ich habe jetzt mal eine einfache Test-Seite angelegt. Bin auf Euer Feedback gespannt. Wie gesagt muss man immer kurz warten, bis der Fehler auftritt.

Ich kann den Fehler nicht nachvollziehen. Was ich aber sehr gut sehen kann, ist, dass der GET-Request tatsächlich gecached wird aber der POST-Request nie (siehe Developer-Tools, Netzwerk-Tab). Ich würde also nicht unbedingt Netzwerk-Probleme ausschließen. Dass GET aus dem Cache kommt und deshalb geht, kann das Problem auch einfach nur verdecken.

LG,
CK

[Christian Kruse]

Hallo Christian,

Ich kann den Fehler nicht nachvollziehen.

Immer noch nicht. Die Requests werden weiterhin erfolgreich ausgeführt.

LG,
CK

[tobi85]

Hast Du im FF getestet? Wenn ja, welche Version? Wie lang hattest Du gewartet?

[Christian Kruse]

Hallo tobi85,

Hast Du im FF getestet? Wenn ja, welche Version? Wie lang hattest Du gewartet?

Chrome und Firefox, etwa eine halbe Stunde (bin in der Zwischenzeit mit dem Hund draußen gewesen).

LG,
CK

[pl]

Hallo, also ich habe jetzt mal eine einfache Test-Seite angelegt. Bin auf Euer Feedback gespannt. Wie gesagt muss man immer kurz warten, bis der Fehler auftritt.

https://www.slewo.com/test/index.html

Da geht kein AJAX Request raus. Aber das haben die anderen bestimmt auch schon rausgefunden.

[Christian Kruse]

Hallo tobi85,

	error: function (jqXHR, exception) {

Was sagt der dritte Parameter? Die Error-Funktion erhält laut Doku drei Parameter: jqXHR, textStatus und errorThrown. Der zweite und dritte sind Strings.

Wie sieht die URL aus? (siehe auch)

LG,
CK