[GELÖST] Probleme mit Sonderzeichen unter RaspberryMatic (cURL, ReGa, lighttpd)

[blackhole]

Wurde der Fehler in RaspberryMatic zwischenzeitlich behoben?

Ich habe vor, den aktuell nur für RM-User eingebauten Workaround in der kommenden Version Alexa.sh (Release: Anfang April) wieder zu entfernen.

[jmaus]

Wurde der Fehler in RaspberryMatic zwischenzeitlich behoben?

Nochmal: Das ist kein Fehler in RaspberryMatic, sondern es wird hier lediglich eine neuere curl version eingesetzt die sich standardmäßig eben anders (aber im Grunde laut RFCs nicht falsch) verhält. Nur die ReGaHss kommt mit dieser Art des URL parameter encodings eben (noch) nicht klar und müsste angepasst werden.

[blackhole]

Nochmal: Das ist kein Fehler in RaspberryMatic

Natürlich ist das ein Fehler in RaspberryMatic: cURL ist nur halbherzig implementiert.
Entsprechende Hinweise zur Fehlerbehebung habe ich dir hier gegeben.

Überall anders funktioniert das einwandfrei (Original Firmware, Debian, etc. pp.).

[jmaus]

Nochmal: Das ist kein Fehler in RaspberryMatic

Natürlich ist das Fehler in RaspberryMatic. Überall anders funktioniert das einwandfrei.

Tut mir leid, aber die Aussage ist non-sense. Du weisst genauso gut wie ich das es "curl" selber ist welches dieses URL encoding macht und nicht "RaspberryMatic". Deine Vergleiche von CCU3 vs. RaspberryMatic hinken also mal wieder. Es geht hier lediglich um den Unterschied der curl version die in der CCU3 noch Verwendung findet und der aktuelleren curl versionen wie sie bei RaspberryMatic automatisch durch neuere Buildroot Versionen mitkommen. Und hier haben die CURL entwickler in neueren Versionen anscheinend eine Anpassung in der Art&Weise des URL encodings vorgenommen die jedoch meines bisherigen Erachtens im gegebenen Kontext vollkommen valide ist. Nur ist ReGaHss eben darauf noch nicht vorbereitet.

Entsprechende Hinweise zu Fehlerbehebung habe ich dir hier gegeben.

Diese Hinweise sind nett gemeint, sind aber leider IMHO nicht fundiert genug. Wenn du einfach mal die aktuellen Quellen von curl von der Hauptseite heruntergeladen hättest und ungepatcht kompiliert hättest, dann würdest du merken da sich neuere Versionen von curl wie von dir fest gestellt auch unter deinem Debian System so verhält. Zumindest stelle ich das hier unter Ubuntu 20.04 genauso fest. Dort ist die Standard curl version noch die 7.68.0 und die verhält sich wie die alte version in der CCU3. Und kompiliere ich darauf eine 7.81.0 curl version verhält sie sich eben logischerweise genauso wie unter neueren RaspberryMatic Versionen.

