Dynamische Inhalte und Cache

[pl]

Mal angenommen,

auf einer Seite wird das aktuelle Datum angezeigt was serverseitig eingebaut wurde. Ist es sinnvoll, diese Seite zu cachen?

Bitte mal um Hinweise.

[Gunnar Bittersmann]

@@pl

auf einer Seite wird das aktuelle Datum angezeigt was serverseitig eingebaut wurde. Ist es sinnvoll, diese Seite zu cachen?

Die entscheidende Frage ist: Ist es sinnvoll, das aktuelle Datum serverseitig auf einer Seite einzubauen?

LLAP 🖖

[pl]

@Gunnar Bittersmann

auf einer Seite wird das aktuelle Datum angezeigt was serverseitig eingebaut wurde. Ist es sinnvoll, diese Seite zu cachen?

Die entscheidende Frage ist: Ist es sinnvoll, das aktuelle Datum serverseitig auf einer Seite einzubauen?

Wenn das die Frage gewesen wäre hätte ich sie so gestellt. Aber hier gehts um dynamische Inhalte und das Datum ist nur ein Beispiel. Ein sehr gutes Übrigens!

MfG

[Felix Riesterer]

Lieber pl,

Die entscheidende Frage ist: Ist es sinnvoll, das aktuelle Datum serverseitig auf einer Seite einzubauen?

das ist eine sehr berechtigte Frage.

Wenn das die Frage gewesen wäre hätte ich sie so gestellt. Aber hier gehts um dynamische Inhalte und das Datum ist nur ein Beispiel.

Dann entscheide doch Du, bei welchen Inhalten es Deiner Meinung nach einen Sinn hat, die Seite cachen zu lassen. Gunnars Meinung war Dir ja nicht gut genug, warum sollte die von jemand anderes dann besser sein?

Ein sehr gutes Übrigens!

Anscheinend findest das nur Du so. Daher auch mein Vorschlag, dass Du in dieser Frage völlig alleine entscheiden solltest.

Liebe Grüße,

Felix Riesterer.

[pl]

hi,

Ok, ich denke wir können die Sache abbrechen.

PS:

Wenn das die Frage gewesen wäre hätte ich sie so gestellt. Aber hier gehts um dynamische Inhalte und das Datum ist nur ein Beispiel.

Ein sehr gutes Übrigens!

Deswegen weil es auf die älteste und am meisten verbreitete Art und Weise des Cachen abzielt.

Und genau deswegen kann man die Frage allgemein beantworten. So ist ein Datum gültig von 0 bis 24 Uhr und dementsprechend kann man Last-Modified und Expires setzen.

Ganz analog verhält es sich mit jeder Art von dynamischen Inhalten, dynamisch heißt ja, dass es ein Datum der letzten Änderung gibt und somit wird auch ein Verfallsdatum sinnvoll.

Im Übrigen stellt sich die Frage bei jeder Art von Content.

[beatovich]

hallo

Ganz analog verhält es sich mit jeder Art von dynamischen Inhalten, dynamisch heißt ja, dass es ein Datum der letzten Änderung gibt und somit wird auch ein Verfallsdatum sinnvoll.

Auch dynamisch (also auf dem Server zusammengebaute) Inhalte können über einen längeren Zeitraum das identische Ergebnis ausliefern.

[beatovich]

hallo

Mal angenommen,

auf einer Seite wird das aktuelle Datum angezeigt was serverseitig eingebaut wurde. Ist es sinnvoll, diese Seite zu cachen?

Bitte mal um Hinweise.

Kommt auf die Rolle des Datums an. Ist dieses Datum in irgend einer Weise in der URL repräsentiert, dann ja.

[pl]

hallo

Mal angenommen,

auf einer Seite wird das aktuelle Datum angezeigt was serverseitig eingebaut wurde. Ist es sinnvoll, diese Seite zu cachen?

Bitte mal um Hinweise.

Kommt auf die Rolle des Datums an. Ist dieses Datum in irgend einer Weise in der URL repräsentiert, dann ja.

Wie ist das denn zu verstehen? Könntest Du das mal ein bischen ausführlicher erläutern?

MfG

[beatovich]

hallo

Kommt auf die Rolle des Datums an. Ist dieses Datum in irgend einer Weise in der URL repräsentiert, dann ja.

Wie ist das denn zu verstehen? Könntest Du das mal ein bischen ausführlicher erläutern?

