Autor Thema: FHEMWEB: gewünschter Server-Header  (Gelesen 1253 mal)

Offline curt

  • Sr. Member
  • ****
  • Beiträge: 983
FHEMWEB: gewünschter Server-Header
« am: 26 Dezember 2018, 23:12:07 »
Frohe und gesegnete Weihnachten!

@rudolfkoenig
Gewünscht wird eine zusätzlicher Server-Header-Zeile (wirklich Server-Header, nicht html-Header). Der zusätzliche Serverheader-Eintrag solle sein:

Cache-Control: max-age=0,no-cache,no-store,post-check=0,pre-check=0

Dieser Server-Headereintrag soll je FHEMWEB-Device binär schaltbar sein: An/Aus.

Motivation:
FTUI spielt mit dynamischen HTML-Seiten. Je nach Browser geht das gern ordentlich schief, selbst bei identischem Browser unter verschiedenen Betriebssystemen. Das Verhalten ist nicht vorhersagbar. Die Lösung ist: Browser-Cache ausschalten! Dafür gibt es mehrere Möglichkeiten: Im HTML-File ein Manifest. Im Browser Cache abschalten. Und eben die oben genannte Version. - Anläßlich der Feiertage hatte ich Gelegenheit mit einem Familienmitglied zu sprechen, der sich intensiv mit dem Thema auseinandersetzt - er meint, dass die *aktuell* sicherste Version der Server-Header sei.

Siehe auch:
https://stackoverflow.com/questions/18514749/no-caching-in-html5

@setstate
RPI 3 Busware-CC1101 Jeelink HomeMatic Z-Wave (USB) + viele RPI Zero W

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 20780
Antw:FHEMWEB: gewünschter Server-Header
« Antwort #1 am: 27 Dezember 2018, 10:17:22 »
Zitat
Gewünscht wird eine zusätzlicher Server-Header-Zeile (wirklich Server-Header, nicht html-Header). Der zusätzliche Serverheader-Eintrag solle sein:
Sowas mache ich natuerlich nicht generisch, Bilder, CSS, usw. sollten zwischenspeicherbar sein. Weiterhin traue ich dem verlinkten Beitrag nicht: ich sehe keine Erklaerung fuer die einzelnen Werte, und fuer post-check=0,pre-check=0 habe ich auch sonstwo keine Doku gefunden.

Ich habe jetzt "Cache-Control: no-cache, no-store, must-revalidate" zu der Haupt-FHEMWEB-Antwortseite hinzugefuegt, wie hier
https://developer.mozilla.org/de/docs/Web/HTTP/Headers/Cache-Control es empfohlen wird. Wenn es nicht passt bitte
- beschreiben, fuer welche Seiten der Header gewuenscht ist
- was die Parameter bewirken.

Offline curt

  • Sr. Member
  • ****
  • Beiträge: 983
Antw:FHEMWEB: gewünschter Server-Header
« Antwort #2 am: 27 Dezember 2018, 22:57:01 »
und fuer post-check=0,pre-check=0 habe ich auch sonstwo keine Doku gefunden.

Diese beiden sind IE-spezifische Sonderlocken zur serverseitig vorgegebenen Cache-Steuerung.

Ich habe jetzt "Cache-Control: no-cache, no-store, must-revalidate" zu der Haupt-FHEMWEB-Antwortseite hinzugefuegt, wie hier
https://developer.mozilla.org/de/docs/Web/HTTP/Headers/Cache-Control es empfohlen wird. Wenn es nicht passt bitte
- beschreiben, fuer welche Seiten der Header gewuenscht ist
- was die Parameter bewirken.

Es geht (mir) ausschließlich um FTUI. Die FTUI-Seiten werden massiv aus dynamic-html zusammengestellt. Das betrifft selbst einzelne veränderliche <div>-Elemente. Caching ist da ganz fatal.

FTUI kommt in der vorn @setstate vorgeschlagenen Version mit einer einzigen index.html-Seite. DIese und die Unterseiten bestehen aus template-html-Seiten.

