[gelöst]"unsupported HTTP method HEAD" verhindert streamen von RSS jpg/png an TV

Begonnen von frank, 07 Februar 2018, 14:36:00

Vorheriges Thema - Nächstes Thema

frank

hallo rudi,

beim versuch die vom rss-modul bereitgestellten bilder über dlna an einen tv zu streamen, erhalte ich meldungen, dass die methode HEAD nicht unterstützt wird. schlimmer ist allerdings, dass der tv dadurch den streaming versuch beendet. wahrscheinlich möchte er vor dem GET genau wissen, was ihn erwartet.

2018.02.01 20:25:57.600 4: DLNAClient: start play for http://192.168.1.25:8083/fhem/rss/rss_fon.jpg
2018.02.01 20:25:57.601 5: DLNAClient: setAVTransportURI Start
2018.02.01 20:25:57.681 3: WEB_192.168.1.26_54314: unsupported HTTP method HEAD, rejecting it.
2018.02.01 20:25:57.709 5: DLNAClient: setAVTransportURI End


eine kleine änderung in 01_FHEMWEB.pm ermöglicht das streamen zumindestens schon mal auf einem modell (andere werden in kürze sicherlich folgen):
if($method !~ m/^(GET|POST|HEAD)$/i){


eine kurze suche zum thema "method head" brachte mir aber gerade dieses etwas ernüchternde, aber schon alte zitat:

Zitat von: rudolfkoenig am 23 Januar 2017, 21:53:19
HEAD war nie richtig implementiert, FHEMWEB liefert die Daten immer komplett zurueck. Es richtig zu implementieren waere aufwendig, weiterhin is HEAD in diesem Fall nicht adaequat. Bitte die andere Applikation anpassen.

1. hat sich eventuell der aufwand in der zwischenzeit vereinfacht?
2. was genau wäre denn aufwändig? nach meinem derzeitigen verständnis ist eine antwort auf HEAD wie bei einem GET, aber ohne body. also content-lenght=0.
3. wäre es denkbar, solch eine "kastrierte" GET antwort zumindestens über attribut zu erlauben?
4. oder würdest du vielleicht mit einem attr sendGetAnswerToHead den wohl bis vor einem jahr gängigen zustand wieder erlauben? gab es konkrete probleme, dass eine HEAD anfrage nun ordnungsgemäss abgelehnt wird, da fhem sie noch nicht beantworten kann?

zur zeit muss man einen zusätzlichen server aufsetzen und diesen ständig mit aktuellen bildern füttern.

gruss frank
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

rudolfkoenig

1. Nein.
2. Die Daten werden an mehreren Stellen zurueckgeliefert, und diese kennen nicht die Methode.
3. _ich_ (bzw. FHEMWEB) habe damit kein Problem, aber die andere Seite, weil die keine Daten erwarten.
4. wo ist das Unterschied zu 3?

KölnSolar

Hi Rudi,
ich hatte auch die entsprechende Diskussion zwischen Dir und André dazu im Sommer gesehen, wo Du ja empfahlst, die Gegenseite entsprechend anzupassen. Da es sich in unserm Fall um die Firmware eines Geräts(TV) handelt, ist das ja leider nicht möglich  :'( Es sei denn, Du hättest einen Tipp, wie wir das abfangen/beeinflussen könnten  :-\

Wenn ich das mit meinem Fünftelwissen halbwegs verstehe, wird derzeit rigoros die Anfrage mit HEAD abgelehnt. Würde man sie, wie von Frank u. André vorgeschlagen zulassen, dann passiert ja in FHEM erst mal nichts schlimmes, sondern es wird nur wie im Falle einer GET-Anfrage geantwortet. Wenn ich Dein 3. richtig verstehe, sorgst Du Dich aber jetzt, dass die Gegenstelle mit der eigentlich zu umfangreichen Antwort nicht klar kommt. Das ist in unseren Fällen aber gerade nicht der Fall, sondern es funktioniert einwandfrei. Und nun frage ich mich, wo der Gewinn/Vorteil ist, HEAD nicht zuzulassen  :-\ Ich sehe nur die cases

1. aktuelle Version FHEMWEB lehnt rigoros ab --> Kommunikation bzgl. HEAD-Anfragen wird mit Logmeldung level=3 unterbunden;Geräte
    funktionieren nicht.
2. angepasste Vers. lässt HEAD-Anfragen zu und behandelt diese wie GET; (NEUE) Logmeldung level=4 als potentieller Fehlerhinweis
a) manche Geräte funktionieren bei HEAD-Anfragen einwandfrei. Hier sehe ich den Gewinn für FHEM.
b) manche nicht :'(  aber who cares, da kein Unterschied zu 1. Nichts gewonnen aber auch nichts verloren.