Nimm als Beispiel ein Webtagebuch. Da steht das Datum für den Inhalt, der hier als ein unveränderlicher Inhalt definiert sei. Dieses Tagebuch kann urls haben, in welchen das Erstelldatum irgendwie mitverarbeitet ist

[pl]

hallo

Kommt auf die Rolle des Datums an. Ist dieses Datum in irgend einer Weise in der URL repräsentiert, dann ja.

Wie ist das denn zu verstehen? Könntest Du das mal ein bischen ausführlicher erläutern?

Nimm als Beispiel ein Webtagebuch. Da steht das Datum für den Inhalt, der hier als ein unveränderlicher Inhalt definiert sei. Dieses Tagebuch kann urls haben, in welchen das Erstelldatum irgendwie mitverarbeitet ist

Machst Du das irgendwo? Also Beispiel?

MfG

[beatovich]

hallo

Nimm als Beispiel ein Webtagebuch. Da steht das Datum für den Inhalt, der hier als ein unveränderlicher Inhalt definiert sei. Dieses Tagebuch kann urls haben, in welchen das Erstelldatum irgendwie mitverarbeitet ist

Machst Du das irgendwo? Also Beispiel?

https://forum.selfhtml.org/self/2018/apr/29/dynamische-inhalte-un-cache/1720816#m1720816

[pl]

Machst Du das irgendwo? Also Beispiel?

https://forum.selfhtml.org/self/2018/apr/29/dynamische-inhalte-un-cache/1720816#m1720816

Da gibt es kein Last-Modified. Da wird evntl. by ETag (if_none_match) gecached aber das konnte ich nicht nachvollziehen. Bei mir wird die Seite nicht gecached (status 200 bei jedem Request).

MfG

[beatovich]

hallo

https://forum.selfhtml.org/self/2018/apr/29/dynamische-inhalte-un-cache/1720816#m1720816

Da gibt es kein Last-Modified. Da wird evntl. by ETag (if_none_match) gecached aber das konnte ich nicht nachvollziehen. Bei mir wird die Seite nicht gecached (status 200 bei jedem Request).

Das war auch nur ein aus der Hüfte geschossenes Beispiel. Vergib mir, dass ich das Cache-Verhalten von Seiten nicht überprüfe, ausser bei meinen eigenen. Und da gibt bei mir derzeit keinen datumsbezogenen Inhalt.

[Henry]

Hallo pl,

Da gibt es kein Last-Modified. Da wird evntl. by ETag (if_none_match) gecached aber das konnte ich nicht nachvollziehen. Bei mir wird die Seite nicht gecached (status 200 bei jedem Request).

So schlecht war das Beispiel gar nicht, wenn man andere Sichtweisen dazu befragt. Was meinst du mit Status 200, was für eine Art Cache hattest du denn im Sinn?

Gruss
Henry

[pl]

Status 200 heißt: Vom Server geliefert. Also: Nicht im Cache.

MfG

[Regina Schaukrug]

(Hurra! Eine komplexe Frage zum Cachen. Das ist ja quasi meine Spezialstrecke…)

Aber ja doch!

1. Cache nicht nur clientseitig, sondern auch serverseitig.
2. Erzeuge zum Servercache einen passenden ETAG, der das Datum UND die URL repäsentiert.
3. Sende must_revalidate und den Etag mit den headern.

Bei einer Abfrage nach der Seite ohne ETAG: schaue nach dem cache und ob dieser vorhanden und tagesaktuell ist. Falls ja: Seite aus server-cache und etag ausliefern. Falls nein: cache erzeugen, etag bauen, inhalt und etag ausliefern.

Bei einer Abfrage mit ETAG:

Schaue, ob das Datum im ETAG noch gültig ist: Falls ja: sende nur den ETAG und gut. Falls nicht nimm die neue Seite aus dem cache und sende diese mit dem neuen ETAG. Ist die nicht vorhanden, dann erzeuge diese und den ETAG einmalig. Nicht vergessen die alte Seite und den alten ETAG zu löschen.

Hint: Seite+Etag mit cronjob neu erzeugen. Nicht vergessen die alte Seite und den alten ETAG zu löschen.

Dann wäre da noch die einfachen Methoden:

<?php
header ( 'Expires: ' . date( 'r', mktime( 0, 0, 0, date('n'), date('j')+1, date('Y') ) ) );

Das erzeugt etwas wie:

