Hallo Rudi,
ich würde gerne FHEM "missbrauchen", um über dessen Webserver, am liebsten über einen virtuellen Host auf Port 80, die wpad.dat ausliefern zu lassen. Damit eine solche Auslieferung überhaupt ordentlich funktionert, müssste dafür aber m.W. in den HttpUtils zumindest noch der MIME-Typ "application/x-ns-proxy-autoconfig" ergänzt werden.
Siehe https://de.wikipedia.org/wiki/Web_Proxy_Autodiscovery_Protocol .
Wäre es dir möglich, das einzubauen?
Was für einen Aufwand es bedeuten würde, virtuelle Hosts abzubilden, kann ich in keiner Weise überblicken.
Ich bin absolute gegen solch einen Missbrauch. FHEM ist nicht dafür entwickelt worden. Es wäre etwas anderes wenn man keine Klimmzüge dafür machen müsste.
Was spricht denn dagegen einfach ein Apache oder ein NGINX zum ausliefern zu verwenden?
Zitat von: CoolTux am 11 Februar 2025, 08:17:40Ich bin absolute gegen solch einen Missbrauch. FHEM ist nicht dafür entwickelt worden.
*unterschreib*
Noch dazu, wo FHEM gar keinen eigenen "Webserver" hat. Das was FHEMWEB für eine Darstellung im Browser bereitstellt, ist von einem Webserver im eigentlichen Sinn weit entfernt und optional. Deshalb kann man FHEM ja auch völlig ohne FHEMWEB betreiben.
Zitat von: CoolTux am 11 Februar 2025, 08:17:40Ich bin absolute gegen solch einen Missbrauch. FHEM ist nicht dafür entwickelt worden. Es wäre etwas anderes wenn man keine Klimmzüge dafür machen müsste.
Das kann ich eben nicht einschätzen, ob wirklich "Klimmzüge" erforderlich sind.
ZitatWas spricht denn dagegen einfach ein Apache oder ein NGINX zum ausliefern zu verwenden?
Dass ich nirgends einen Webserver lokal laufen habe und auch grds. keinen benötige. Ich würde also lediglich für die Auslieferung dieser einen Datei einen Webserver aufsetzen müssen. Dabei ist mir bewusst, dass ich dies auch in einem lxc bzw. in einer VM machen kann, in der sowieso schon etwas anderes läuft, aber es ist halt ein zusätzlicher Dienst, der konfiguriert werden muss und gepflegt sein will.
Zitat von: Ralli am 11 Februar 2025, 10:48:06Ich würde also lediglich für die Auslieferung dieser einen Datei einen Webserver aufsetzen müssen.
Hast Du eigentlich schon jemals einen Blick in die Dokumentation zu FHEM geworfen?
Wenn es nur darum geht, eine Datei auszuliefern, kannst Du das jetzt schon mit einem device vom Typ HTTPSRV umsetzen.
Das ist sogar mit Beispiel in der commandref beschrieben.
https://commandref.fhem.de/#HTTPSRV
Liebes Betateilchen,
ja, das habe ich. Und ja, das mache ich bereits mit MP3-Dateien für meine Sonos. Aber der Punkt ist eben genau dieser:
ZitatMIME-Typ "application/x-ns-proxy-autoconfig"
Siehe https://wiki.fhem.de/wiki/HTTPSRV#Fallstricke
Dann geht es doch aber tatsächlich gar nicht darum, einen Webserver zu "missbrauchen" oder virtuelle Hosts zu erzeugen, sondern letztlich nur darum, eine Liste mit Dateiendungen zu erweitern?
Hast Du mal getestet, ob mit einer bei Dir lokal geänderten HttpUtils.pm Dein Vorhaben so funktioniert, wie Du es Dir vorstellst? Wenn ja, schlage doch die Erweiterung der Tabelle einfach ganz regulär als patch vor.
Ich habe %ext2MIMEType in HttpUtils.pm global zur Verfuegung gestellt (my => use vars), damit sollte man mit Folgendes sich behelfen koennen:
define addExt notify global:INITIALIZED { $ext2MIMEType{dat} = "application/x-ns-proxy-autoconfig";; undef }
Vielen lieben Dank dafür.
Ich teste und berichte - ein einfacher Browser-Aufruf zeigt schon mal, dass die Auslieferung der wpad.dat so nun "als Download" funktioniert statt als Anzeige im Browserfenster.
Edit:
Es klappt! Das folgende Log zeigt, dass zwei ausschließlich per DHCP-Option 252 auf FHEM als Lieferant für wpad.dat konfigurierte Clients bei FHEM brav die Datei abholen.
2025.02.12 11:29:53.780 4: Connection accepted from WEB_10.0.0.69_50017
2025.02.12 11:29:53.782 4: WEB_10.0.0.69_50017 GET /fhem/wpad/wpad.dat; BUFLEN:0
2025.02.12 11:29:53.782 4: WEB: /fhem/wpad/wpad.dat / RL:58 / application/x-ns-proxy-autoconfig; charset=utf-8 / / Cache-Control: no-cache, no-store, must-revalidate
2025.02.12 11:29:53.794 4: Connection closed for WEB_10.0.0.69_50017: EOF
[...]
2025.02.12 11:34:33.899 4: Connection accepted from WEB_10.0.0.175_51647
2025.02.12 11:34:33.899 4: WEB_10.0.0.175_51647 GET /fhem/wpad/wpad.dat; BUFLEN:0
2025.02.12 11:34:33.899 4: WEB: /fhem/wpad/wpad.dat / RL:58 / application/x-ns-proxy-autoconfig; charset=utf-8 / / Cache-Control: no-cache, no-store, must-revalidate
2025.02.12 11:34:33.914 4: Connection closed for WEB_10.0.0.175_51647: EOF
Mal aus Neugierde: Wieso setzt du einen Proxy ein, bzw. was für Geräte sind das, die du über den Proxy laufen lässt?
Mir ist irgendwie noch nie ein richtiger usecase dafür eingefallen, deshalb bin ich neugierig:D
Wenn du kein Directrouting möchtest sondern das Kommunikationsverhalten von Clients ins Internet aus Gründen von Datenschutz und IT-Sicherheit etwas eingrenzen oder kanalisieren aber nicht komplett abschalten willst, ist das das Mittel der Wahl. Und mit einer wpad.dat bist du viel flexibler in der Defintion von Regeln, wofür welcher Proxy wie zu nutzen ist.
Aber auch wenn du überhaupt keinen Proxy nutzt, schauen die Windows-Clients in der Standardeinstellung trotzdem alle Nase lang nach, ob es irgendwo eine wpad.dat zu finden gibt. Also entweder automatische Proxy-Konfiguration auf jedem Client deaktivieren oder von zentraler Stelle aus verwalten.