Es betrifft diesen Pfad, der bei mir so aussieht:

define TABLETUI HTTPSRV ftui/ ./www/tablet/ Tablet-UI
attr TABLETUI room 99_System
RPI 3 Busware-CC1101 Jeelink HomeMatic Z-Wave (USB) + viele RPI Zero W

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 20780
Antw:FHEMWEB: gewünschter Server-Header
« Antwort #3 am: 28 Dezember 2018, 10:22:44 »
Zitat
Diese beiden sind IE-spezifische Sonderlocken zur serverseitig vorgegebenen Cache-Steuerung.
Tut mir leid, IE unterstuetze ich nicht. Irgendwo muss man die Grenze ziehen :)

Zitat
Es geht (mir) ausschließlich um FTUI. Die FTUI-Seiten werden massiv aus dynamic-html zusammengestellt. Das betrifft selbst einzelne veränderliche <div>-Elemente. Caching ist da ganz fatal.
Das mag alles sein, hilft _mir_ aber nicht. Ich weiss weder, ob die Modifikation geholfen hat, noch wo ich was aendern soll, wenn nicht.

Offline curt

  • Sr. Member
  • ****
  • Beiträge: 983
Antw:FHEMWEB: gewünschter Server-Header
« Antwort #4 am: 28 Dezember 2018, 17:00:37 »
Tut mir leid, IE unterstuetze ich nicht. Irgendwo muss man die Grenze ziehen :)

Klingt nach Fefe ... Kein Problem, ich lebe damit. Ich erwähnte es der Vollständigkeit halber.

Das mag alles sein, hilft _mir_ aber nicht. Ich weiss weder, ob die Modifikation geholfen hat, noch wo ich was aendern soll, wenn nicht.

Vielleicht reden wir aneinander vorbei. Es geht um serverseitige Header. Ich wünsche mir da die zusätzliche Zeile Cache-Control: max-age=0,no-cache,no-store zumindest bei type text/html.

Aktualität:
01_FHEMWEB.pm              18065 2018-12-27 10:12:16Z rudolfkoenig

Abrufzeit ca. 1630 Uhr:

Der Server antwortet auf https://192.168.128.13:8083/fhem/www/tablet/index.html
Content-Encoding gzip
Expires Wed Dec 26 21:29:00 2018 GMT
X-FHEM-csrfToken csrf_127748583133680
ETag "1545858805"
Content-Type text/html; charset=UTF-8
X-NoScript-ReqData {}

Ich sehe da kein Cache-Control. Expires liegt zwei Tage in der Vergangenheit, das geht schon mal in die richtige Richtung. (Expires wird offenbar an Hand der Erstellungszeit der Datei index.html gebildet.)

Der Server antwortet auf (Template innerhalb von index.html) https://192.168.128.13:8083/fhem/www/tablet/uebersicht.html
Content-Encoding gzip
Expires Fri Dec 28 15:52:53 2018 GMT
X-FHEM-csrfToken csrf_150032447053838
ETag "1545852818"
Transfer-Encoding chunked
Content-Type text/html; charset=UTF-8

Auch hier ist immerhin Expires in der Vergangenheit. Wie das gebildet wird, soll mir egal sein. - Das reicht aber nicht. Browser (wie auch Proxys) sind recht frei darin, was sie cachen. Serverseitig gesendetes Cache-Control wird aber ernst genommen.

Rudolf, vielleicht habe ich Deinen letzten Beitrag auch falsch verstanden - was habe ich zu liefern?
RPI 3 Busware-CC1101 Jeelink HomeMatic Z-Wave (USB) + viele RPI Zero W

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 20780
Antw:FHEMWEB: gewünschter Server-Header
« Antwort #5 am: 28 Dezember 2018, 18:28:54 »
Zitat
Rudolf, vielleicht habe ich Deinen letzten Beitrag auch falsch verstanden - was habe ich zu liefern?
Das, was in deinem letzten Beitrag vorhanden ist.