Expires: Mon, 30 Apr 2018 00:00:00 +0200

Bedeutet: Der Client schaut auf seine Uhr... und die kann sehr falsch gehen. Also wäre besser …

<?php
echo ("Cache-Control: max-age=".(mktime( 0,0,0,date('n'),date('j')+1,date('Y') ) -mktime()));

zu notieren. Das erzeugt etwas wie:

Cache-Control: max-age=36680

Und macht den Cache ab Mitternacht der Serverzeit ungültig. Maßgeblich ist der Zeitpunkt des Requests. Daher muss die Restgültigkeit jedes Mal neu bestimmt werden.

Nur etwas schwieriger wird es, wenn noch Authorisierungen oder Sprachen zu berücksichtigen sind.

[beatovich]

hallo

Nur etwas schwieriger wird es, wenn noch Authorisierungen oder Sprachen zu berücksichtigen sind.

Cache-Control ist doch nicht für POST zuständig. Oder irre ich mich?

[Regina Schaukrug]

Nur etwas schwieriger wird es, wenn noch Authorisierungen oder Sprachen zu berücksichtigen sind.

Cache-Control ist doch nicht für POST zuständig. Oder irre ich mich?

Nun, wenn die Sprache (auch per GET) oder Authorisierungsdaten gesendet werden, dann wird der Browser den eigenen Cache nicht benutzen, sondern die Abfrage ohne if_none_match-header stellen.

Andernfalls sind z.b. SessionID und Sprache im Cookie (Sprache vielleicht auch als Parameter in der URL) enthalten - und müssen beim serverseitigen Caching mit beachtet werden.

[Regina Schaukrug]

Maßgeblich ist der Zeitpunkt des Requests. Daher muss die Restgültigkeit jedes Mal neu bestimmt werden.

Hint: Auf die gewünschte Zeitzone achten.

[pl]

Maßgeblich ist der Zeitpunkt des Requests. Daher muss die Restgültigkeit jedes Mal neu bestimmt werden.

Hint: Auf die gewünschte Zeitzone achten.

Das ist ziemlich verwirrend. Wäre schön wenn Du das mal erklären tätest was Du damit meinst.

MfG

[Regina Schaukrug]

Das ist ziemlich verwirrend.

Wieso? Der Datumswechsel laut GMT, ZULU-TIME oder +00:00 findet nicht gleichzeitig, sondern zwei Stunden später statt als der laut MEST, CEST, Europe/Berlin oder +02:00.

[pl]

Das ist ziemlich verwirrend.

Wieso? Der Datumswechsel laut GMT, ZULU-TIME oder +00:00 findet nicht gleichzeitig, sondern zwei Stunden später statt als der laut MEST, CEST, Europe/Berlin oder +02:00.

Beim Cache spielt das überhaupt keine Rolle! Siehe auch hier

MfG

[pl]

(Hurra! Eine komplexe Frage zum Cachen. Das ist ja quasi meine Spezialstrecke…)

Ja wie wärs denn mit einer Antwort? Nicht einmal meine Frau musste da lange überlegen.

Und ja, natürlich kann man auch per ETag cachen. Last-Modified ist jedoch besser lesbar wenns mal ans Debuggen geht.

MfG

[JürgenB]

Hallo,

Ja wie wärs denn mit einer Antwort? Nicht einmal meine Frau musste da lange überlegen.

also kennst du die Antwort auf deine Frage schon? Ist das hier ein Quiz?

Gruß
Jürgen

[pl]

Hallo,

Ja wie wärs denn mit einer Antwort? Nicht einmal meine Frau musste da lange überlegen.

also kennst du die Antwort auf deine Frage schon? Ist das hier ein Quiz?

Ja natürlich. Und im Gegensatz zu den hier üblichen Matheaufgaben ist das sogar eine sehr praxisnahe Frage. Also interessiert mich schon die Meinung andererer auch hierzu. Aber so wie es aussieht liegen da wohl kaum irgendwelche Erfahrungen vor. Obwohl es auch eine Frage der Logik ist: Ist das Datum von heute morgen noch gültig -- reichen Antworten auf die Frage des Caching von SEO bis Debugging.

Das ist also alles in Allem etwas komplexer als das man es mit einer Antwort der Art "Du musst das für Dich selbst entscheiden" abtun kann. Warum sollte einer ne Frage stellen wenn er es selbst entscheiden will? Andererseits ist es kein Widerspruch Fragen zu stellen wenn man die Antwort kennt oder zumindest meint zu kennen.

