Patch: Redirects in HttpUttils.pm

[wmr72]

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

[Dr. Boris Neubert]

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

[Markus Bloch]

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

[rudolfkoenig]

Habs mit kleinen Aenderungen (u.a. 302&303) eingecheckt.
Default loglevel habe ich von 1 auf 4 geaendert, sonst befuerchte ich einen Aufstand.

[Loredo]

Die Version scheint Schwierigkeiten mit gesicherten https URLs zu haben 
Wenn ich eine https URL abfrage, bekomme ich Fehler:

Code Auswählen Erweitern



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.


[rudolfkoenig]

Kannst du bitte die erste Zeile des Headers hier posten?
Scheint so, dass kein Status-Code zurueckgeliefert wird.

[Loredo]

Im Response-Header scheint er zu fehlen, ja:

Code Auswählen Erweitern


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

[Loredo]

Korrektur, ist vorhanden:

Code Auswählen Erweitern

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


[rudolfkoenig]

Mit diesem Header sollte es keine Fejlermeldungen geben.
Kannst Du bitte eine komplette Antwort (header+body), die Fehler verursacht, hier als Attachement hochladen?

[Loredo]

wget -qO- --server-response [size=78%]http://192.168.6.50:80/web/powerstate?[/size]

Code Auswählen Erweitern


  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?

Code Auswählen Erweitern


  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>


[Loredo]

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...

[rudolfkoenig]

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.

anderes 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.

[Loredo]

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.

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).

$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

[rudolfkoenig]

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.

[Loredo]

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

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 )