Ich habe die Cache-Zeile in die "normale" FHEMWEB Antwortseite eingebaut, also Room-Overview, Detailansicht, etc.
Externe Dateien (wie index.html) werden weiterhin ohne Cache-Control geliefert, weil da das Speichern per Etag (== Zeitstempel) geregelt werden sollte.
Ich werde fuer diese kein "no-cache,no-store" einbauen, weil dadurch immer alle .css/.js/.png/etc Dateien neu geholt werden, was den Seitenaufbau deutlich ausbremst.

Was ich noch nicht verstehe: wieso darf index.html nicht zwischengespeichert werden?
Wenn das nur beim Entwickeln stoert: ist ein Reload im Browser per "Shift-Ctrl-R" (oder Vergleichbares) keine Option?

Offline curt

  • Sr. Member
  • ****
  • Beiträge: 983
Antw:FHEMWEB: gewünschter Server-Header
« Antwort #6 am: 28 Dezember 2018, 18:55:25 »
Ich habe die Cache-Zeile in die "normale" FHEMWEB Antwortseite eingebaut, also Room-Overview, Detailansicht, etc.

Da schadet es auch nicht.

Ich will das grundsätzliche Problem nochmals schildern:
FTUI (und FUIP) setzen massiv auf dynamic-html, html5. Bei scheinbar nur einer Seite (index.html) werden ganz massiv dynamische Inhalte ausgetauscht: html-Seiten, Grafiken, alles mögliche wird nachgeladen, ausgetauscht, aktualisiert.

Auf der Protokollebene (Port 80 bzw. 443) sind das alles eigene Dateien.

Nun kommt der Browser (schlimmer noch: im ungünstigsten Fall Proxys) ins Spiel: Die haben einen eigenen Plan, wie man Seiten cacht. Und jeder Browser macht das anders. Insbesondere fiel mir Vivaldi auf: Der schafft es, auf verschiedenen Betriebssystemen völlig anders anzuzeigen.

Externe Dateien (wie index.html) werden weiterhin ohne Cache-Control geliefert, weil da das Speichern per Etag (== Zeitstempel) geregelt werden sollte.

Sollte. Funktioniert aber nicht zwingend. - Die derzeit sicherste Methode ist der Wechsel der OSI-Schicht: Der Webserver sagt an, wie es zu halten sei.

Ich werde fuer diese kein "no-cache,no-store" einbauen,

Ich möchte es trotzdem diskutieren.

weil dadurch immer alle .css/.js/.png/etc Dateien neu geholt werden, was den Seitenaufbau deutlich ausbremst.

Widerspruch.
Ich habe jetzt auf mehreren Browsern mit der Brechstange den Cache clientseitig ausgeschaltet. Selbst ein einem RPi mit Display und Vivaldi wird da nichts ausgebremst.

Was ich noch nicht verstehe: wieso darf index.html nicht zwischengespeichert werden?

Weil für dynamische Seiten genau garnichts gecacht werden soll.

Ja, aktuell haben wir noch keine dynamisch sich ändernden GIF/JPEG oder js. Aber das dürfte nur eine Frage der Zeit sein.

Ich merke aber, dass ich mich offensichtlich nicht gut ausdrücken konnte:
Du hast mit dem Holzhammer diese Headerzeile reingedroschen und weigerst Dich nun, mit dem Holzhammer nochmals draufzuhauen.

Ich hingegen will etwas völlig anderes:

define WEB FHEMWEB 8083 global
attr WEB caching 0