Man lernt nie aus. Und man lernt auch aus Dingen die man nicht tun sollte. Wo sind denn hier die Praktiker!?

MfG

[markk]

Lieber Hotti,

Ja natürlich. Und im Gegensatz zu den hier üblichen Matheaufgaben ist das sogar eine sehr praxisnahe Frage. Also interessiert mich schon die Meinung andererer auch hierzu. Aber so wie es aussieht liegen da wohl kaum irgendwelche Erfahrungen vor.

Warum bist du noch in diesem Forum aktiv?

Was motiviert dich denn dann noch hier Fragen zu stellen? Seit mittlerweile einigen - vieler Meinungen nach zu vielen - Jahren legst du ein wiederkehrendes Pattern an den Tag: Du verpackst deine subjektive Meinung in eine rein äußerlich objektiv gestellte Frage. Sobald - freiwillige - Antworten auf deine Frage kommen, versuchst du diese durch nicht nachvollziehbare Argumente zu zerschmettern, ja, gar zu diffamieren.

Unabhängig davon, ob die Qualität der Antworten gegeben ist - was meiner Meinung nach durchaus in den meißten Fällen zutreffend ist -, warum tust du das?

Warum bist du noch in diesem Forum aktiv?

Von Außen betrachtet - und mit durchaus langjähriger, zwar passiver, Erfahrung mit diesem Forum (Tisch, Vererbung, Restaurant etc) - kann ich es einfach nicht mehr nachvollziehen, warum du dir das antust.

Warum bist du noch in diesem Forum aktiv?

Es gibt zwei Fälle:

1. Das Forum ist inkompetent.
2. Das Forum ist kompetent.

Im ersten Fall gibt es keinen Grund mehr für dich hier zu posten. Und bitte verfalle nicht dem there-is-someone-wrong-in-the-internet-phenomenon.

Im zweiten Fall, lies und lerne.

Warum bist du noch in diesem Forum aktiv?

Ich sage nicht, dass alles schwarz und weiß zu betrachten ist. Aber du bist offensichtlich nicht erwünscht hier. Nein, nicht du als Person, sondern nur das, was du postest.

Ich frage erneut: Warum bist du noch in diesem Forum aktiv?

Du gehst doch auf die Rente zu - ich glaube gar, dass du bereits in Rente bist -, was ist eigentlich mit dieser Altersweisheit? Magst du dich in deinem Alter immernoch belanglos im Internet streiten?

Warum bist du noch in diesem Forum aktiv?

VG M

PS: Ich weiß, du wirst nicht antworten, falls du es doch tun solltest, es geht um genau diese Frage hier (falls dir das noch nicht aufgefallen sein sollte): Warum bist du noch in diesem Forum aktiv?

[pl]

@markk

Die beste und wohl auch die schönste Erfahrung ist die Dankbarkeit. Genau deswegen bin ich hier.

MfG

[markk]

Moin,

Die beste und wohl auch die schönste Erfahrung ist die Dankbarkeit. Genau deswegen bin ich hier.

