Autor Thema: [HttpUtils] Fallback auf HTTP wenn IO::Socket::SSL nicht geladen werden kann  (Gelesen 215 mal)

Offline Loredo

  • Developer
  • Hero Member
  • ****
  • Beiträge: 2806
  • ~ Challenging Innovation ~
Hi,


derzeit versucht HttpUtils eine unverschlüsselte Verbindung aufzubauen, wenn IO::Socket::SSL nicht geladen werden kann:



2017.03.20 10:39:02.669 4: HttpUtils url=https://api.pushover.net:443/1/users/validate.json
2017.03.20 10:39:02.794 4: Can't locate IO/Socket/SSL.pm in @INC (you may need to install the IO::Socket::SSL module) (@INC contains: . /usr/local/Cellar/perl/5.24.1/lib/perl5/site_perl/5.24.1/darwin-thread-multi-2level /usr/local/Cellar/perl/5.24.1/lib/perl5/site_perl/5.24.1 /usr/local/Cellar/perl/5.24.1/lib/perl5/5.24.1/darwin-thread-multi-2level /usr/local/Cellar/perl/5.24.1/lib/perl5/5.24.1 /usr/local/lib/perl5/site_perl/5.24.1 ./FHEM) at (eval 61) line 2.
BEGIN failed--compilation aborted at (eval 61) line 2.


2017.03.20 10:39:02.794 5: HttpUtils request header:
POST /1/users/validate.json HTTP/1.0
Host: api.pushover.net
User-Agent: fhem
Content-Length: 72
Content-Type: application/x-www-form-urlencoded


2017.03.20 10:39:02.967 4: https://api.pushover.net:443/1/users/validate.json: HTTP response code 400
2017.03.20 10:39:02.967 4: HttpUtils https://api.pushover.net:443/1/users/validate.json: Got data, length: 264
2017.03.20 10:39:02.967 5: HttpUtils response header:
HTTP/1.1 400 Bad Request
Date: Mon, 20 Mar 2017 09:39:02 GMT
Content-Type: text/html
Content-Length: 264
Connection: close


Das ist aber eigentlich unnütz, denn wie man sieht erwartet ein Server verständlicherweise, dass auf dem Port auf TLS umgeschaltet wird und man wird so nie eine 200er Antwort erhalten, ohne dass man auch auf den unverschlüsselten Port wechselte (was auch nur automatisch ginge, wenn die Standardports verwendet würden).
Außerdem ist es denke ich keine gute Idee einfach eine unverschlüsselte Verbindung aufzubauen, wenn eigentlich explizit eine verschlüsselte Verbindung seitens des Modulautors angefordert wurde.


Beiliegender Patch als Vorschlag dies zu ändern.




Gruß
Julian
FHEM-Module: ENIGMA2, GEOFANCY, ONKYO_AVR, PHTV, RESIDENTS, ROOMMATE, GUEST, HP1000, powerMap, Pushover, THINKINGCLEANER, Wunderground | FHEM-Befehl: msg

FHEM 5.9dev auf Intel NUC mit Proxmox VE
Homematic via HMCCU, Hue Color Bulbs
ONKYO TX-NR626, Philips 55" PFL8008S, Sonos 1xS1, 1xS3, 2xS5

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 16423
Hab den Patch mit leichten Aenderungen eingecheckt:
- da ich alle hu_XXX Variablen nach einem Close entfernen will, habe ich kein hu_sslError eingebaut.
- ich will nicht Fehlermeldungen umdichten, habe deswegen die urspruengliche Fehlermeldung zurueckgeliefert.

Offline Loredo

  • Developer
  • Hero Member
  • ****
  • Beiträge: 2806
  • ~ Challenging Innovation ~
Hervorragend, danke!


Gibt es denn eine Möglichkeit zu unterscheiden, ob eine Anfrage aufgrund eines nicht ladbaren Perl Moduls nicht abgesendet oder ob einfach ein Timeout erreicht wurde?
Dafür war hu_sslError gedacht.
FHEM-Module: ENIGMA2, GEOFANCY, ONKYO_AVR, PHTV, RESIDENTS, ROOMMATE, GUEST, HP1000, powerMap, Pushover, THINKINGCLEANER, Wunderground | FHEM-Befehl: msg

FHEM 5.9dev auf Intel NUC mit Proxmox VE
Homematic via HMCCU, Hue Color Bulbs
ONKYO TX-NR626, Philips 55" PFL8008S, Sonos 1xS1, 1xS3, 2xS5

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 16423
Bei timeout sollte die Fehlermeldung den String "timed out" enthalten (wenn nicht bitte melden).
Beim Modul-Ladeproblemen gehe ich davon aus, dass das Problemmodul (IO/Socket/SSL.pm) in der Fehlermeldung erwaehnt wird.

 

decade-submarginal