Gern mit default 1.
So etwa stelle ich mir das vor. (Und bei caching 0) wird Cache-Control: max-age=0,no-cache,no-store für jede auszuliefernde Datei rausgerotzt.
RPI 3 Busware-CC1101 Jeelink HomeMatic Z-Wave (USB) + viele RPI Zero W

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 20780
Antw:FHEMWEB: gewünschter Server-Header
« Antwort #7 am: 28 Dezember 2018, 19:15:30 »
Zitat
So etwa stelle ich mir das vor. (Und bei caching 0) wird Cache-Control: max-age=0,no-cache,no-store für jede auszuliefernde Datei rausgerotzt.
Erstens ist das nicht so trivial, weil dieser Code in FHEMWEB an mehreren Stellen existiert.
Zweitens will ich erst was einbauen, wenn ich den Grund verstehe: wieso aendert sich index.html?

Zitat
Selbst ein einem RPi mit Display und Vivaldi wird da nichts ausgebremst.
Versuch das mal mit 1s Latenz und 100kb/sec Durchsatz zwischen Browser und Server.

Offline curt

  • Sr. Member
  • ****
  • Beiträge: 983
Antw:FHEMWEB: gewünschter Server-Header
« Antwort #8 am: 28 Dezember 2018, 19:32:57 »
Erstens ist das nicht so trivial, weil dieser Code in FHEMWEB an mehreren Stellen existiert.

Ich habe mich artig auf meine Fingerchen gesetzt.

Zweitens will ich erst was einbauen, wenn ich den Grund verstehe: wieso aendert sich index.html?

Um die geht es nicht primär. In meinem von index.html auf Klick inkludiertem Template dwd-wetter.html sind Konstrukte, wie wiederum ein Template laden, sagen wir "t_DWD_temp_max.html". Darin sind DIV-Konstrukte - die aktualisieren (unter den schon genannten Bedingungen) nicht. Das ist dort alles plain-text, daher ist klar, dass man bei text/html ansetzen muss.

Versuch das mal mit 1s Latenz und 100kb/sec Durchsatz zwischen Browser und Server.

Wieso sollte ich das denn versuchen? Sei bitte nicht böse: Mit der Begründung kann man auch sagen, dass alles mit nativem V.24 funktionieren muss, selbstredend über V.24-Kabel, 9.600.

Rudolf,
es wird doch überhaupt nicht erwartet, dass Du wegen einer sicher noch selten auftretenden Problematik springst wie ein Federmännchen. Das muss doch nicht morgen um 1100 fertig sein.

Ich habe ein real auftretendes Problem geschildert. Mehr kann ich nicht tun, wer bin ich denn? Ich bitte, da wirklich nichts falsch zu verstehen: Du bist der Chef mit dem Blick auf das große Ganze, auf das komplette Getriebe. Das ist so, da gibt es nichts zu erörtern. - Ich habe lediglich gesagt, dass an einem Zahnrädchen ganz unten Späne fallen.
RPI 3 Busware-CC1101 Jeelink HomeMatic Z-Wave (USB) + viele RPI Zero W

Offline herrmannj

  • Global Moderator
  • Hero Member
  • ****
  • Beiträge: 5054
Antw:FHEMWEB: gewünschter Server-Header
« Antwort #9 am: 28 Dezember 2018, 20:11:44 »
Dynamische Inhalte lassen sich super clientseitig "no-cachen" indem man an die Ressourcen einen Parameter mit zufälligem Inhalt anhängt. Also Fragezeichen und random zahl btw Kaufmannsund plus random wenn schon was dranhängt
smartVisu mit fronthem, einiges an HM, RFXTRX, Oregon, CUL, Homeeasy, ganz viele LED + Diverse

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 20780
Antw:FHEMWEB: gewünschter Server-Header
« Antwort #10 am: 28 Dezember 2018, 20:53:22 »
Zitat
In meinem von index.html auf Klick inkludiertem Template dwd-wetter.html sind Konstrukte, wie wiederum ein Template laden, sagen wir "t_DWD_temp_max.html". Darin sind DIV-Konstrukte - die aktualisieren (unter den schon genannten Bedingungen) nicht.
Welcher dieser Dateien wird auf dem Server geaendert?
Reden wir hier von Entwicklung?
- Wenn ja: funktioniert Shift-Ctrl-R (OSX: Shift-Cmd-R) nicht?
- Wenn nein: wer aendert diese Dateien?
Nicht falsch verstehen: ich will mich (zunaechst mal :) ) nicht querstellen, aber verstehen.

