WebSocket: Invalid frame header

[timmib]

Guten Tag,

ich würde hier gerne nochmal hier auf das/mein Problem mit websockets bei HTTPS hinweisen.
https://forum.fhem.de/index.php/topic,114505.msg1087635.html#msg1087635

Eventuell war es damals auch das falsche Unterforum bei den UIs, denn der Server gibt ja laut Chrome den kaputten Response zurück.

wss://pitwo:8083/fhem/?XHR=1&inform=type=status;filter=HIER_JEDE_MENGE;since=1643568603347;fmt=JSON&timestamp=1643568604336

Viele Grüße

Tim

[rudolfkoenig]

Ich gehe davon aus, dass das Problem nicht generisch ist, sonst haette man das frueher schon gemeldet.
Dafuer spricht auch, dass laut Beitrag das Problem TabletUI spezifisch ist.

Ich helfe gerne, allerdings brauche ich etwas zum nachstellen des Problems.

[timmib]

Hallo Rudolf,

ja, das wird wohl etwas schwierig nachzustellen.

Ich hab mal grad meine FHEM Entwicklung VM auf HTTPS umgestellt und die produktive fhem.cfg dort genutzt.
Da kommen leider nicht genug Frames bis der Fehler kommt.

Ich hab mal alternativ auf der produktiven Instanz mit allerlei WebSocket Chrome Extensions probiert etwas rauszufinden. Die laufen aber auch nur recht früh auf den Fehler, aber ohne weitere Details.
Der "WebSocket King client" meldet auch nur:

An unknown error occurred: {"isTrusted":true}.

Was mich da nur wundert, sind die diversen SVG Grafiken aus den states die da verschickt werden.

z.B.

Code Auswählen Erweitern

["HUEDevice5","off","<div id=\u0022HUEDevice5\u0022  title=\u0022off\u0022 class=\u0022col2\u0022><a href=\u0022/fhem?cmd.HUEDevice5=set HUEDevice5 toggle&room=HUEDevice&fwcsrf=csrf_551213403330698\u0022><svg class=\u0022 off\u0022 data-txt=\u0022off\u0022 version=\u00221.0\u0022 xmlns=\u0022http://www.w3.org/2000/svg\u0022  width=\u0022468pt\u0022 height=\u0022617pt\u0022 viewBox=\u00220 0 468 617\u0022  preserveAspectRatio=\u0022xMidYMid meet\u0022> <metadata> Created by potrace 1.8, written by Peter Selinger 2001-2007 </metadata> <g transform=\u0022translate(0,617) scale(0.221801,-0.221801)\u0022  stroke=\u0022none\u0022> <path d=\u0022M756 2765 c-9 -25 -7 -128 3 -144 5 -8 16 -11 25 -8 24 10 19 160 -5 165 -9 2 -19 -4 -23 -13z\u0022/> <path d=\u0022M1310 2695 c0 -77 2 -86 18 -83 14 3 17 15 17 83 0 68 -3 80 -17 83 -16 3 -18 -6 -18 -83z\u0022/> <path d=\u0022M1806 2581 c-47 -47 -67 -74 -63 -85 4 -9 10 -16 14 -16 17 0 155 148 149 159 -14 21 -32 10 -100 -58z\u0022/> <path d=\u0022M220 2622 c0 -23 125 -147 139 -138 21 13 11 32 -52 94 -64 64 -87 75 -87 44z\u0022/> <path d=\u0022M809 2257 c-70 -20 -136 -63 -174 -115 -65 -87 -65 -91 -65 -643 0 -479 1 -500 21 -553 25 -67 87 -134 160 -173 l54 -28 250 0 c235 0 253 1 296 21 63 29 125 94 158 163 l26 56 0 520 0 520 -28 56 c-32 66 -99 132 -165 162 -43 20 -65 22 -267 24 -153 2 -234 -2 -266 -10z m486 -146 c48 -22 69 -44 90 -94 13 -31 15 -107 15 -517 0 -526 0 -523 -59 -573 -48 -40 -90 -47 -299 -47 -205 0 -226 4 -280 54 -51 46 -50 40 -53 567 l-3 495 23 40 c24 43 64 72 115 85 17 4 117 7 221 8 164 0 195 -2 230 -18z\u0022/> <path d=\u0022M13 2065 c-11 -29 12 -36 118 -33 96 3 104 4 104 23 0 19 -8 20 -108 23 -91 2 -108 0 -114 -13z\u0022/> <path d=\u0022M1877 2066 c-11 -27 17 -36 113 -36 100 0 127 8 117 34 -5 13 -25 16 -116 16 -83 0 -110 -3 -114 -14z\u0022/> <path d=\u0022M10 1510 c0 -19 6 -20 116 -20 105 0 115 2 112 18 -3 15 -18 17 -116 20 -107 3 -112 2 -112 -18z\u0022/> <path d=\u0022M1876 1522 c-2 -4 -1 -14 3 -20 5 -9 38 -12 117 -10 89 2 109 6 109 18 0 12 -20 16 -112 18 -61 1 -114 -1 -117 -6z\u0022/> <path d=\u0022M21 981 c-8 -5 -11 -16 -8 -25 5 -13 24 -16 112 -16 88 0 107 3 112 16 10 26 -16 34 -112 34 -50 0 -96 -4 -104 -9z\u0022/> <path d=\u0022M1882 978 c-8 -8 -9 -15 -1 -25 8 -9 40 -13 108 -13 101 0 128 8 118 34 -5 13 -24 16 -110 16 -66 0 -107 -4 -115 -12z\u0022/> <path d=\u0022M768 693 c-36 -41 -30 -95 11 -108 60 -19 520 -91 539 -84 53 20 66 99 19 119 -28 12 -482 90 -524 90 -16 0 -37 -8 -45 -17z\u0022/> <path d=\u0022M793 530 c-41 -17 -58 -85 -28 -110 15 -12 492 -100 543 -100 33 0 62 34 62 74 0 18 -6 38 -13 44 -6 6 -120 29 -252 51 -132 23 -251 43 -265 46 -14 2 -35 0 -47 -5z\u0022/> <path d=\u0022M793 360 c-46 -18 -59 -90 -20 -114 21 -13 478 -96 531 -96 14 0 35 9 46 20 26 26 27 85 2 99 -10 5 -126 28 -258 51 -131 22 -248 42 -259 44 -11 2 -30 0 -42 -4z\u0022/> <path d=\u0022M871 154 c-26 -33 -27 -55 -3 -82 13 -16 51 -26 176 -47 158 -27 159 -27 185 -7 31 22 41 81 18 101 -16 13 -271 61 -323 61 -23 0 -39 -8 -53 -26z\u0022/> </g> </svg></a></div>"]