Aber vielleicht übersehe ich ja auch etwas, das mit Deinem Wissen Bauchschmerzen auslöst.

Kölle Alaaf
Markus
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

rudolfkoenig

Du hast die Alternative des "Dazulernens" ausgelassen: FHEM sagt HEAD geht nicht, Client versucht GET als Fallback: alles funktioniert wie im Spec. Vorschlag: FHEMWEB Attribut, und ich weise in der Doku explizit auf das Problem hin, damit ist der schwarze Peter nicht mehr bei mir.

KölnSolar

Schöner Vorschlag  ;)

ZitatFHEM sagt HEAD geht nicht, Client versucht GET als Fallback: alles funktioniert wie im Spec.
Das ist schon richtig.

D.h. Du erwartest, dass manche Geräte mit dem zusätzlichen Attribut auf die Nase fallen, weil Sie die response incl. body nicht als korrekte Antwort interpretieren, mangels "deutlicher" Info bitte per GET anzufragen, dies dann nicht mehr tun und folglich die Kommunikation abbrechen ?

Aus unserer Sicht ist es einen Versuch wert  8)
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

frank

Zitat von: rudolfkoenig am 08 Februar 2018, 09:46:54
Du hast die Alternative des "Dazulernens" ausgelassen: FHEM sagt HEAD geht nicht, Client versucht GET als Fallback: alles funktioniert wie im Spec. Vorschlag: FHEMWEB Attribut, und ich weise in der Doku explizit auf das Problem hin, damit ist der schwarze Peter nicht mehr bei mir.

ich habe gerade noch mal versucht eine spec zu HEAD zu finden.
https://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.4

Zitat9.4 HEAD

The HEAD method is identical to GET except that the server MUST NOT return a message-body in the response. The metainformation contained in the HTTP headers in response to a HEAD request SHOULD be identical to the information sent in response to a GET request. This method can be used for obtaining metainformation about the entity implied by the request without transferring the entity-body itself. This method is often used for testing hypertext links for validity, accessibility, and recent modification.

The response to a HEAD request MAY be cacheable in the sense that the information contained in the response MAY be used to update a previously cached entity from that resource. If the new field values indicate that the cached entity differs from the current entity (as would be indicated by a change in Content-Length, Content-MD5, ETag or Last-Modified), then the cache MUST treat the cache entry as stale.

hiernach (erster satz) verstehe ich eigentlich nicht, warum HEAD generell abgelehnt wird.
head ist identisch zu get mit einer ausnahme. der server hat die wahl, ob die antwort mit oder ohne content erfolgt. deine augenblickliche vorgehensweise head abzulehnen, um dadurch explizit ein get zu bekommen, verursacht doch eigentlich nur mehr kommunikation/traffic. dann doch besser sofort bei head antworten.

ich kann aber auch gut mit einem attribut leben.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

rudolfkoenig

Zitathiernach (erster satz) verstehe ich eigentlich nicht, warum HEAD generell abgelehnt wird.
Weil "MUST NOT" im Deutschen "DARF NICHT" heisst, siehe auch https://www.ietf.org/rfc/rfc2119.txt:
Zitat2. MUST NOT   This phrase, or the phrase "SHALL NOT", mean that the
definition is an absolute prohibition of the specification
Das klingt fuer mich nicht nach Wahl :)

Ich habe jetzt allowedHttpMethods implementiert:
ZitatallowedHttpMethods
  FHEMWEB implements the GET, POST and OPTIONS HTTP methods. Some external
  devices require the HEAD method, which is not implemented correctly in
  FHEMWEB, as FHEMWEB always returns a body, which, according to the spec,
  is wrong. As in some cases this not a problem, enabling GET may work.
  To do this, set this attribute to GET|POST|HEAD, default ist GET|POST.
  OPTIONS is always enabled.
Wenn SVN wieder geht, dann werde ich es einchecken.

rudolfkoenig


frank

Zitat von: rudolfkoenig am 08 Februar 2018, 12:56:49
Habs eingecheckt.
danke, ... auch für die englisch nachhilfe.

ZitatWeil "MUST NOT" im Deutschen "DARF NICHT" heisst
ein ami sagte mir allerdings dazu: "must not" sei kein verbot.  :)
deshalb wohl auch die explizite klarstellung durch rfc2119.