Zitat
Wieso sollte ich das denn versuchen? Sei bitte nicht böse: Mit der Begründung kann man auch sagen, dass alles mit nativem V.24 funktionieren muss, selbstredend über V.24-Kabel, 9.600.
Im Chrome Entwicklerfenster, Network-Tab, "Online" auf "Slow 3G" stellen. Ich wollte damit demonstrieren, dass in manchen Situationen (z.Bsp. Bedienung per Mobiltelefon, aus dem Ausland) Caching durchaus sinnvoll ist.

Offline curt

  • Sr. Member
  • ****
  • Beiträge: 983
Antw:FHEMWEB: gewünschter Server-Header
« Antwort #11 am: 28 Dezember 2018, 21:36:23 »
Welcher dieser Dateien wird auf dem Server geaendert?

Änderungen von Readings werden von FTUI-Widgets aufgenommen. Typischerweise passiert das in DIV-Konstrukten von html-Dateien. Die von index.html nachgeladenen Templates sind reale html-Dateien. Das ist kaskadierbar.

Reden wir hier von Entwicklung?

Negativ.
Das Fehlverhalten ist bislang niemandem aufgefallen. Respektive wurde nicht erkannt. Der Anfragende lief mangels Antwort abwinkend weg.

- Wenn ja: funktioniert Shift-Ctrl-R (OSX: Shift-Cmd-R) nicht?

Ich kenne auch die schmutzigen Tricks wie CTRL-F5. Aber mach das mal ohne Tastatur.

- Wenn nein: wer aendert diese Dateien?

FHEM.
Genau genommen sind es Readings, die sich ändern. Erstmals fiel mir das bei dem Wigdet Label auf: Das rotzt plain-text Readings raus.

Das läuft bei FTUI kaskadenartig: FTUI == index.html. Die lädt auf Tastendruck Garten_DWD.html als scheinbar neue Seite nach. Dort wiederum sind DIV-Konstrukte, die weitere html-Seiten (hier: NICHT nachladen!) in diese scheinbare Seite einbinden.

(Mir fiel das auf, weil einerseits die textliche Vorhersage [Min/Max-Temperatur für 5 Tage] wirr aktualisiert(e). Andererseits aktualisiert(e) eine Grafik wirr. - Ich ging der Sache auf den Grund.)

Nicht falsch verstehen: ich will mich (zunaechst mal :) ) nicht querstellen, aber verstehen.

Verstanden.

Nebensatz:
Ich wollte/will auf kleinen "Maschinen" schmale Browser. Die sollen vor allem nicht "nach Hause" telefonieren wollen. Zuerst war Midori am Start. Das ging gar nicht, da stimmten die Werte nicht [¹]. Nun ist Vivaldi im Rennen, das hatte ich gleichzeitig auf RPi, Debian, Ubuntu. Und fiel es mir wie Schuppen aus ... das Problem ist das Caching. Und da kann ich mich nur wiederholen: (Derzeit) stabilste Lösung ist, dass der Server ansagt, wie das zu handhaben sei: Das haben alle implementiert.

[¹] Mir war damals nicht klar/überschaubar, dass das ein Caching-Problem ist. Ich habe Midori zu früh weggeworfen. Ach, doch nicht: Der kann CSS3 nichtvollständig, Für FTUI ist das keine Empfehlung.

Falls ich schlecht/unklar formulierte: Bitte nachfragen.

@setstate
RPI 3 Busware-CC1101 Jeelink HomeMatic Z-Wave (USB) + viele RPI Zero W

Offline herrmannj

  • Global Moderator
  • Hero Member
  • ****
  • Beiträge: 5054
