FHEMWEB: gewünschter Server-Header

[Thorsten Pferdekaemper]

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

[rudolfkoenig]

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:

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

[curt]

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.

[JoeALLb]

FTui hat dilich sogar einen eigenen Serverclon. FTUiSRV. Wäre das nicht besser dort aufgehoben?

[curt]

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

[Thorsten Pferdekaemper]

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.

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.

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

[Thorsten Pferdekaemper]

FTui hat dilich sogar einen eigenen Serverclon. FTUiSRV. Wäre das nicht besser dort aufgehoben?

Meinst Du curt oder mich wegen FUIP?
Gruß,
   Thorsten