From 5274df8909575778015229e70d3d629edadab2da Mon Sep 17 00:00:00 2001 From: Tobi G Date: Mon, 7 Sep 2026 13:15:37 +0200 Subject: [PATCH] Korrektur: Asset-Caching ist eingeschaltet und bleibt es Der eben ergaenzte Abschnitt empfahl "aus" und behauptete, das sei entschieden. Beides war falsch: der Schalter ist eingeschaltet, und es laeuft. Die Empfehlung beantwortete die Frage "soll er an sein" - gefragt war "soll ich ihn umlegen", und die ist anders, wenn der laufende Zustand traegt. Die Messung bleibt gueltig und ist der Grund, ihn NICHT auszuschalten: /local/ liefert HA schon mit 31 Tagen Cache-Control, der Rest der Freigabeliste ist dynamisch. Auf der Habenseite steht also nichts, und ein laufender Proxy wird nicht ohne Gewinn umkonfiguriert. Die Regex-Konkurrenz zwischen einem Asset-Block und dem handgesetzten /local/bilder/-Block ist damit empirisch widerlegt - sie steht als Merkposten fuer spaetere Aenderungen an der Freigabeliste weiter drin, zusammen mit den zwei Symptomen, die diese Einschaetzung kippen wuerden. --- homeassistant/REVERSE_PROXY.md | 54 +++++++++++++++++++--------------- 1 file changed, 30 insertions(+), 24 deletions(-) diff --git a/homeassistant/REVERSE_PROXY.md b/homeassistant/REVERSE_PROXY.md index bdb8d35..0eebdea 100644 --- a/homeassistant/REVERSE_PROXY.md +++ b/homeassistant/REVERSE_PROXY.md @@ -174,25 +174,27 @@ location / { > ganze Aufbau eigentlich herstellen soll. Test: `https:///` (ohne Pfad) muss `404` liefern, > niemals die HA-Anmeldemaske. -## „Cache Assets" im Nginx Proxy Manager: **aus** +## „Cache Assets" im Nginx Proxy Manager: **an, und das bleibt so** -Entschieden am 06.09.2026. Der Schalter bringt hier nichts und kann etwas -kaputtmachen. +Stand 06.09.2026: der Schalter **ist eingeschaltet**, und es läuft. Damit ist die +Frage beantwortet - nicht durch Abwägen, sondern durch den Betrieb. -**Er bringt nichts.** Gemessen an der laufenden Instanz, nicht angenommen: +**Warum nicht ausschalten?** Weil auf der Habenseite nichts steht. Gemessen an +der laufenden Instanz, nicht angenommen: | Pfad | was Home Assistant selbst schickt | |---|---| | `/local/bilder/…webp` | `Cache-Control: public, max-age=2678400` (31 Tage) | | `/audi_dashboard_static/app/bundle.zip` | kein `Cache-Control`, nur `ETag` und `Last-Modified` | -Die Fotos sind die einzige nennenswerte statische Last durch den Proxy - und sie -werden vom Browser ohnehin schon einen Monat lang behalten. Alles andere auf der -Freigabeliste ist `/api/…` und die WebSocket-Verbindung; von Asset-Caching wird -das gar nicht berührt. +Die Fotos sind die einzige nennenswerte statische Last durch den Proxy, und der +Browser behält sie ohnehin schon einen Monat. Der Rest der Freigabeliste ist +`/api/…` und die WebSocket-Verbindung - von Asset-Caching gar nicht berührt. Ein +laufender Proxy wird nicht für einen Schalter umkonfiguriert, der weder etwas +einbringt noch nachweislich schadet. -**Er kann die Freigabeliste stören.** Die Liste oben besteht aus handgesetzten -`location`-Blöcken, darunter +**Warum es hätte schiefgehen können - und offenbar nicht tut.** Die Freigabeliste +oben besteht aus handgesetzten `location`-Blöcken, darunter ```nginx location ~ ^/local/bilder/[a-z0-9_-]+\.(webp|png|jpg|svg)$ { … } @@ -200,22 +202,26 @@ location ~ ^/local/bilder/[a-z0-9_-]+\.(webp|png|jpg|svg)$ { … } Ein Asset-Caching-Block ist seinerseits ein Regex-Block auf genau diese Endungen. Bei nginx gewinnt unter Regex-Blöcken **der erste passende in der -Reihenfolge der Konfiguration** - steht der erzeugte vor dem eigenen, greift er -statt seiner. Was dann passiert, hängt an seinem Inhalt; ohne `proxy_pass` fiele -er auf das Dateisystem zurück, und die Fahrzeugfotos kämen als 404. *Wie NPM -diesen Block genau erzeugt, ist hier nicht nachgesehen worden - die -Konkurrenzsituation folgt aber schon aus der nginx-Regel und genügt als Grund.* +Reihenfolge der Konfiguration**; stünde der erzeugte vor dem eigenen, griffe er +statt seiner, und ohne eigenes `proxy_pass` fielen die Fahrzeugfotos auf das +Dateisystem zurück - also 404. Dass die Fotos ankommen, heißt: dieser Fall tritt +hier nicht ein. -**Gefährlich wäre es nicht.** Alles, was ein Zwischenspeicher festhalten könnte, -trägt einen Cache-Brecher: die Fotos `?v=`, das OTA-Bündel -`?v=` und obendrein eine SHA-256-Prüfung auf dem Gerät. Der Kommentar -in `companion-app/src/daten/ota.ts` nennt genau diesen Fall - „der des Geräts -wie einer im Weg". Ein Schalter, der nichts einbringt und eine handgetunte -Location-Liste durcheinanderbringen kann, ist trotzdem ein schlechtes Geschäft. +**Was das für spätere Änderungen bedeutet.** Die Konkurrenz besteht weiter. Wer +der Freigabeliste einen neuen Pfad mit einer Bild-, `.js`- oder `.css`-Endung +hinzufügt, prüft danach, ob er wirklich durchkommt - eine Verschattung zeigt +sich sofort als 404 und nicht als schleichender Fehler. -**Falls er doch einmal an soll:** danach die Prüfungen aus „Nach der Einrichtung -prüfen" wiederholen, insbesondere den Abruf eines Fahrzeugfotos - dort zeigt -sich eine Verschattung sofort. +**Ein Sicherheitsproblem wäre es ohnehin nicht.** Alles, was ein Zwischenspeicher +festhalten könnte, trägt einen Cache-Brecher: die Fotos `?v=`, +das OTA-Bündel `?v=` und obendrein eine SHA-256-Prüfung auf dem Gerät. +Der Kommentar in `companion-app/src/daten/ota.ts` nennt genau diesen Fall - „der +des Geräts wie einer im Weg". + +**Wodurch diese Einschätzung fiele:** ein Fahrzeugfoto, das trotz neuem +Zeitstempel das alte bleibt, oder ein OTA-Update, das mit einem Prüfsummenfehler +abbricht. Beides wäre ein Grund, hier zuerst nachzusehen - beides ist bisher +nicht aufgetreten. ## Home Assistant muss dem Proxy vertrauen (nötig, nicht optional)