Antw:FHEMWEB: gewünschter Server-Header
« Antwort #12 am: 28 Dezember 2018, 22:08:22 »
nochmals, dafür existieren aus gutem Grund etablierte, clientseitige Verfahren: https://curtistimson.co.uk/post/front-end-dev/what-is-cache-busting/
smartVisu mit fronthem, einiges an HM, RFXTRX, Oregon, CUL, Homeeasy, ganz viele LED + Diverse

Offline curt

  • Sr. Member
  • ****
  • Beiträge: 983
Antw:FHEMWEB: gewünschter Server-Header
« Antwort #13 am: 28 Dezember 2018, 22:37:22 »
<seufzt>

Nochmals: Es gibt sehr guten Grund, auf das serverseitige Verfahren in faktisch einer anderen OSI-Schicht zu setzen. Ich habe das alles schon (hoffentlich verständlich) erklärt. Ich denke mir sowas doch nicht aus.

Ich weiß, wo solche Diskussionen an diesem Punkt typischerweise enden: Ich bin ja auch schon groß. Das möchte ich nicht., ich kenne solche Auseinandersetzungen bis zum Erbrechen.

Ich habe alles gesagt, was zu sagen ist.
Ich hoffe, dass ich damit einen ganz kleinen Beitrag für FHEM und FTUI leisten konnte.
RPI 3 Busware-CC1101 Jeelink HomeMatic Z-Wave (USB) + viele RPI Zero W

Offline herrmannj

  • Global Moderator
  • Hero Member
  • ****
  • Beiträge: 5054
Antw:FHEMWEB: gewünschter Server-Header
« Antwort #14 am: 28 Dezember 2018, 23:18:38 »
flauschig bleiben. :) Rudi hat doch erklärt warum er aus gutem Grund dagegen ist und die verlinkte Lösung haben schlaue Leute ausgedacht weil es eben doch gute Gründe dafür gibt.
 
Du hast ja schon festgestellt das zb Browser oder proxys durchaus eigene Interpretationen der Server Header haben. Deshalb hängt man clientseitig pro Element einen Querystring mit zufälligem Inhalt, ran. Der wird so gewählt das der Server ihn nicht beachtet aber alle Systeme "auf der Strecke" dann ein Element sehen das sich von den mglw im Cache liegenden durch den Namen (wegen der Query) unterscheidet.

Das ist etabliert und wurde genau für das von Dir beschriebene Szenario entwickelt.
« Letzte Änderung: 28 Dezember 2018, 23:25:06 von herrmannj »
smartVisu mit fronthem, einiges an HM, RFXTRX, Oregon, CUL, Homeeasy, ganz viele LED + Diverse

Offline Thorsten Pferdekaemper

  • Developer
  • Hero Member
  • ****
  • Beiträge: 5552
  • Finger weg von der fhem.cfg
Antw:FHEMWEB: gewünschter Server-Header
« Antwort #15 am: 29 Dezember 2018, 14:27:16 »
Hi,
ich klinke mich hier auch mal ein.
Ich dachte zuerst, dass ich das Problem verstehen würde, aber ich habe da etwas zu FUIP-lastig gedacht. FTUI dürfte das Problem doch gar nicht haben. Alles, was bei FTUI dynamisch ist, passiert im Client. Es gibt doch gar keine HTML/CSS/JS oder sonstige Datei, die auf dem Server geändert wird. (Oder?)
D.h. man kann (und sollte) alles, was geht, aus dem Cache holen. (Außer vielleicht während der Entwicklung, aber das ist ein anderes Thema.)
In meinem von index.html auf Klick inkludiertem Template dwd-wetter.html sind Konstrukte, wie wiederum ein Template laden, sagen wir "t_DWD_temp_max.html". Darin sind DIV-Konstrukte - die aktualisieren (unter den schon genannten Bedingungen) nicht.
Alle hier erwähnten Dateien sind meiner Meinung nach statisch, also wieso nicht aus dem Cache? Die dynamischen "DIV"-Konstrukte sollten alle auf dem Client geändert werden. Wenn das nicht klappt, dann hilft am Cache fummeln auch nichts.
Möglicherweise werden da Seiten (oder allgemein Dateien) von einem anderen Server (DWD?) geholt, die sich mit der Zeit ändern. Die werden aber nicht von FHEMWEB geliefert (oder?), sondern direkt vom (z.B.) DWD-Server. Wenn es dort Cache-Probleme gibt, dann kann man die kaum in FHEMWEB lösen.
Gruß,
   Thorsten