Eine Möglichkeit wäre, da Logging in FHEM selber einzubauen, um dann zu vergleichen, wo er aussteigt.

Ich hab es mal mit fiddler aufgezeichnet. Er meint auch "ProtocolError". Siehe Screenshot. Evtl. sagt es Dir ja was.

Viele Grüße

Tim

[timmib]

Ich hab es nochmal ein paar mal probiert. Es endet immer mit einer 25, also einem "end of medium".

[timmib]

Ich habe es nun auch mal mit HTTP (ohne S) probiert und auch funktioniert es nicht mehr.

Die Fehlermeldung in der Chrome Developer Console sagt:

Code Auswählen Erweitern

failed: Could not decode a text frame as UTF-8.

Da scheint also wirklich etwas korruptes über geschickt zu werden was kein Text ist.

Die Stelle im Code wäre in 01_FHEMWEB.pm

Code Auswählen Erweitern

sub
FW_Read($$) korrekt?

[rudolfkoenig]

FW_Read ist korrekt.
Eigentlich muss man Daten FHEM-intern als UTF-8 vorhalten, leider halten sich manche Module nicht strikt an diese Richtlinie.
Jetzt muesste man das Modul rausfinden, das der Verursacher ist.

[timmib]

OK,

das heißt ich bau hier mal provisorisch logging ein:

Code Auswählen Erweitern

   
    my $ret = FW_fC($data);
    FW_addToWritebuffer($hash,
                       FW_longpollInfo("JSON", defined($ret) ? $ret : "")."\n");
    $hash->{BUF} = substr($hash->{BUF}, $i+$len);
    FW_Read($hash, 1) if($hash->{BUF});
    return;

[timmib]

Also es liegt nicht an einem bestimmten Gerät.

Ich habe eine Stelle gefunden, wo es im Browser aufhört. Das Device habe ich deaktiviert, aber es passiert weiterhin.

Außerdem habe ich mal FW_addToWritebuffer ausgegeben und dort sind auch immer nur Nachrichten kleiner 65536.

Können wir da mal gemeinsam draufschauen?

[rudolfkoenig]

