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?