Ich habe folgendes FHEM-Device definiert:
defmod myFTUISRV FTUISRV ftuisrv/ ./www/tablet/ FTUISRV
Ein wenig "rumgespielt" und alles funktioniert wie erwartet - ftuisrv-Zugriffe nehmen den richtigen Weg.
Anschließend habe ich noch folgendes FHEM-Device definiert:
defmod myFTUI HTTPSRV ftui/ ./www/tablet/ FTUI
Wieder ein wenig "rumgespielt" und festgestellt, dass zwar ftui-Zugriffe den richtigen Weg nehmen, aber ftuisrv-Zugriffe wohl nicht mehr.
Um der Sache auf den Grund gehen zu können, habe ich an geeigneter Stelle zusätzliche Logeinträge integriert und das obige Vorgehen nochmals durchgeführt.
Sich ergebende Logeinträge (nur myFTUISRV ist definiert und der gewünschte Weg wird gefunden ...)
2019.11.18 10:48:32.574 3: === WEB.arg: /ftuisrv/index_ftuisrv.html
2019.11.18 10:48:32.575 3: WEB.url: /FileLog_logWrapper
2019.11.18 10:48:32.575 3: WEB.url: /FileLog_toSVG
2019.11.18 10:48:32.575 3: WEB.url: /ftuisrv
2019.11.18 10:48:32.575 3: WEB.FUNC: FTUISRV_CGI
Sich ergebende Logeinträge (myFTUISRV und myFTUI sind definiert und der gewünschte Weg wird nicht mehr gefunden ...)
2019.11.18 10:56:28.295 3: === WEB.arg: /ftuisrv/index_ftuisrv.html
2019.11.18 10:56:28.296 3: WEB.url: /FileLog_logWrapper
2019.11.18 10:56:28.296 3: WEB.url: /FileLog_toSVG
2019.11.18 10:56:28.296 3: WEB.url: /ftui
2019.11.18 10:56:28.296 3: WEB.FUNC: HTTPSRV_CGI
Ist dieses Verhalten gewollt und unumgänglich oder kann man den regulären Ausdruck "schärfer" gestalten?
Bei $data{FWEXT}{regexp} bestimmt regexp (erweitert zu ^regexp) die URL, was umgeleitet wird.
Damit matcht ^/ftui auch /ftuisrv.
Wenn das beschriebene Verhalten ein Problem ist, dann muss HTTPSRV und FTUISRV (was offensichtlich durch HTTPSRV inspiriert wurde) die Logik zum Berechnen von regexp anpassen.
Grundsätzlich besteht dieses Problem nicht nur zwischen HTTPSRV und FTUISRV, sondern betrifft ebenso die restlichen Module, die FWEXT nutzen - aktuell sind es wohl 26 Stück.
$data{FWEXT}{key} wird bei einer Stichprobe in ein paar Modulen scheinbar nie als regexp verwendet; was aber wahrscheinlich auch nur in der {FUNC} zu Problemen führen würde, da dort das betroffene Gerät "rückwärts" zu ermitteln ist.
Eine minimale Änderung in 01_FHEMWEB.pm würde aus meiner Sicht das Problem zentral lösen. Ich kann jedoch nicht sagen, ob die bisher verwendete Sortierung hier tatsächlich wichtig ist. Wenn wichtig, dann ist die Lösung geplatzt; wenn unwichtig, dann würde die umgekehrte Sortierung stets den längsten, passenden Ausdruck zuerst durchlaufen.
Änderung der Zeile 935 in 01_FHEMWEB.pm
--- foreach my $k (sort keys %{$data{FWEXT}}) {
+++ foreach my $k (reverse sort keys %{$data{FWEXT}}) {
Bei umgekehrter Sortierung ergibt sich folgende, korrekte Wegfindung:
2019.11.19 08:04:13.863 3: === WEB.arg: /ftui
2019.11.19 08:04:13.863 3: WEB.url: /ftuisrv
2019.11.19 08:04:13.864 3: WEB.url: /ftui
2019.11.19 08:04:13.864 3: WEB.FUNC: HTTPSRV_CGI
2019.11.19 08:04:27.999 3: === WEB.arg: /ftuisrv
2019.11.19 08:04:27.999 3: WEB.url: /ftuisrv
2019.11.19 08:04:27.999 3: WEB.FUNC: FTUISRV_CGI
Habe dein Vorschlag uebernommen.
Vielen Dank - funktioniert einwandfrei.