Neuigkeiten:

Am Sonntag den 8.12.2024 kann es ab ca. 8:00 Uhr zu kurzzeitigen Einschränkungen / Ausfällen bei den Diensten des FHEM Vereines kommen.
Die Server müssen mal gewartet und dabei neu gestartet werden ;)

Hauptmenü

Unknown encoding '"UTF-8"' at FHEM/HttpUtils.pm line 1061

Begonnen von DS_Starter, 19 Mai 2024, 11:38:29

Vorheriges Thema - Nächstes Thema

DS_Starter

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
Proxmox+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

rudolfkoenig

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.

DS_Starter

#2
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.
Proxmox+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

DS_Starter

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
Proxmox+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

rudolfkoenig

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.