RasPi
Heizkessel-Steuerung per Arduino und HTTPMOD
und einen Haufen Homematic (Wired)

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 20780
Antw:FHEMWEB: gewünschter Server-Header
« Antwort #16 am: 29 Dezember 2018, 15:54:43 »
Zitat
Es gibt doch gar keine HTML/CSS/JS oder sonstige Datei, die auf dem Server geändert wird. (Oder?)
Das war auch meine Vorstellung, deswegen habe ich nachgebohrt.
Damit aber curt nicht voellig an den "Alteingesessenen" verzweifelt, habe ich seinen Wunsch per FHEMWEB Attribut ermoeglicht (auch deswegen, weil ich das selbst vermisste :) ).

Aus dem commandref:
Zitat
httpHeader
One or more HTTP header lines to be sent out with each answer. Example:
  attr WEB httpHeader X-Clacks-Overhead: GNU Terry Pratchett

Offline curt

  • Sr. Member
  • ****
  • Beiträge: 983
Antw:FHEMWEB: gewünschter Server-Header
« Antwort #17 am: 03 Januar 2019, 23:31:22 »
Ich dachte zuerst, dass ich das Problem verstehen würde, aber ich habe da etwas zu FUIP-lastig gedacht. FTUI dürfte das Problem doch gar nicht haben. Alles, was bei FTUI dynamisch ist, passiert im Client. Es gibt doch gar keine HTML/CSS/JS oder sonstige Datei, die auf dem Server geändert wird. (Oder?)

Nun stellt der Webbrowser allerdings auch Readings dar - das erledigen FTUI-Widgets. Wie sie das im einzelnen erledigen weiß ich nicht genau. Was ich genau weiß: Einige Browser (Vivaldi) halten diese Werte (typischerweise Texte, aber auch Grafiken - also html-plaintext als Referenz auf die [geänderte] Grafik im Cache. Und es interessiert sie genau gar nicht, ob sich Readings ändern. Ich habe das oben ausführlich beschrieben. (es sieht sehr lustig aus, wenn man auf nur einem Monitor vier Fenster hat - alle mit der gleichen URL, alle mit unterschiedlichen Ausgaben ...)

Dieses Verhalten habe ich mit einem Familienangehörigen diskutiert, er/sie/es programmiert im Job html-5. Von dort kam der Hinweis auf serverseitiges "Abschalten" des Browsercaches.

Selbstverständlich kann man jeden Browser selbst dazu bewegen, dass er nicht mehr cacht. Die Frage ist, was cleverer ist, was langfristig zielführend ist.

Das war auch meine Vorstellung, deswegen habe ich nachgebohrt.
Damit aber curt nicht voellig an den "Alteingesessenen" verzweifelt, habe ich seinen Wunsch per FHEMWEB Attribut ermoeglicht (auch deswegen, weil ich das selbst vermisste :) ).

Ich danke, das ist sehr freundlich.
RPI 3 Busware-CC1101 Jeelink HomeMatic Z-Wave (USB) + viele RPI Zero W

Offline JoeALLb

  • Hero Member
  • *****
  • Beiträge: 1554
Antw:FHEMWEB: gewünschter Server-Header
« Antwort #18 am: 05 Januar 2019, 01:16:39 »
FTui hat dilich sogar einen eigenen Serverclon. FTUiSRV. Wäre das nicht besser dort aufgehoben?
FHEM-Server auf IntelAtom+Debian (8.1 Watt), KNX,
RasPi-2 Sonos-FHEM per FHEM2FHEM,RasPi-3 Versuchs-RasPi für WLAN-Tests
Gateways: DuoFern Stick, CUL866 PCA301, CUL HM, HMLan, JeeLink, LaCrosse,VCO2
Synology. Ardurino UNO für 1-Wire Tests, FB7270