ich habe nun auch noch folgendes zum response code=200 gefunden: https://tools.ietf.org/html/rfc2616#section-10.2.1
ZitatHEAD   the entity-header fields corresponding to the requested
          resource are sent in the response without any message-body;


vielleicht gibt es eines tages doch noch ein echtes HEAD.  ;)
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

rudolfkoenig

Habe gerade eine schoene Erklaerung fuer Programmierer gefunden: im Deutschen werden Hilfsverben (must, may, etc) mit "not" anders geklammert:
DE: "the server (must not) return a message body"
EN: "the server must (not return) a message body"

Btw: ich wuesste gerne, ob in eurem Fall mein Patch ueberhaupt hilft.

Det20


rudolfkoenig

Klar. Eingecheckt heisst ist im SVN, und ist morgen ab 8 per FHEM-update verfuegbar.

Det20

Da, teste ich. Ist aber ein Fehler in der Doku drin:


      FHEMWEB implementiert die HTTP Methoden GET, POST und OPTIONS. Manche
      externe Geräte benötigen HEAD, das ist aber in FHEMWEB nicht
      korrekt implementiert, da FHEMWEB immer ein body zurückliefert, was
      laut Spec falsch ist. Da ein body in manchen Fällen kein Problem
      ist, kann man HEAD durch setzen dieses Attributes auf HEAD|POST|HEAD
      aktivieren, die Voreinstellung ist HEAD|POST. OPTIONS ist immer
      aktiviert.


die Voreinstellung ist HEAD|POST

rudolfkoenig

Danke, habs gefixt. Bis zum morgigen update empfehle ich die englische Variante.

frank

das attribut allowedHttpMethods funktioniert, wie erhofft.

1. ohne attr kein stream.
2. mit GET|POST|HEAD stream möglich.
3. mit GET|POST wieder kein stream.

kleiner schönheitsfehler: wenn noch kein attribut vorhanden ist, wird bei der auswahl über die selectbox kein defaultwert im eingabefeld angezeigt, also nur ein leeres eingabefeld.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

rudolfkoenig

Zitatkleiner schönheitsfehler: wenn noch kein attribut vorhanden ist, wird bei der auswahl über die selectbox kein defaultwert im eingabefeld angezeigt, also nur ein leeres eingabefeld.
Das Anzeigen der Voreinstellung bei einem Attribut ist bei der aktuellen Architektur unmoeglich, dafuer waeren grundlegende Umbauten noetig. Das Modul kann fuer Attribute mit Auswahlfelder(!) eine Reihenfolge vorgeben, beim Freitext gibts das nicht.

KölnSolar

Hi Rudi,
danke für die Modifikation. Bei mir funktioniert alles wie es soll. Bisher keine negativen Nebeneffekte festgestellt.
Grüße Markus
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

Det20


Kamik

Hallo zusammen,

Ich bin gerade über diesen Threads gestolpert auf der Suche nach einem Fehler meines webhooks zu netatmo:

WEBhook_178.156.202.81_62618: unsupported HTTP method HEAD, rejecting it.

Der webhook erhält keine Informationen mehr seit Anfang Juni.

Könnte das etwas mit eurem Thema zu tun haben?

Gruß Kamik

Gesendet von meinem SM-G950F mit Tapatalk


frank

hallo Kamik,
ich denke, du verwechselst ursache und wirkung.

das in diesem thread neu vorgestellte attr allowedHttpMethods könnte aber dein problem lösen, wenn du für das benutzte webdevice des webhook "attr <device> allowedHttpMethods GET|POST|HEAD" setzt.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

Kamik

Zitat von: frank am 23 Juni 2019, 20:58:21
hallo Kamik,
ich denke, du verwechselst ursache und wirkung.

das in diesem thread neu vorgestellte attr allowedHttpMethods könnte aber dein problem lösen, wenn du für das benutzte webdevice des webhook "attr <device> allowedHttpMethods GET|POST|HEAD" setzt.
Hi Frank,
das habe ich jetzt Mal gesetzt. Mein webhook läuft ja auch über die Instanz Fhemweb. Danke, ich werde berichten.

Gruß

Gesendet von meinem SM-G950F mit Tapatalk


frank

du könntest auch ein weiteres webdevice nur für den webhook anlegen.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

Kamik

Zitat von: frank am 23 Juni 2019, 21:06:12
du könntest auch ein weiteres webdevice nur für den webhook anlegen.
Das habe ich bereits getan.

Gesendet von meinem SM-G950F mit Tapatalk