Ich versuche gerade, meinen Reverse Proxy von nginx auf haproxy umzustellen, scheitere aber an den Websockets.
Ich bekomme im Browser nur:
fhemweb.js:1111 WebSocket connection to 'wss://meinhostname/fhem?XHR=1&inform=type=status;filter=WEB;since=1527516206;fmt=JSON&fw_id=37591×tamp=1527516225186' failed:Error during WebSocket handshake: Unexpected response code: 200
Hat jemand einen Konfigurationshinweis für mich? Hier ist meine Config:
acl host_fhem hdr(host) -i meinhostname
use_backend bk_fhem if host_fhem
backend bk_fhem
server localhost 127.0.0.1:8083 maxconn 1000 weight 10 cookie check
Hi,
hast du für das Problem eine Lösung gefunden? Ich habe ein ähnliches Fehlerbild mit HaProxy und Fhem.
MfG,
Marlon
Hallo, ich kämpfe leider mit dem gleich Problem. Aktuell benutze ich haproxy 2.2.13. Mit version 1.8.x läuft es wunderbar.
Beste Grüße
Da die websocket session eigentlich nicht mit einem code geschlossen werden sollte, habe ich mal aus meiner haproxy config "option http-server-close" gelöscht.
Damit scheint es jetzt zu gehen. Ihr müsstet prüfen, dass dies weder im defaults, noch im frontend oder backend steht.
Hallo, ich wollte nur Bescheid geben, dass leider das Problem bei mir immernoch vorhanden ist. Es hatte nichts mit der option http-server-close zu tun.
Ich hatte in den defaults aus versehen den mode auf tcp geändert.
Wer http mode in haproxy nicht benötigt, kann aber das Problem mit tcp lösen. Leider benötige ich aber http mode, womit das Problem weiterhin vorhanden ist.
Ich glaube ich komme dem Problem näher.
Das Problem liegt wohl nicht an HAproxy, da vom Backend das http 200 kommt, hier muss aber 101 für protocol upgrade kommen.
HAproxy benennt alle HTTP header name in lower case um.
Nachdem ich inhaltlich 2 identische Header verglichen hatte, bei einem kommt 200, beim anderen 101, probiert ich mit den Header Namen herum.
Header sind laut RFC nicht case sensitive, aber es scheint, dass FHEM beim HEADER "sec-websocket-key" vs "Sec-WebSocket-Key" Probleme hat.
Sobald dieser HEader in lowever case kommt, erhaltet man eine 200 Antwort. Das ist aus meiner Sicht ein Bug.
Nun weiß ich leider nicht, wie ich potentielle issues bei FHEM melden kann? Wer kann hier weiterhelfen?
Beste Grüße
ZitatSobald dieser HEader in lowever case kommt, erhaltet man eine 200 Antwort. Das ist aus meiner Sicht ein Bug.
Habs versucht zu fixen, bitte um Feedback.
Oh, das ging ja super schnell. Danke für promptes angucken.
Ich habe gerade mal update durchlaufen lassen:
2021.04.23 22:20:00.888 1: UPD ./CHANGED
2021.04.23 22:20:00.971 1: UPD ./configDB.pm
2021.04.23 22:20:01.008 1: UPD FHEM/10_FBDECT.pm
2021.04.23 22:20:01.045 1: UPD FHEM/30_HUEBridge.pm
2021.04.23 22:20:01.084 1: UPD FHEM/49_IPCAM.pm
2021.04.23 22:20:01.121 1: UPD FHEM/69_SoftliqCloud.pm
2021.04.23 22:20:01.159 1: UPD FHEM/98_ComfoAir.pm
2021.04.23 22:20:01.195 1: UPD FHEM/98_DOIF.pm
2021.04.23 22:20:01.252 1: UPD FHEM/98_WeekdayTimer.pm
2021.04.23 22:20:01.431 1: UPD FHEM/HttpUtils.pm
2021.04.23 22:20:01.469 1: UPD FHEM/lib/AttrTemplate/mqtt2.template
2021.04.23 22:20:01.615 1: UPD lib/FHEM/Core/Authentication/Passwords.pm
Leider verhällt sich das immer noch fehlerhaft. Zum Vergleich, 2 identische Requests, 1x mit "sec-websocket-key" und der andere mit "Sec-WebSocket-Key".
Welches File wurde denn aktualisiert?
Ich sehe gerade, der letzte commit im trac ist ja von 18:06. https://svn.fhem.de/trac/log/trunk/fhem?rev=24315 (https://svn.fhem.de/trac/log/trunk/fhem?rev=24315)
Sorry die doofe Frage, aber muss ich noch etwas warten bis ich den commit sehe?
ZitatSorry die doofe Frage, aber muss ich noch etwas warten bis ich den commit sehe?
Normalerweise bis zum naechsten Tag etwa um 8.
Der Kopierprozess startet um 7:45, und dauert wenige Minuten.
Danke für die Erklärung.
Habe gerade das Update reinlaufen lassen und es funktioniert jetzt wunderbar!
Vielen Dann für den schnellen Fix!
Beste Grüße
Danke rudolfkoenig, bei mir läuft es jetzt auch :D.
MfG Marlon