Außerdem habe ich mal FW_addToWritebuffer ausgegeben und dort sind auch immer nur Nachrichten kleiner 65536.

Ich meine so einfach ist die Pruefung auf "gueltiges UTF-8" nicht.

[timmib]

Ja, die Länge war eine andere Vermutung als das UTF-8.

Wie geschrieben, ich habe eine Stelle gefunden wo er aussteigt. Das war aber eine "normales" Homematicgerät mit dem es Serverseitig weiterging und im Client nicht. Die Deaktivierung dieses Homematicgeräts hat auch nix gebracht.

[herrmannj]

FW_Read ist korrekt.
Eigentlich muss man Daten FHEM-intern als UTF-8 vorhalten, leider halten sich manche Module nicht strikt an diese Richtlinie.
Jetzt muesste man das Modul rausfinden, das der Verursacher ist.

ähhm. sorry für kapern - aber fhem intern UTF-8 per policy? Als Character Stream oder Bytestream? Wo steht das denn? Im Kern würde ichs gut finden - macht aber konkret keinen Sinn. Perl intern ist theoretisch unicode. UTF8 ist ja nur eine (externe) Spezifikation und dort gilts es zwischen https://perldoc.perl.org/perlunicode#Byte-and-Character-Semantics zu unterscheiden. Wenn wir uns darauf einigen könn(t)en dass fhem intern alles Unicode ist und alle Schnittstellen extern utf8 byte (unless otherwise specified;) ), das wäre gut. Dann würde length('ö') immer 1 ergeben und/oder diverse regex vorhersagbarer funktionieren. Falls ich was verpasst habe, lern ich gern nach .

[timmib]

Lieber Rudolf,

du hattest natürlich Recht.

Der Schuldige war https://forum.fhem.de/index.php/topic,113820.165.html

Der Umlaut in "Verstärken" im Reading wurde auch im FHEM-WebUI als Fragezeichen in einer Raute dargestellt. Ich sag dem Entwickler bescheid.

Da ist aber noch ein Modul.... grrr.

[rudolfkoenig]

Als Character Stream oder Bytestream?

UTF-8 als Character-Stream sagt mir nichts, insofern Bytestream. Es ist mir klar, dass andersrum auch Vorteile hat, allerdings sind diese gegenueber der aktuell verwendeten nicht so gewaltig, dass ein Umbau aller(!) input/output Schnittstellen sich deswegen lohnen wuerde.

[justme1968]

das fhem intern alles als utf-8 vorhält bzw. vorhalten soll ist nur die halbe wahrheit. die internen strings sind nur byte folgen im utf-8 encoding die bei ausgabe über fhemweb als utf-8 encoded verkauft werden. es sind aber keine echten perl utf-8 (upgraded) strings. das bedeutet leider das alle perl routinen die auf zeichen basis arbeiten wie regex, in, explizite längen bestimmung oder implizite bei printf nicht korrekt funktionieren sobald ein charakter mit mehr als einem byte ins spiel kommt. typischweise sind das alle umlaute. deshalb gibt es intern auch schon einige workarounds bei einigen regexen.

das umstellen auf korrektes und vollständiges unicode handling wär zwar mit einigem aufwand verbunden, hätte am ende aber so viele vorteile das ich dafür wäre das zu stemmen. nicht zuletzt würden damit künstliche einschränkung für device und reading namen weg fallen die es nämlich genau deshalb gibt weil die diversen regexe die auf word oder zeichen matchen für die fhem ,unicode' variante nicht funktionieren wie sie sollten.

vielleicht könnte man damit anfangen fälle und testdaten zu sammeln die aktuell nicht so arbeiten wie erwartet und wünschenswert. sowie tesfälle die das aktuelle verhalten fest halten und das verhalten nach einer umstellung gegenpüfen. ich denke das es den aufwand wert wäre. das gewurschtel das wir immer wieder mit diesem thema haben ist 2022 und eigentlich schon länger nicht mehr zeitgemäß.

[herrmannj]

Ich würde das auch gut finden. Bitte gleich Unicode intern, alles nach aussen utf8. Das wird weh tun weil unzählige workarounds existieren und ehrlich gesagt weiß ich auch nicht genau wie wir das stemmen können weil ich es für unrealistisch halte alle Module zeitgleich umzubauen. Nichts desto trotz, echt nicht mehr zeitgemäß und das sind Versäumnisse der Vergangenheit. Aussitzen geht vielleicht, aber auch nicht ewig und besser wird's auch nicht.