• -1, pl, Netzneutralität ist noch nicht vorbei
• -1, pl, Netzneutralität ist noch nicht vorbei
• -1, pl, Netzneutralität ist noch nicht vorbei
• -1, pl, Netzneutralität ist noch nicht vorbei
• -1, pl, Dynamische Inhalte und Cache
• -1, pl, Dynamische Inhalte und Cache
• -2, pl, Begriff für <...>, [[...]], {...} gesucht
• -2, pl, Begriff für <...>, [[...]], {...} gesucht
• -1, pl, Begriff für <...>, [[...]], {...} gesucht
• -1, pl, Begriff für <...>, [[...]], {...} gesucht
• -1, pl, Begriff für <...>, [[...]], {...} gesucht
• -1, pl, Begriff für <...>, [[...]], {...} gesucht
• -1, pl, Kontaktformular und neues Datenschutzgesetz
• -1, pl, Kontaktformular und neues Datenschutzgesetz
• -3, pl, Kontaktformular und neues Datenschutzgesetz
• -2, pl, Kontaktformular und neues Datenschutzgesetz
• -1, pl, Kontaktformular und neues Datenschutzgesetz
• -2, pl, Kontaktformular und neues Datenschutzgesetz
• -1, pl, Prüfung schlägt fehl
• -2, pl, Prüfung schlägt fehl
• -4, pl, Einfache Erklärung gesucht
• -1, pl, Schweizer Satire Isopropanol
• -1, pl, Alte Browser bei Webseiten ausschließen?
• -2, pl, Alte Browser bei Webseiten ausschließen?
• -2, pl, Alte Browser bei Webseiten ausschließen?
• -2, pl, Was haltet ihr von bootstrap
• -1, pl, Was haltet ihr von bootstrap
• -1, pl, Nachdenkliches zum Wochenende: Alternativen zu Googles Überwachungskapitalismus
• -1, pl, BlobURL in window.open
• -1, pl, DSGVO, Recht auf Vergessenwerden und auf Datenübertragbarkeit
• -2, pl, DSGVO, Recht auf Vergessenwerden und auf Datenübertragbarkeit
• -1, pl, DSGVO, Recht auf Vergessenwerden und auf Datenübertragbarkeit
• -1, pl, Ajax Post Data - PHP Script erzeugt Notice: Undefined index:...
• -1, pl, Ajax Post Data - PHP Script erzeugt Notice: Undefined index:...
• -1, pl, SQL Update bei vielen Anwendern
• -1, pl, Mensch ist gar nicht nur Mensch
• -4, pl, Mensch ist gar nicht nur Mensch
• -1, pl, Fallstudie
• -1, pl, Fallstudie
• -3, pl, Wiki: Perl-Bereich depubliziert
• -1, pl, Wiki: Perl-Bereich depubliziert
• -1, pl, Wiki: Perl-Bereich depubliziert
• -1, pl, Wiki: Perl-Bereich depubliziert
• -2, pl, Wiki: Perl-Bereich depubliziert

Ausschnitt der letzten zwei Wochen.

[Matthias Apsel]

Hallo markk,

• -3, pl, Wiki: Perl-Bereich depubliziert
• -1, pl, Wiki: Perl-Bereich depubliziert
• -1, pl, Wiki: Perl-Bereich depubliziert
• -1, pl, Wiki: Perl-Bereich depubliziert
• -2, pl, Wiki: Perl-Bereich depubliziert

Ausschnitt der letzten zwei Wochen.

Das ist von 2017.

Bis demnächst
Matthias

[markk]

Moin ${vname},

• -3, pl, Wiki: Perl-Bereich depubliziert

Ausschnitt der letzten zwei Wochen. Das ist von 2017.

Oh, ich bitte vielmals um Entschuldigung.

Gut, dass du dir die Mühe gemacht hast, die 11% relativieren natürlich die gesamte Aussage.

Bis demnächst
Matthias

Cheers, markk

[Matthias Apsel]

Hallo markk,

Gut, dass du dir die Mühe gemacht hast,

Ich brauchte mir keine Mühe zu machen, ich wusste, dass die Depublizierung der Perldokumentation nicht innerhalb der letzen beiden Wochen geschah.

die 11% relativieren natürlich die gesamte Aussage.

Was auch immer du mit deiner Aufzählung sagen möchtest, ich möchte sie nicht relativieren.

Bis demnächst
Matthias

[markk]

Hallo Matthias,

Was auch immer du mit deiner Aufzählung sagen möchtest, ich möchte sie nicht relativieren.

Dann habe ich deinen Kommentar wohl falsch aufgefasst.

Cheers, markk

[Regina Schaukrug]

Nicht einmal meine Frau musste da lange überlegen.

Dann befrage eben diese in Zukunft. Oder mag Deine Frau eine solcherart besondere Weise der Ansprache etwa auch nicht?

[pl]

Nicht einmal meine Frau musste da lange überlegen.

Dann befrage eben diese in Zukunft.

Das ist eine gute Idee! Sag das auch den Betreibern dieses Forums!

MfG

[pl]

hi

Das erzeugt etwas wie:

Expires: Mon, 30 Apr 2018 00:00:00 +0200

Was übrigens falsch ist. Die Zeitzone hat in diesem Header nichts zu suchen! Vielmehr sind sämtliche Angaben in HTTP Date GMT. Siehe HTTP Date

FileEtag siehe da

[Gunnar Bittersmann]

@@pl

Expires: Mon, 30 Apr 2018 00:00:00 +0200

Was übrigens falsch ist. Die Zeitzone hat in diesem Header nichts zu suchen! Vielmehr sind sämtliche Angaben in HTTP Date GMT.

