Hallo,
ich bin nicht sicher ob das hier der richtige Teil des Forums ist, falls nicht bitte den Beitrag verschieben.
Mir war durch Probleme mit dem Auflösen von Telefonnummern in FB_CALLMONITOR aufgefallen, dass das Folgen von HTTP Redirects in CustomGetFileFromURL nicht sehr robust ist. Insbesondere funktioniert es nur dann, wenn der Location-Header gleich in der zweiten Zeile der Response steht. Der angehängte Patch behebt das, außerdem hab ich das Logging so angepasst, dass überall der eingestellte Loglevel berücksichtigt wird.
Gruß Wolfgang
Hallo,
Patch ist gut. Danke.
Ich habe gleich noch alle Stellen überarbeitet, wo trotz $quiet URLs gezeigt werden. Neuer Patch gegen HEAD in der Anlage.
Rudi, checkst Du es bitte ein?
Grüße
Boris
Hallo,
aktuell erkennt HttpUtils eine Umleitung nur bei HTTP Status 301 (Moved Permanently). Allerdings ist im HTTP Protokoll auch eine Umleitung mit Status 302 (Found) und 303 (See Other) möglich. Alle 3 Varianten sind im Internet weit geläufig.
Es währe daher toll, wenn man die if-Bedingung auf Status 302 und 303 erweitern würde.
Gruß
Markus
Habs mit kleinen Aenderungen (u.a. 302&303) eingecheckt.
Default loglevel habe ich von 1 auf 4 geaendert, sonst befuerchte ich einen Aufstand.
Die Version scheint Schwierigkeiten mit gesicherten https URLs zu haben :-\
Wenn ich eine https URL abfrage, bekomme ich Fehler:
2013.12.20 02:41:41 5: ENIGMA2 LR_SAT: GET https://192.168.6.50:443/web/powerstate?
Use of uninitialized value $code in concatenation (.) or string at FHEM/HttpUtils.pm line 150.
Use of uninitialized value $code in numeric eq (==) at FHEM/HttpUtils.pm line 153.
Use of uninitialized value $code in numeric eq (==) at FHEM/HttpUtils.pm line 153.
Use of uninitialized value $code in numeric eq (==) at FHEM/HttpUtils.pm line 153.
Kannst du bitte die erste Zeile des Headers hier posten?
Scheint so, dass kein Status-Code zurueckgeliefert wird.
Im Response-Header scheint er zu fehlen, ja:
Request Headers:
GET /web/powerstate? HTTP/1.1
Host: 192.168.6.50
Connection: keep-alive
Cache-Control: max-age=0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.48 Safari/537.36
DNT: 1
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8,da;q=0.6,de;q=0.4,sl;q=0.2
Response Header
Content-Type:text/xml
Date:Sun, 22 Dec 2013 12:49:08 GMT
Server:TwistedWeb/12.0.0
Transfer-Encoding:chunked
Response Header:
Transfer-Encoding: chunked
Date: Sun, 22 Dec 2013 12:55:27 GMT
Content-Type: text/xml
Server: TwistedWeb/12.0.0
Die Antwort sieht bei der Abfrage über normales HTTP aber genauso wird, wird vom HttpUtils Modul jedoch korrekt verarbeitet.
Gruß
Julian
Korrektur, ist vorhanden:
HTTP/1.1 200 OK
Transfer-Encoding: chunked
Date: Sun, 22 Dec 2013 12:55:27 GMT
Content-Type: text/xml
Server: TwistedWeb/12.0.0
Mit diesem Header sollte es keine Fejlermeldungen geben.
Kannst Du bitte eine komplette Antwort (header+body), die Fehler verursacht, hier als Attachement hochladen?
wget -qO- --server-response [size=78%]http://192.168.6.50:80/web/powerstate? (http://192.168.6.50:80/web/powerstate?)[/size]
HTTP/1.1 200 OK
Transfer-Encoding: chunked
Date: Mon, 23 Dec 2013 08:36:37 GMT
Content-Type: text/xml
Server: TwistedWeb/12.0.0
<?xml version="1.0" encoding="UTF-8"?>
<e2powerstate>
<e2instandby>
false </e2instandby>
</e2powerstate>
wget -qO- --no-check-certificate --server-response https://192.168.6.50:443/web/powerstate? (https://192.168.6.50:443/web/powerstate?)
HTTP/1.1 200 OK
Transfer-Encoding: chunked
Date: Mon, 23 Dec 2013 08:38:00 GMT
Content-Type: text/xml
Server: TwistedWeb/12.0.0
<?xml version="1.0" encoding="UTF-8"?>
<e2powerstate>
<e2instandby>
false </e2instandby>
</e2powerstate>
Es gibt auch noch ein anderes seltsames Verhalten, vielleicht hängt das irgendwie mit hinein:
http://forum.fhem.de/index.php/topic,14792.msg117866.html#msg117866
Dort haben wir beobachtet, dass man einige bestimmte Seiten nicht via GET anfragen kann, sondern nur per POST. Dies zeigte sich allerdings nur auf einer Fritzbox so und irgendwie konnten wir uns da keinen Reim drauf machen...
Das von dir gepostete Antwort ist mAn kein gueltiges HTTP: zwischen Header und Inhalt fehlt die leere Zeile. Vermutlich duerfen Headerzeilen auch nicht mit Leerzeichen anfangen, beides ist fuer GetHttpFile relevant. Ist das sicher kein Copy&Paste Artifakt? Um das zu vermeiden wollte ich ein Attachement. Wenn es kein Copy&Paste Fehler ist, dann muss ich das passende HTTP-RFC nochmal durchlesen.
Zitatanderes seltsames Verhalten
Der verlinkte Artikel verwirrt mich mehr, als es mir hilft: Was hat das mit Redirects zu tun? Bitte nicht alle Probleme die mit einem Computer zu tun haben, in diesem Thread loesen wollen.
$fritzbox ist vmtl Unsinn: $noshutdown muss gesetzt sein, falls man den Webserver auf dem Fritzbox anspricht, der vertraegt kein shutdown(1). Wo der Aufruf herkommt, ist egal, d.h. ihr musst $noshutdown entweder auf 1 setzen, falls der Enigma2-Webserver shutdown(1) nicht kapiert, oder sonst auf 0 lassen.
Zitat von: rudolfkoenig am 23 Dezember 2013, 10:35:45
Der verlinkte Artikel verwirrt mich mehr, als es mir hilft: Was hat das mit Redirects zu tun? Bitte nicht alle Probleme die mit einem Computer zu tun haben, in diesem Thread loesen wollen.
Ich nahm an, dass Änderungen beim Redirect dazu geführt haben, dass die Status Codes bei HTTPS nicht mehr richtig verarbeitet werden.
Zitat von: rudolfkoenig am 23 Dezember 2013, 10:35:45
Das von dir gepostete Antwort ist mAn kein gueltiges HTTP: zwischen Header und Inhalt fehlt die leere Zeile. Vermutlich duerfen Headerzeilen auch nicht mit Leerzeichen anfangen, beides ist fuer GetHttpFile relevant. Ist das sicher kein Copy&Paste Artifakt? Um das zu vermeiden wollte ich ein Attachement. Wenn es kein Copy&Paste Fehler ist, dann muss ich das passende HTTP-RFC nochmal durchlesen.
Es kommt per C&P aus der OSX-Shell. Die Ausgabe dort hat wget erstellt und ich vermute stark, dass das Programm das Einrücken bewirkt hat. Wenn ich per Telnet auf den Port gehe, sind keine Leerzeichen am Anfang. Die Ausgabe sieht auch bei anderen Webseiten so aus.
Anbei als Datei (wget -q -S -O - --no-check-certificate --server-response https://192.168.6.50:443/web/powerstate 1>powerstate.txt 2>&1).
Zitat von: rudolfkoenig am 23 Dezember 2013, 10:35:45$fritzbox ist vmtl Unsinn: $noshutdown muss gesetzt sein, falls man den Webserver auf dem Fritzbox anspricht, der vertraegt kein shutdown(1). Wo der Aufruf herkommt, ist egal, d.h. ihr musst $noshutdown entweder auf 1 setzen, falls der Enigma2-Webserver shutdown(1) nicht kapiert, oder sonst auf 0 lassen.
Ah, ok. Danke für die Aufklärung!
Gruß
Julian
Die angehaengte Datei ist identisch mit dem Zitat, nach der manuellen Korrektur hat der entsprechende Code aus HttpUtils.pm damit keine Probleme.
Ein Grund koennte sein, dass die Zeilen nicht mit CR/NL (wie in http://www.w3.org/Protocols/rfc2616/rfc2616-sec2.html#sec2.2 definiert ist) terminiert sind, sondern nur NL oder nur CR. Sowas wird aber durch wget oder Copy&Paste geaendert.
Mein Vorschlag: die Daten in HttpUtils.pm Zeile 145 per Log 1, $ret; auszugeben, und die komplette Log-Datei hier anhaengen.
Hallo Rudi,
ich habs probiert wie von dir vorgeschlagen. Die resultierende Datei scheint mir aber wenig hilfreich - es wird nur eine leere Variable ausgegeben. Anbei; ab Zeile 1027 habe ich von HTTP auf HTTPS Kommunikation umgeschaltet.
Könnte es an dem nicht vertrauenswürdigen Zertifikat liegen?
Aus IO::Socket::SSL Doku
Zitat
SSL_verify_mode
This option sets the verification mode for the peer certificate. You may combine SSL_VERIFY_PEER (verify_peer), SSL_VERIFY_FAIL_IF_NO_PEER_CERT (fail verification if no peer certificate exists; ignored for clients), SSL_VERIFY_CLIENT_ONCE (verify client once; ignored for clients). See OpenSSL man page for SSL_CTX_set_verify for more information.
The default is SSL_VERIFY_NONE for server (e.g. no check for client certificate) and SSL_VERIFY_PEER for client (check server certificate).
Demnach muss man inzwischen vielleicht auch für die Client-Kommunikation explizit SSL_VERIFY_NONE setzen. Ich werde aber aus der Doku nicht ganz schlau und konnte es demnach nicht austesten.
(Und ja, spätestens jetzt vermische ich die Themen in der Tat! Ich wollte dir aber hier antworten ::)
- feel free to open a new thread ;) )
Aus dem Log werde ich nicht schlau: ich sehe da nicht mal einen Hinweis auf die Umleitung.
Die Beschreibung zu SSL_verify_mode verstehe ich auch nicht wirklich, testen kann ich aber noch weniger als Du.
Ich sagte ja, man sieht, dass man nichts sieht :-\
Eine Umleitung findest du in dem Log auch nicht. Man sieht die Abfragen wie sie ohne SSL laufen. Dann füge ich dem Objekt ein HTTPS=1 hinzu und die dann weitere Abfrage wird mit einer HTTPS-URL statt HTTP-URL ausgeführt. Daraufhin sieht man, dass an der Stelle, wo sonst der HTTP-Body ausgegeben wird, gar nichts mehr ausgegeben wird.
Ich vermute daher, dass IO::Socket::SSL hier nicht besonders gesprächig ist und die Verbindung einfach nicht aufbaut, weil der SSL-Handshake schon nicht akzeptiert wird, da das Zertifikat selbst signiert ist. Scheint aber auch keine unbedingt verlässliche Theorie, siehe unten...
Nachstellen kannst du das auch ohne eine Dreambox o.ä., sofern du das ENIGMA2 Modul dafür nehmen wolltest. Bis zu dieser Stelle kommt man mit jedem HTTPS Webserver.
Hier ein Beispiel mit vermeintlich vertrautem SSL Zertifikat (je nach Distribution); funktioniert bei mir wie es soll.
define httpsTest ENIGMA2 www.cacert.org 443
attr httpsTest https 1
Hier ein Beispiel mit vertrautem SSL Zertifikat; was trotzdem nicht funktioniert.
define httpsTest ENIGMA2 homebanking.sskm.de 443
attr httpsTest https 1
Hier ein Beispiel mit selbst signiertem Zertifikat, was seltsamer Weise funktioniert:
define httpsTest ENIGMA2 makecert.com 443
attr httpsTest https 1
So kann man es mit verschiedenen Seiten durchprobieren. Ich erkenne irgendwie kein richtiges Muster.
Gruß
Julian
Ich komme damit auch nicht weiter.
Habe Hoffnung in SSL_error_trap gesetzt, sie wird aber bei mir nicht aufgerufen.
Immerhin werden ab sofort die Fehlermeldungen verhindert.