Hallo Rudi,
ich habe etwas mit global encode=unicode experimentiert.
Dabei ist mir der Fehler
Unknown encoding '"UTF-8"' at FHEM/HttpUtils.pm line 1061aufgefallen der zum sofortigen FHEM Absturz führt.
Meiner Meinung nach wird ein Header von irgendeinem angefragten Webserver empfangen der den String
...charset="UTF-8" anstatt ...charset=UTF-8
enthält. Encode kommt damit nicht klar und lässt Perl abstürzen.
Ich konnte HttpUtils.pm über die eingefügte Zeile "$encoding =~ s/['"]//g;" härten, sodass ein Absturz vermieden wird.
...
my $encoding = defined($hash->{forceEncoding}) ? $hash->{forceEncoding} :
$hash->{httpheader} =~ m/^Content-Type.*charset=(\S*)/im ? $1 :
'UTF-8';
$encoding =~ s/['"]//g;
...
Vllt. übernimmst du diesen Change da diese Gefahr m.M. immer auftreten kann?
LG,
Heiko
Danke fuer den Hinweis.
Ich habe jetzt das Entfernen der Anfuehrungszeichen uebernommen, und auch den Absturz fuer unbekannte charsets abgefangen.
Welcher Webserver schickt sowas?
Ich habe auf Anhieb keinen gefunden.
Danke Rudi.
ZitatWelcher Webserver schickt sowas?
Habe ich noch nicht herausgefunden. Die ich in Verdacht hatte (API's von Fully Android, Synology) sind unschuldig.
Habe noch nicht weiter intensiv gesucht. Mir war es wichtig generell solche Situationen zu vermeiden.
Durch die UND Verküpfung ($unicodeEncoding && $encoding) macht es sich erst durch encode=unicode bemerbar.
Hallo Rudi,
jetzt habe ich auch den Sender des Content herausgefunden.
In HttpUtils ergänzt:
if($unicodeEncoding && $encoding) {
if ($encoding =~ /["']/ ) {
Log3 $hash, 1, "HttpUtils response called url: ".$hash->{url};
Log3 $hash, 1, "HttpUtils response with wrong charset in header:\n$hash->{httpheader}" if($hash->{httpheader});
}
$encoding =~ s/["']//g; #138273
eval { $ret = Encode::decode($encoding, $ret) };
return $@ if($@);
}
Anhand der Url konnte ich nun doch die Synology Web-API als Übeltäter ermitteln:
Zitat2024.05.20 13:26:34.819 1: HttpUtils response called url: http://192.168.2.10:5000/webapi/auth.cgi?api=SYNO.API.Auth&version=6&method=Login ....
2024.05.20 13:26:34.820 1: HttpUtils response with wrong charset in header:
HTTP/1.1 200 OK
Server: nginx
Date: Mon, 20 May 2024 11:26:34 GMT
Content-Type: text/plain; charset="UTF-8"
Connection: close
Vary: Accept-Encoding
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
P3P: CP="IDC DSP COR ADM DEVi TAIi PSA PSD IVAi IVDi CONi HIS OUR IND CNT"
Vllt. macht es Sinn die Logausgabe für ein Debugging umzubauen und drin zu lassen.
LG
ZitatVllt. macht es Sinn die Logausgabe für ein Debugging umzubauen und drin zu lassen.
"Leider" sind die Quotes laut Spec https://datatracker.ietf.org/doc/html/rfc7231#section-3.1.1.1 erlaubt, jedenfalls enthaelt einer der Beispiele die Anfuehrungszeichen :)
Nach etwas graben in den RFCs: laut https://datatracker.ietf.org/doc/html/rfc7230#section-3.2.6 sind nur doppelte Anfuehrungszeichen erlaubt. Ich habe HttpUtils.pm entsprechend angepasst.