FHEMWEB: gewünschter Server-Header

Begonnen von curt, 26 Dezember 2018, 23:12:07

Vorheriges Thema - Nächstes Thema

curt

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 4 - Jeelink HomeMatic Z-Wave

rudolfkoenig

ZitatGewü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.

curt

Zitat von: rudolfkoenig am 27 Dezember 2018, 10:17:22und 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.

Zitat von: rudolfkoenig am 27 Dezember 2018, 10:17:22Ich 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 4 - Jeelink HomeMatic Z-Wave

rudolfkoenig

ZitatDiese beiden sind IE-spezifische Sonderlocken zur serverseitig vorgegebenen Cache-Steuerung.
Tut mir leid, IE unterstuetze ich nicht. Irgendwo muss man die Grenze ziehen :)

ZitatEs 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.

curt

Zitat von: rudolfkoenig am 28 Dezember 2018, 10:22:44
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.

Zitat von: rudolfkoenig am 28 Dezember 2018, 10:22:44
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 4 - Jeelink HomeMatic Z-Wave

rudolfkoenig

ZitatRudolf, 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?

curt

Zitat von: rudolfkoenig am 28 Dezember 2018, 18:28:54
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.

Zitat von: rudolfkoenig am 28 Dezember 2018, 18:28:54
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.

Zitat von: rudolfkoenig am 28 Dezember 2018, 18:28:54
Ich werde fuer diese kein "no-cache,no-store" einbauen,

Ich möchte es trotzdem diskutieren.

Zitat von: rudolfkoenig am 28 Dezember 2018, 18:28:54
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.

Zitat von: rudolfkoenig am 28 Dezember 2018, 18:28:54
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 4 - Jeelink HomeMatic Z-Wave

rudolfkoenig

ZitatSo 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?

ZitatSelbst 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.

curt

Zitat von: rudolfkoenig am 28 Dezember 2018, 19:15:30
Erstens ist das nicht so trivial, weil dieser Code in FHEMWEB an mehreren Stellen existiert.

Ich habe mich artig auf meine Fingerchen gesetzt.

Zitat von: rudolfkoenig am 28 Dezember 2018, 19:15:30
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.

Zitat von: rudolfkoenig am 28 Dezember 2018, 19:15:30
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 4 - Jeelink HomeMatic Z-Wave

herrmannj

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

rudolfkoenig

ZitatIn 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.

ZitatWieso 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.

curt

Zitat von: rudolfkoenig am 28 Dezember 2018, 20:53:22
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.

Zitat von: rudolfkoenig am 28 Dezember 2018, 20:53:22
Reden wir hier von Entwicklung?

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

Zitat von: rudolfkoenig am 28 Dezember 2018, 20:53:22
- 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.

Zitat von: rudolfkoenig am 28 Dezember 2018, 20:53:22
- 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.)

Zitat von: rudolfkoenig am 28 Dezember 2018, 20:53:22
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 4 - Jeelink HomeMatic Z-Wave

herrmannj


curt

<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 4 - Jeelink HomeMatic Z-Wave

herrmannj

#14
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.