HttpUtils: leere Antwort (war: 57_Calendar - mal wieder Probleme beim Abruf der Kalenderdaten)

[betateilchen]

Danke. Aber solange das Problem mit den HttpUtils noch nicht gelöst ist, bleibe ich erstmal bei meiner eigenen Version des Kalendermoduls 

[cornelius fillmore]

Noch ne Idee warum das bei mir nicht funktioniert?

[justme1968]

ich versuche gerade das netatmo modul auf das NonblockingGet umzustellen und habe direkt beim ersten versuch schon das problem das ich ohne noshutdown=>1 nur ein 'empty answer received' bekomme.

mit noshutdown=>1 geht es ohne probleme.

[rudolfkoenig]

Hat das frueher ohne dieses Attribut funktioniert? Falls ja, dann haette ich gerne eine Moeglichkeit es nachzutesten. Falls nein, dann ist das mir egal (== Server-Bug).
Und egal ob ja oder nein, dein Problem ist was anderes als das, was hier diskutiert wird.

[betateilchen]

(http://up.picr.de/17334352bj.gif)

[justme1968]

also wenn ich mir die ersten beiträge in diesem thread anschaue find ich schon das es etwas damit zu tun hat.

und nein ich kann dir nicht sagen ob es früher funktioniert hat. die alter version benutzt LWP und ich möchte je gerade auf deine nonblocking version umstellen.

[betateilchen]

Falls nein, dann ist das mir egal (== Server-Bug).

Das bedeutet (wenn es denn wirklich so wäre, was es nicht ist), wir schieben den Fehler einfach auf eine Ursache außerhalb von fhem, die wir nun noch weniger beeinflussen können als das Verhalten von fhem selbst. Sehr praktisch...

[rudolfkoenig]

Nein, es bedeutet, dass in diesem Fall die Funktion mit noshutdown=1 zu verwenden ist.
Schlechte Laune?

[betateilchen]

nö, ich hab keine schlechte Laune.

Weißt Du übrigens, was passiert, wenn ich mit noshutdown=1 in den HttpUtils arbeite? Ich kann darauf warten, dass (reproduzierbar!) mein fhem nach mehreren Stunden komplett abschmiert, und zwar wegen Socket-Fehlern in der http-Kommunikation. Eine wirkliche Lösung ist das also auch nicht.

[rudolfkoenig]

Und das nennst Du eine konstruktive Fehlermeldung?

[betateilchen]

Nö.

Aber ausführlichere Meldungen machen ja keinen Sinn, da Du der festen und hier bereits mehrfach verlautbarten Meinung Überzeugung bist, Deine HttpUtils seien fehlerfrei und es Dir wurscht ist, wenn etwas nicht funktioniert, solange der Fehler vielleicht auf Serverseite zu suchen (und somit niemals zu finden) ist.

Mit einer solchen Einstellung eines "Gegenübers" in Supportfragen verliere selbst ich irgendwann die Lust, konstruktive Fehlermeldungen und Debugginganalysen zu erstellen, wenn sie ohnehin niemanden interessieren. Sorry.

[justme1968]

unabhängig ob das ganze ein fehler auf server oder client seite ist hilft es niemanden nicht eine lösung dafür anzubieten.

um mal wieder etwas produktives dazu zu sagen: was spricht dagegen das shutdown für den non blocking fall einfach in die directReadFn nach das sysread zu schieben.

damit läuft es bei mir zuverlässig. und es nicht unlogisch erst dann zu zu machen.

[betateilchen]

unabhängig ob das ganze ein fehler auf server oder client seite ist hilft es niemanden nicht eine lösung dafür anzubieten

Meine Rede. Danke.

[rudolfkoenig]

@justme1968:
shutdown zu verschieben hilft nicht bzw. ist equivalent mit noshutdown=1.
shutdown schliesst die Schreibseite einer TCP-Verbindung, um den Server zu signalisieren, es kommt nichts mehr. Manche Server meinen, wer nichts mehr sagt, der kann auch nicht zuhoeren, und schliessen ihrerseits die Verbindung ohne zu antworten, was meiner Ansicht nach ein Bug im Server ist.

In diesem Fall muss man in FHEM noshutdown verwenden, was aber Konsequenzen hat: die Laenge der Daten muss in der naechsten Schicht (HTTP:Content-Length) stehen. Auch die Lese-Seite ist deswegen aufwendiger: wenn der Server "mein" shutdown richtig interpretiert, dann schliesst er nach seiner Antwort die Verbindung, und damit weiss ich die Antwortlaenge. Mit "noshutdown=1" muss ich auch den HTTP-Header interpretieren. Ich habe zwar dieses Interpretieren unlaengst eingebaut, bin aber nicht sicher, ob es ueberall funktioniert, siehe betateilchens Meldung: irgendwo ist wohl noch ein Problem.

@betateilchen:
Ich versuche ein Problem zu fixen, wenn ich weiss, woran es liegt. Ich akzeptiere auch Patches, wenn ich sie einigermassen verstehe, und keine Angst von der Nebenwirkungen habe. Ich habe wegen deiner Meldung etliche Stunden verbracht, ein Problem was ich nicht nachstellen kann, zu loesen. Kannst du bitte verraten, was du von mir erwartest?

[justme1968]

wenn ich mir diverse flussdiagramme zu http anschaue macht dort der client die verbinung zu nach dem er eine antwor bekommen hat. ob man also wirklich von einem server fehler sprechen kann weiss ich nicht zumal ein http 1.1 server davon ausgehen darf das ein client die verbindung offen lassen möchte so lange er kein close im request mit schickt.

zu equivalent: schliesst perl tatsächlich das socket auf fhem seite inklusive freigabe aller kernel resourcen wenn ich mit noshutdown=1 arbeite? oder ist das nicht vollständig aufräumen der grund das betateilchen nach einer weile probleme damit hat?

zu content length: nach meinen tests reicht es das shutdown nach dem select zu machen. also z.b. auch vor dem sysread in directReadFn. damit solltest du immer noch lesen können bis zum ende ohne die content-lengt zu benötigen.

sollte fhem nicht ein close im http request mit schicken wenn nicht beabsichtigt ist die connection offen zu halten?

[rudolfkoenig]

so lange er kein close im request mit schickt.

Habe ich aber, siehe shutdown

oder ist das nicht vollständig aufräumen der grund das betateilchen nach einer weile probleme damit hat?

Das kann natuerlich sein, und ich bin offen fuer Verbesserungen. Wenn ich das nachstellen koennte, wuerde ich sogar selbst fixen.

reicht es das shutdown nach dem select zu machen.

Das ist quatsch. Entweder funktioniert shutdown, und dann muss es nach dem letzten write erfolgen, oder nicht, dann sollten wir es lassen. Wenn noshutdown sicher funktioniert, kann gerne zum default werden.

sollte fhem nicht ein close im http request mit schicken wenn nicht beabsichtigt ist die connection offen zu halten?

Wie geht sowas?

[justme1968]

für close gibt es in http 1.1 ein extra header feld:

Connection: close

es später zu schicken würde genau den 'server fehler' abfangen das der server nichts mehr zurück sendet wenn der client die verbindung zu gemacht hat.

ob die lokale seite korrekt zu gemacht wird auch ohne shutdown sollte man in /proc/pid/fd oder mit netstat eigentlich sehen können.

probier mal ein

Code Auswählen Erweitern

HttpUtils_NonblockingGet({
       url => 'http://api.netatmo.net/api/devicelist',
       callback=>sub($$$){ Log 1,"$_[0]->{myParam} ERR:$_[1] DATA:$_[2]});

ohne das noshutdown bekomme ich das geschilderte problem, mit noshutdown oder noshutdown nach select bekomme ich eine antwort vom server. die antwort ist zwar eine fehlermeldung weil die zugangsdaten fehlen aber zum testen ist das ok.

[betateilchen]

@betateilchen:
...
Kannst du bitte verraten, was du von mir erwartest?

Ja. Kurzgefaßt: Eine Lösung. Du hast die HttpUtils verändert, seither gibts Probleme. Warum erwartest Du da Lösungsvorschläge von den Usern, die nichtmal wissen, warum und was Du geändert hast?

Hier im Thread gehts aber eigentlich um das Calendar-Modul. Im Rahmen der Fehleranalyse sind wir längst bei den HttpUtils (und anderen Modulen mit ähnlichen Problemen) angelangt, und es würde vielleicht Sinn machen, die Diskussion zu HttpUtils in einen separaten Thread zu verlegen. Das Calendarmodul kann eigentlich nichts dafür, dass die HttpUtils nicht funktionieren.

[Dr. Boris Neubert]

Hier im Thread gehts aber eigentlich um das Calendar-Modul. Im Rahmen der Fehleranalyse sind wir längst bei den HttpUtils (und anderen Modulen mit ähnlichen Problemen) angelangt, und es würde vielleicht Sinn machen, die Diskussion zu HttpUtils in einen separaten Thread zu verlegen.

Erledigt!
bn

[betateilchen]

und nein ich kann dir nicht sagen ob es früher funktioniert hat. die alter version benutzt LWP und ich möchte je gerade auf deine nonblocking version umstellen.

Du weißt schon, dass LWP inzwischen auch nonblocking sehr gut funktioniert?

[Loredo]

Ich habe auf der Fritzbox ebenfalls das Problem mit einer leeren Antwort beim ENIGMA2 Modul.


Ich wollte es nur kurz anmerken in der Hoffnung, jemand würde sich doch noch um eine Lösung bemühen.