Und deine Bemerkung zu irgendwelchen (Debian)Patches kann ich nicht nachvollziehen. Schaue ich in das jeweilige Patchset des Debian-Paketes zu curl (https://sources.debian.org/patches/curl ... 3+deb11u1/) sehe ich dort keinerlei relevanten Patch der das URL encoding in irgendeiner weise anpassen/verändern sollte. Oder kannst du mir da irgendwie auf die Sprünge helfen wo genau du einen Patch von Debian siehst der das URL encoding verhalten neuerer curl versionen wieder auf das alte %XX Verfahren für Leerzeichen abändert? Ich sehe da nichts und auch wenn ich das Patchset komplett auf ein vanilla 7.81 curl anwende verhält es sich bei mir immer noch so das es Leerzeichen in URL parametern nun mit einem "+" substituiert.

Daher ist es IMHO weiterhin so, das man das Problem bei ReGaHss angehen sollte und dem Webserver beibringen sollte ein "+" zusätzlich zu einem "%20" als Leerzeichen zu erkennen, denn genau so ist das in der entsprechenden RFC auch vermerkt.

Aber wenn du wie gesagt andere fundiertere Infos hast dann gerne her damit. Bitte aber konkret werden und hier Links und referenzen aufzeigen damit man das auch entsprechend nachvollziehen kann.

[blackhole]

TDu weisst genauso gut wie ich das es "curl" selber ist welches dieses URL encoding macht und nicht "RaspberryMatic".

Ja, aber du hast cURL in RaspberryMatic nur halbherzig implementiert und damit steckt der Fehler in RaspberryMatic.

In allen anderen Distributionen (Original CCU3-Firmware, Debian, etc. pp.) ist cURL so implementiert, dass es richtig funktioniert.
Bei RaspberryMatic ist dies nicht der Fall.

Daher ist es IMHO weiterhin so, das man das Problem bei ReGaHss angehen sollte und dem Webserver beibringen sollte ein "+" zusätzlich zu einem "%20" als Leerzeichen zu erkennen, denn genau so ist das in der entsprechenden RFC auch vermerkt.

Ein Leerzeichen kann sowohl als "+" als auch als "%20" URL-encodiert werden. Beides kann richtig sein, beides kann aber auch völlig falsch sein. Maßgeblich ist, in welchem Kontext das zu encodierende Leerzeichen steht. Die original Firmware der CCU3 und Debian Stable erkennen das via cURL korrekt und encodieren das betroffene Leerzeichen korrekt mit "%20". RaspberryMatic macht genau diese Erkennung eben falsch und encodiert daher das betroffenen Leerzeichen fälschlicherweise mit "+", letztendlich weil dein cURL zu neu™ und ungepatcht ist.

[jmaus]

Und nur um meine letzten Aussagen noch einmal zu untermauern:

Noch ein letzter Hint von meiner Seite, da ich gerade eine Debian-Installation von Buster auf Bullseye angehoben habe und von dieser Installation aus die Gegenprobe gemacht habe:

Code: Alles auswählen

# cat /etc/debian_version
11.2

Code: Alles auswählen

# curl -v -G --data-urlencode "value=dom.GetObject(ID_SYSTEM_VARIABLES).Get('TTS Lastalexa').State('Test')" "http://10.1.17.100:8181/hm.exe"  
[...]
> GET /hm.exe?value=dom.GetObject%28ID_SYSTEM_VARIABLES%29.Get%28%27TTS%20Lastalexa%27%29.State%28%27Test%27%29 HTTP/1.1
[...]
> User-Agent: curl/7.74.0
[...]

Es ist nicht verwunderlich das mit der curl 7.74.0 Version du siehst das er dort ein "%20" statt eines "+" unterbringt. Denn compiliere ich mir diese Version manuell dann sehe ich das auch unter Ubuntu 20.04. In der Tat habe ich nun mal selbst weiter recherchiert und herausgefunden das die Änderung in "curl" mit der version 7.77.0 einzug gehalten hat. Hier ist die entsprechende Änderung dazu:

https://github.com/curl/curl/commit/0d7 ... 35704b58ac

Ist also in der Tat wie von mir schon benannt ein Fix in curl gewesen um einen Known Bug zu in der Nutzung von "--data-urlencode" zu eliminieren. Kann man da sehr gut sehen. Sobald also eine neuere Debian-Version oder ein anderes Betriebssystem auf curl Versionen >= 7.77.0 updaten werden wirst du auch dort das "Problem" bzw. besser gesagt: Das geänderte Verhalten sehen.

Ich bleibe also dabei: Das Problem müsste in ReGaHss repariert werden indem man den Webserver dort an die Gegebenheiten von RFC1866 besser anpasst, denn curl wird vllt. nicht der einzige HTTP Client sein der ein "+" statt eines "%20" zum kodieren eines Leerzeichens in URL Parametern verwendet.

[blackhole]

Mir ist es eigentlich völlig egal, wo du den Fehler angesiedelt siehst. Dein cURL passt nicht zu ReGa/WebUI in RaspberryMatic. Somit arbeitet ausschließlich RaspberryMatic an dieser Stelle fehlerhaft.

Ich habe verstanden, dass RaspberryMatic -im Gegensatz zu anderen aktuellen Stable-Distributionen- den Fehler mitschleppen und an anderer Stelle umgehen wird. Letztendlich umgehe ich diesen RM-Fehler für RM-User zurzeit auch in Alexa.sh.

Das reicht mir an Information, die ich für die kommende Version von Alexa.sh benötige.

[jmaus]

TDu weisst genauso gut wie ich das es "curl" selber ist welches dieses URL encoding macht und nicht "RaspberryMatic".

Ja, aber du hast cURL in RaspberryMatic nur halbherzig implementiert und damit steckt der Fehler in RaspberryMatic.

Tut mir leid wenn ich es so hart sagen muss: Aber diese Aussage disqualifiziert dich leider technisch ein weiteres mal. Denn die Termina die du darin verwendest und die Schlussfolgerungen die du voreilig damit ziehst sind einfach falsch. Ich "implementiere" bzw. man "implementiert" hier gar nichts in einem Betriebssystem. Die richtige Aussage wäre: RaspberryMatic verwendet eine neuere/aktuellere buildroot version als Grundlage des Betriebssystems und neuere Buildroot Versionen setzen eben curl versionsn >= 7.77.0 ein. Und damit kommen neben einiger Bugfixes eben in diesem speziellen Fall auch eine Änderung beim URL parameter encoding daher (eben NUR wenn man die "--data-urlencode" option verwendet). Das wiederum deckt nun eben eine Limitation bzw. eine gewisse Violation der RFC1866 von älteren ReGaHss Versionen auf die dort repariert werden muss.

Insofern bin ich dir zumindest unter dem Strich dankbar das du darauf gekommen bist, denn das mündete jetzt in dem folgenden Bug/Issue-Ticket auf GitHub bzgl. ReGaHss das ich sicherlich dann in Zukunft bearbeiten werde. Siehe:

https://github.com/jens-maus/RaspberryMatic/issues/1762

Es bleibt aber dabei: Das Problem tritt nur bei der Nutzung von curl zu Tage wenn man die "--data-urlencode" Option mit curl Versionsn >= 7.77.0 verwendet. Und da dein "Alexa.sh" Skript momentan der einzigste ist der diese Option wohl einsetzt halte ich das für ein Issue mit niedriger Priorität, da die Verbreitung dieses Skriptes ohnehin gering ist (auch weil du deine "Entwicklungen" ja nicht frei verfügbar irgendwo zur verfügung stellst, sondern nur auf Anfragen+Bitten diese herausgibst).

[blackhole]

Ich habe es eben in meinem vorherigen Beitrag zu spät reineditiert, daher an dieser Stelle noch einmal:

Mir ist es eigentlich völlig egal, wo du den Fehler angesiedelt siehst. Dein cURL passt nicht zu ReGa/Webserver in RaspberryMatic. Somit arbeitet ausschließlich RaspberryMatic an dieser Stelle fehlerhaft.

Ich habe verstanden, dass RaspberryMatic -im Gegensatz zu anderen aktuellen Stable-Distributionen- den Fehler mitschleppen und an anderer Stelle umgehen wird. Letztendlich umgehe ich diesen RM-Fehler für RM-User zurzeit auch in Alexa.sh.

Das reicht mir an Information, die ich für die kommende Version von Alexa.sh benötige.

[jmaus]

Nur kurze Nachinfo: Mit der ReGaHss Version R1.00.0388.0230 oder neuer wird dieses Problem behoben sein und sich ReGaHss RFC1866 konform verhalten.