Offline curt

  • Sr. Member
  • ****
  • Beiträge: 983
Antw:FHEMWEB: gewünschter Server-Header
« Antwort #19 am: 05 Januar 2019, 01:35:07 »
Das kann ich nicht beurteilen, da mir FTUiSRV bis eben völlig unbekannt war. Ich finde da auch nur wenig, vermutlich dieser Thread:
https://forum.fhem.de/index.php/topic,43110.0.html
RPI 3 Busware-CC1101 Jeelink HomeMatic Z-Wave (USB) + viele RPI Zero W

Offline Thorsten Pferdekaemper

  • Developer
  • Hero Member
  • ****
  • Beiträge: 5552
  • Finger weg von der fhem.cfg
Antw:FHEMWEB: gewünschter Server-Header
« Antwort #20 am: 05 Januar 2019, 10:41:59 »
Nun stellt der Webbrowser allerdings auch Readings dar - das erledigen FTUI-Widgets. Wie sie das im einzelnen erledigen weiß ich nicht genau.
Im Prinzip erfahren die Widgets über ajax oder websocket von den Änderungen im Backend. Daraufhin werden die Seiten per JavaScript (also im Client) auf den neusten Stand gebracht.
Hast Du mal mit den meta-Angaben longpoll und longpoll_type gespielt? Vielleicht gibt es hier ein Problem.

Zitat
Was ich genau weiß: Einige Browser (Vivaldi) halten diese Werte (typischerweise Texte, aber auch Grafiken - also html-plaintext als Referenz auf die [geänderte] Grafik im Cache. Und es interessiert sie genau gar nicht, ob sich Readings ändern. Ich habe das oben ausführlich beschrieben. (es sieht sehr lustig aus, wenn man auf nur einem Monitor vier Fenster hat - alle mit der gleichen URL, alle mit unterschiedlichen Ausgaben ...)
Ich glaube Dir, dass Du das Symptom siehst, aber die ganzen Erklärungen erscheinen mir etwas seltsam. Das, was im Endeffekt im Client gerendert wird, ist durch JavaScript im Browser erzeugt. Da ist also erst einmal gar keine Interaktion mit dem Server beteiligt. Der Browser hat da auch gar keine Chance, irgendwas aus dem Cache zu holen.
Das einzige, was tatsächlich mit dem Server zu tun hat, ist der longpoll-Mechanismus. Dieser sollte aber sowieso am Cache vorbei gehen, alles andere hätte schon längst ständig zu Problemen geführt.

Zitat
Selbstverständlich kann man jeden Browser selbst dazu bewegen, dass er nicht mehr cacht. Die Frage ist, was cleverer ist, was langfristig zielführend ist.
IMHO: Vielleicht mal herausfinden, welcher Request da tatsächlich aus dem Cache bedient wird und durch "übliche" Techniken selbiges verhindern.

Gruß,
   Thorsten
RasPi
Heizkessel-Steuerung per Arduino und HTTPMOD
und einen Haufen Homematic (Wired)

Offline Thorsten Pferdekaemper

  • Developer
  • Hero Member
  • ****
  • Beiträge: 5552
  • Finger weg von der fhem.cfg
Antw:FHEMWEB: gewünschter Server-Header
« Antwort #21 am: 05 Januar 2019, 10:42:34 »
FTui hat dilich sogar einen eigenen Serverclon. FTUiSRV. Wäre das nicht besser dort aufgehoben?
Meinst Du curt oder mich wegen FUIP?
Gruß,
   Thorsten
RasPi
Heizkessel-Steuerung per Arduino und HTTPMOD
und einen Haufen Homematic (Wired)