Dem ist wohl so. Immer noch. Nur den Beleg dafür bist du schuldig geblieben.

Siehe HTTP Date

Nein. Siehe nicht dort. Veraltet.

Expires: RFC 7234 §5.3

HTTP-date: RFC 7231 §7.1.1.1

LLAP 🖖

[pl]

@Gunnar Bittersmann

Expires: Mon, 30 Apr 2018 00:00:00 +0200

Was übrigens falsch ist. Die Zeitzone hat in diesem Header nichts zu suchen! Vielmehr sind sämtliche Angaben in HTTP Date GMT.

Dem ist wohl so. Immer noch. Nur den Beleg dafür bist du schuldig geblieben.

Siehe HTTP Date

Nein. Siehe nicht dort. Veraltet.

Expires: RFC 7234 §5.3

HTTP-date: RFC 7231 §7.1.1.1

Und was steht da als Beispiel!? Richtig:

Sun, 06 Nov 1994 08:49:37 GMT 

Also keine Zeitzonenangabe sondern GMT!

An HTTP-date value represents time as an instance of Coordinated Universal Time (UTC).

Und Genau deswegen hat die Zeitzone im Expires Header nichts zu suchen!

MfG

[Gunnar Bittersmann]

@@pl

Sun, 06 Nov 1994 08:49:37 GMT 

Also keine Zeitzonenangabe sondern GMT!

Erstens ist GMT eine Zeitzonenangabe.

Zweitens sagte ich nichts Widersprüchliches, sondern:

„Dem ist wohl so. Immer noch. Nur den Beleg dafür bist du schuldig geblieben.“

An HTTP-date value represents time as an instance of Coordinated Universal Time (UTC).

Darüber, dass UTC was anderes ist als GMT, sehen wir hier mal geflissentlich hinweg.

Und Genau deswegen hat die Zeitzone im Expires Header nichts zu suchen!

S.o.

LLAP 🖖

[pl]

@Gunnar Bittersmann

Zweitens sagte ich nichts Widersprüchliches, sondern:

„Dem ist wohl so. Immer noch. Nur den Beleg dafür bist du schuldig geblieben.“

Was eine glatte Lüge ist: Den RFC hatte ich verlinkt! Und wer diesen richtig versteht, wird nicht auf die Idee kommen eine von GMT oder UTC abweichende Zeitzone in einen Expires Header zu setzen. Das macht übrigens, auch ohne den RFC zu HTTP~Date zu kennen, überhaupt keinen Sinn!

MfG

[Gunnar Bittersmann]

@@pl

„Dem ist wohl so. Immer noch. Nur den Beleg dafür bist du schuldig geblieben.“

Was eine glatte Lüge ist: Den RFC hatte ich verlinkt!

Aber den falschen.

Wenn du Verständnisprobleme hast, können wir versuchen, diese aus dem Weg zu räumen. Aber bezichtige hier andere nicht der Lüge!

LLAP 🖖

[pl]

@Gunnar Bittersmann

Wenn du Verständnisprobleme hast, können wir versuchen, diese aus dem Weg zu räumen. Aber bezichtige hier andere nicht der Lüge!

Ich verstehe sehr gut. Im Übrigen ist es pure Trollerei deinerseits, einen Streit vom Zaune zu brechen ob GMT eine Zeitzonenangabe ist oder den Sachverhalt ausdrückt keine von GMT abweichende Zeitzone zu notieren. Das Problem liegt bi Dir.

.

[Gunnar Bittersmann]

@@pl

Wenn du Verständnisprobleme hast, können wir versuchen, diese aus dem Weg zu räumen. Aber bezichtige hier andere nicht der Lüge!

Ich verstehe sehr gut. Im Übrigen ist es pure Trollerei deinerseits, einen Streit vom Zaune zu brechen ob GMT eine Zeitzonenangabe ist oder den Sachverhalt ausdrückt keine von GMT abweichende Zeitzone zu notieren. Das Problem liegt bi Dir.

Wieder mal typisch: Wenn du in die Ecke gedrängt bist, lenkst du mit einem anderen Thema ab. Glaubt du wirklich, du kommst mit dieser Masche durch?

Es geht hier immer noch darum, dass du für deine Aussage „Vielmehr sind sämtliche Angaben in HTTP Date GMT“ keinen gültigen Beleg geliefert hast und mich einen Lügner genannt hast, als ich dich darauf hinwies.

Dass „Vielmehr sind sämtliche Angaben in HTTP Date GMT“ immer noch gültig ist, hast du dem blanken Zufall zu verdanken. Es hätte auch anders kommen können und inzwischen wären auch Angaben im vernünftigen Datumsformat ISO 8601 möglich – du hättest es nicht gewusst, weil du in deiner Uraltquelle verhaftet geblieben bist. Und das, obwohl aus dieser selbst hervorgeht, dass sie veraltet ist.

„Ich verstehe sehr gut“? Ich habe da Bedenken.

LLAP 🖖

[pl]

@Gunnar Bittersmann

Wieder mal typisch: Wenn du in die Ecke gedrängt bist, lenkst du mit einem anderen Thema ab.

Unsinn. Typisch ist vielmehr, daß jeder meiner Beiträge hier die Trolle auf den Plan ruft und da bist Du kein Deut besser als alldie Anderen hier. Damit wird jegliche fachliche Diskussion im Keim erstickt!

Andererseits würde ein Hinweis auf RFC2616 ganz anders diskutiert werden, weil jeder selbst denken kann, Trolle jedoch ihr Gehirn abschalten. Und jeder der sich ein bischen intensiver mit dem Thema Cache befasst hat, wird auch von sich aus darauf kommen daß die Angabe einer von GMT/UTC abweichenden Zeitzone in Sachen Cache überhaupt keinen Sinn ergibt.

Das sind sozusagen Überlegungen erster Ordnung bei denen das Datumsformat noch gar keine Rolle spielt! Und im ETag sowieso nicht!

MfG

[dedlfix]

Tach!

Und jeder der sich ein bischen intensiver mit dem Thema Cache befasst hat, wird auch von sich aus darauf kommen daß die Angabe einer von GMT/UTC abweichenden Zeitzone in Sachen Cache überhaupt keinen Sinn ergibt.

Es gibt Betriebssysteme, die laufen nicht unter UTC sondern Lokalzeit. Diese müssen also die Lokalzeit in UTC umrechnen oder die Cache-Zeitangabe in Lokalzeit, bevor sie weitermachen können. Das ist mit den entsprechend vorhandenen Bibliotheken kein Problem. Insofern ist es auch problemlos, eine Cache-Zeitangabe in anderer Zeitzone entgegenzunehmen und so umzurechnen, wie sie intern gebraucht wird. Vermutlich wird das in den Browsern so großzügig implementiert sein, dass Angaben mit von GMT abweichenden Zeitzonen korrekt verarbeiten werden, auch wenn diese Angaben nicht der RFC entsprechen. Ich sehe deshalb keinen gesteigerten Sinn darin, sich auf GMT festzulegen, aber du kannst mir gern die Gründe dafür erklären.

dedlfix.

[pl]

He Danke!

Und jeder der sich ein bischen intensiver mit dem Thema Cache befasst hat, wird auch von sich aus darauf kommen daß die Angabe einer von GMT/UTC abweichenden Zeitzone in Sachen Cache überhaupt keinen Sinn ergibt.

Es gibt Betriebssysteme, die laufen nicht unter UTC sondern Lokalzeit. Diese müssen also die Lokalzeit in UTC umrechnen oder die Cache-Zeitangabe in Lokalzeit, bevor sie weitermachen können. Das ist mit den entsprechend vorhandenen Bibliotheken kein Problem. Insofern ist es auch problemlos, eine Cache-Zeitangabe in anderer Zeitzone entgegenzunehmen und so umzurechnen, wie sie intern gebraucht wird. Vermutlich wird das in den Browsern so großzügig implementiert sein, dass Angaben mit von GMT abweichenden Zeitzonen korrekt verarbeiten werden, auch wenn diese Angaben nicht der RFC entsprechen. Ich sehe deshalb keinen gesteigerten Sinn darin, sich auf GMT festzulegen, aber du kannst mir gern die Gründe dafür erklären.

Genauso stelle ich mir eine fachliche Diskussion vor. Letztendlich läuft das Cachen per Last-Modified jedoch nur auf einen Stringvergleich hinaus. Genauso wie beim ETag.

MfG

PS/Schnelltest: Für Last-Modified lässt mein Apache 2.2 keine eigenen Formate zu. Also auch keine von GMT abweichende ZZ.

[dedlfix]

Tach!

Ich sehe deshalb keinen gesteigerten Sinn darin, sich auf GMT festzulegen, aber du kannst mir gern die Gründe dafür erklären.

Genauso stelle ich mir eine fachliche Diskussion vor.

Ich mir allerdings nicht, denn du gehst nicht auf meine fachlichen Aspekte ein, besonders nicht auf den Wunsch, mir deine Ansicht zu erklären. Wie soll da eine ertragreiche Diskussion zustandekommen?

Letztendlich läuft das Cachen per Last-Modified nur auf einen Stringvergleich hinaus. Genauso wie beim ETag.

Beim ETag geht das, der soll auch nur ein "gleich oder nicht" ergeben. Aber bei eine Angabe wie Sun, 06 Nov 1994 08:49:37 GMT ist ein Stringvergleich nicht möglich, weil man hier wissen möchte, ob man davor oder danach liegt und ein Stringvergleich ist da nicht zielführend.

dedlfix.

[pl]

Tach!

Ich sehe deshalb keinen gesteigerten Sinn darin, sich auf GMT festzulegen, aber du kannst mir gern die Gründe dafür erklären.

Genauso stelle ich mir eine fachliche Diskussion vor.

Ich mir allerdings nicht, denn du gehst nicht auf meine fachlichen Aspekte ein, besonders nicht auf den Wunsch, mir deine Ansicht zu erklären. Wie soll da eine ertragreiche Diskussion zustandekommen?

Dadurch daß man die Einheit von Theorie und Praxis sowie seine Erfahrungen hier einbringt. Was Du an JEDEM meiner Beiträge sprürbar nachvollziehen kannst!

Offensichtlich hast Du meinen letzten Beitrag gar nicht gelesen. Wie soll da eine ertragreiche Diskussion zustande kommen!?

Schade!

[Gunnar Bittersmann]

@@pl

Unsinn. Typisch ist vielmehr, daß jeder meiner Beiträge hier die Trolle auf den Plan ruft und da bist Du kein Deut besser als alldie Anderen hier. Damit wird jegliche fachliche Diskussion im Keim erstickt!

Alles klar: Du der Fachmann, alle anderen hier Trolle. Du bist echt der Knüller!

Andererseits würde ein Hinweis auf RFC2616 ganz anders diskutiert werden,

RFC 2616 ist veraltet, obsolet, außer Kraft gesetzt. Mehr gibt es darüber nicht zu diskutieren.

LLAP 🖖

[pl]

Abgesehen vom eigentlichen Thema. Du schreibst darüber wie Du einen Cache serverseitig realisierst. Wozu eigentlich?

Schau mal, ein serverseitiger Cache optimiert allenfalls serverseitige Prozesse. Der Transport jedoch, der Dialog zwischen Client und Server bleibt davon unberührt. Letzeres ist jedoch genau das Thema um was es hier geht. So ist es der Client, der dem Server mitzuteilen hat, ob er einen bestimmten Inhalt bereits im Cache hat oder neu anfordern will.

Und es ist der Server welcher dem Client mitteilt, wann ein bestimmter Inhalt erstellt bzw. zuletzt geändert wurde. Diese Dialoge werden zwischen Client/Server über HTTP Header abgewickelt und grundsätzliches dazu lässt sich bereits am Webserver selbst konfigurieren.

So setzt der Apache spontan einen Last-Modified Header anhand der Angaben die er zur Datei aus dem Dateisystem findet. Oder er generiert spontan einen ETag anhand dieser Angaben. Vorausgesetzt, es ist so konfiguriert.

Mit dieser Spontanität ists jedoch vorbei wenn der Apache die Inhalte nicht aus dem Dateisystem liest sondern anderweitig bekommt. D.h., für solche Fälle zu regeln ist der Publisher zuständig. Wohlgemerkt: der Publisher, nicht der Programmierer serverseitiger Anwendungen, der setzt das nur um.

Und in diesen Dialog kann ein Benutzer jederzeit eingreifen. Er kann den Cache entleeren und er kann jederzeit veranlassen, daß eine Seite komplett neu vom Server angefordert wird. Einschließlich der darin verlinkten Ressourcen.

Wozu also möchtest Du da serverseitig cachen anstatt diese Standards zweckmäßgerweise einfach nur anzuwenden? Die, abgesehen davon auch völlig unabhängig davon existieren und funktionieren.

MfG