Caching

[Christian S.]

Hi,

ich gebe über ein PHP Skript JavaScript aus (könnten auch Bilder sein):

etwa so:

<script type="text/javascript" src="script.php?id=test"></script>

Klappt auch.

Als Header im PHP Skript gebe ich:

header('Content-type: application/x-javascript');

an.

Wenn ich mir das ganze im Firebug anschaue, dann stelle ich fest, dass "normal" referenzierte Quellen, wie z.B. Bilder oder CSS Dateien gecachet werden.

Der Browser schickt sogar immer noch Header wie "If-Modified-Since" mit.

Das tut er bei meiner script.php nicht. Dort steht kein "If-Modified-Since" in den Request-Headern... warum?

Weiterhin steht auch in den Response-Headern: Pragma: no-cache.
Wo kommt das her?

Und ein Expires Datum in der Vergangenheit.

Ich würde gerne erreichen, dass der Browser mein skript.php?id=test cachet!

Und dass er für diese Resource ein "If-Modified-Since" Header an den Server schickt. Dort möchte ich dann an Hand des Datums entscheiden, ob der Browser ein 304 Status Code (not modified) zurückbekommt, oder eben eine neue Version.

Gruß!

[Edgar Ehritt]

Hallo,

<script type="text/javascript" src="script.php?id=test"></script>

header('Content-type: application/x-javascript');

(Nur nebenbei bemerkt ist der richtige MIME-Type application/javascript!)

Wenn ich mir das ganze im Firebug anschaue, dann stelle ich fest, dass "normal" referenzierte Quellen, wie z.B. Bilder oder CSS Dateien gecachet werden. Der Browser schickt sogar immer noch Header wie "If-Modified-Since" mit. Das tut er bei meiner script.php nicht. Dort steht kein "If-Modified-Since" in den Request-Headern... warum?

PHP senden von allein keinen Header ETag (vgl. Apache-Dokumentation: FileEtag). Der ETag-header beinhaltet eine sehr wahrscheinlich eindeutige Referenz einer angeforderten Resource bezüglich ihrer inhaltlichen Veränderung. Der bei der erstmaligen Anfrage dem Browser übergebene Wert dieses Headers wird bei einer erneuten Anfrage an die selbe Resource im Request-Header If-None_Match dem Server zur Überprüfung mitgegeben.

Mit dem Request-Header If-Modified-Since sieht ähnlich aus. Dieser beinhaltet als Prüfwert für den Server den Inhalt des Resopnse-Header Last-Modified der ersten Anfrage an eine Resource. Da PHP auch diesen Header nicht von alleine setzt, hat der Browser keine Möglichkeiten Konditionen zu stellen, um eine überflüssige Auslieferung der Resource zu verhindern.

Weiterhin steht auch in den Response-Headern: Pragma: no-cache. Und ein Expires Datum in der Vergangenheit.
Wo kommt [die] her?

Wenn Du sie nicht in Dein Script durch header() hineingesetzt hast, gucke bitte mittels phpinfo(4) ob durch die Konfigurationsanweisung auto_prepend_file ein Script bestimmt wurde, was vor jedem Deiner Scripte ausgeführt wird!

Ich würde gerne erreichen, dass der Browser mein skript.php?id=test cachet!

Sieh dir die Funktion header(), Expires, Cache-Control und Pragma an!

Und dass er für diese Resource ein "If-Modified-Since" Header an den Server schickt. Dort möchte ich dann an Hand des Datums entscheiden, ob der Browser ein 304 Status Code (not modified) zurückbekommt, oder eben eine neue Version.

Was steht Dir einer Verarbeitung der Request-Header, die Dir in der globalen Variable $_SERVER zu Verfügung stehen, im Wege?

Gruß aus Berlin!
eddi

[Christian S.]

Hi,

(Nur nebenbei bemerkt ist der richtige MIME-Type application/javascript!)

Ist diese RFC denn auch standardisiert? Jedenfalls scheint es so zu sein, dass z.B. Apache standardmäßig "appclication/x-javascript" für JS dateien ausliefert.

Auch wird dieser Mime-Type von den meisten Browsern unterstützt

application/javascript hingegen nur von FF 1.5+ und Opera 9. Das wäre wohl sehr inakzeptabel.

Danke für deine Antwort und die vielen Links. Werd es mir mal anschauen.

Gruß!

[Edgar Ehritt]

Re:

(Nur nebenbei bemerkt ist der richtige MIME-Type application/javascript!)

Ist diese RFC denn auch standardisiert? Jedenfalls scheint es so zu sein, dass z.B. Apache standardmäßig "appclication/x-javascript" für JS dateien ausliefert.

Die RFC ist informativ. Dies gibt auch die referenzierte Resource an! Desweiteren _scheint_ es auch nur, dass der Apache standardmäßig Resourcen mit Dateiendungen "js" als "appclication/x-javascript" ausliefert. Auszug aus den Sourcen:

application/javascript   js   (version 2.2.8  /docs/conf/mime.types)
application/javascript   js   (version 2.0.63 /docs/conf/mime.types)
application/javascript   js   (version 1.3.41 /conf/mime.types)

Auch wird dieser Mime-Type von den meisten Browsern unterstützt

application/javascript hingegen nur von FF 1.5+ und Opera 9. Das wäre wohl sehr inakzeptabel.

Dieses Dokument bezieht sich vermutlich auf das Attribut type im <script>-Element. IE <=6 versteht hierbei auch kein "appclication/x-javascript". Mir ging es grundsätzlich um den per HTTP versendeten header Content-Type, den die meisten Browser bei einer Scriptreferens eh links liegen lassen.

Gruß aus Berlin!
eddi

[Cybaer]

Hi,

Desweiteren _scheint_ es auch nur, dass der Apache standardmäßig Resourcen mit Dateiendungen "js" als "appclication/x-javascript" ausliefert.

Auszug aus dem Response-Header eines (IMHO recht beliebigen) Apacheservers beim Request einer (statischen) .js-Resource:

Content-Type: application/x-javascript

Es _scheint_ also recht _deutlich_! ;-)

Gruß, Cybaer

[Edgar Ehritt]

Hallo,

Auszug aus dem Response-Header eines (IMHO recht beliebigen) Apacheservers beim Request einer (statischen) .js-Resource:

Content-Type: application/x-javascript

Es _scheint_ also recht _deutlich_! ;-)

Und wenn es auch nur die Patina auf der Software der Version wegen ist - es _scheint_ sehr hell, einer Verjährung resistent aus der Vergangenheit, aber führt offensichtlich nicht zur Erleuchtung! >:{

Immer dieses X für'n U. ^.-

Gruß aus Berlin!
eddi v 0.3.1

[Cybaer]

Hi,

Und wenn es auch nur die Patina auf der Software der Version wegen ist - es _scheint_ sehr hell, einer Verjährung resistent aus der Vergangenheit, aber führt offensichtlich nicht zur Erleuchtung! >:{

:->

Komme zur dunklen Seite der Macht, eddi! Erkenne die Realität ... >>;->

Gruß, Cybaer

[Edgar Ehritt]

Komme zur dunklen Seite der Macht, eddi! Erkenne die Realität ... >>;->

Verführe mich, aber wisse - ein Fehler Deinerseits und Du wirst Dir das Hellste ins Dunkle geholt haben, nichts wird mehr so sein, das es bleiben kann.

[Cybaer]

Hi,

Komme zur dunklen Seite der Macht, eddi! Erkenne die Realität ... >>;->
Verführe mich, aber wisse - ein Fehler Deinerseits und Du wirst Dir das Hellste ins Dunkle geholt haben, nichts wird mehr so sein, das es bleiben kann.

Aaaaahhhh, ich bin geblendet! %-))

Gruß, Cybaer

[Edgar Ehritt]

Re:

Aaaaahhhh, ich bin geblendet! %-))

Ich sag's Dir: Ich weißle, ich weißle. :-P

Gruß aus Berlin!
eddi

[Cybaer]

Hi,

Re:

Aaaaahhhh, ich bin geblendet! %-))

Ich sag's Dir: Ich weißle, ich weißle. :-P

Gruß aus Berlin!
eddi

Gruß, Cybaer

[Cybaer]

Hi,

Aaaaahhhh, ich bin geblendet! %-))
Ich sag's Dir: Ich weißle, ich weißle. :-P

Hmm, Berliner Weißle? ;-)

Gruß, Cybaer

[Edgar Ehritt]

Lies von Max Frisch "Andorra"!

[Cybaer]

Hi,

Lies von Max Frisch "Andorra"!

Ach so. :-)

Ja, danke, habe ich. 8-)

Gruß, Cybaer

[Christian S.]

Hi,

also das Cachen klappt schon ganz gut :-), also dass ich 304 zurückgebe, wenn das Last-Modified nicht mit dem If-Modified-Since passt.

Wenn Du sie nicht in Dein Script durch header() hineingesetzt hast, gucke bitte mittels phpinfo(4) ob durch die Konfigurationsanweisung auto_prepend_file ein Script bestimmt wurde, was vor jedem Deiner Scripte ausgeführt wird!

Nein, tut er nicht. Da steht "no value".

Ich habe auch nichts eingebunden. Aber es werden ja auch noch andere Header mitgesendet, wie z.B. "X-Powered-By: PHP/5.2.1", Server, Date, Keep-Alive, Connection...

kA, wo die alle herkommen.

Gruß!

[Edgar Ehritt]

Hallo,

Hi,

also das Cachen klappt schon ganz gut :-), also dass ich 304 zurückgebe, wenn das Last-Modified nicht mit dem If-Modified-Since passt.

da hoffe ich mal auf einen Tippfehler. Status 304 sollt zurückgegeben werden, wenn Last-Modified und If-Modified-Since zusammen passen.

Nein, tut er nicht. Da steht "no value".

Dann werden diese Header vom Server gesetzt. Um welchen handelt es sich?

Ich habe auch nichts eingebunden. Aber es werden ja auch noch andere Header mitgesendet, wie z.B. "X-Powered-By: PHP/5.2.1", Server, Date, Keep-Alive, Connection...

X-Powered-By wird von PHP selbst generiert. Das hängt mit der Konfiguration expose_php zusammen. Header Server, Date, Keep-Alive und Connection werden vom Server gesetzt, wobei Date den Auslieferungszeitpunkt ausweist. Das ist (nur) wichtig für proxies. Keep-Alive und Connection korrespondieren im Idealfall mit den Wünschen, die der Client (Browser) dem Server in gleichnamigen Headern sendet und sind für Dein eigentliches Anliegen nebensächlich.

Gruß aus Berlin!
eddi

[Christian S.]

Hi,

da hoffe ich mal auf einen Tippfehler. Status 304 sollt zurückgegeben werden, wenn Last-Modified und If-Modified-Since zusammen passen.

Es lag an der Uhrzeit :-). Mich wunderts dass du noch so aufmerksam warst... Ist nur ein Tippfehler...

Dann werden diese Header vom Server gesetzt. Um welchen handelt es sich?

Apache/2.0.54 (Win32) mod_jk2/2.0.4 PHP/5.2.1

Gruß!

[Edgar Ehritt]

Re:

Es ist also zu vermuten, dass der Apache die Header setzt. Dann ist aber auch das Modul mod_headers aktiviert. Füge also bitte folgendes in eine .htaccess ein, um zu versuchen den Pragma- und Expires-Header zu löschen.

  
<FilesMatch \.php>  
   <IfModule headers_module>  
      Header unset Pragma  
      Header unset Expires  
   </IfModule>  
</FilesMatch>  

Gruß aus Berlin!
eddi

[Christian S.]

Hi,

mod_headers aktiviert. Füge also bitte folgendes in eine .htaccess ein, um zu versuchen den Pragma- und Expires-Header zu löschen.

Hilft leider nichts.

Wie ich aber inzwischen herausgefunden habe, ist folgende Funktion dafür verantwortlich:

session_start();

Rufe ich diese auf, dann werden diese ganzen Cache Header (expires, pragma, cache-control) gesetzt. Lasse ich sie weg, dann sind die Header auch weg.

Gruß!

[ChrisB]

Hi,

Wie ich aber inzwischen herausgefunden habe, ist folgende Funktion dafür verantwortlich:

session_start();

Rufe ich diese auf, dann werden diese ganzen Cache Header (expires, pragma, cache-control) gesetzt. Lasse ich sie weg, dann sind die Header auch weg.

RTFMchen ...

http://www.php.net/manual/en/session.configuration.php#ini.session.cache-limiter
http://www.php.net/manual/en/function.session-cache-limiter.php

MfG ChrisB

[Cybaer]

Hi,

Der ETag-header beinhaltet eine sehr wahrscheinlich eindeutige Referenz einer angeforderten Resource bezüglich ihrer inhaltlichen Veränderung.

Nein. Der ETag-Header sagt (zumindest beim Apache) *überhaupt nichts* über Inhalt bzw. Inhaltsveränderung aus! Man darf ihn also z.B. nicht verwenden, wenn man eine inhaltlich identische Resource über eine Serverfarm ausliefern möchte.

Da wären dann, trotz gleichen Inhalts, die ETags unterschiedlich, und ob ein 304er oder 200er kommt, wäre nur davon abhängig, ob der Folgerequest *zufällig* vom selben Server bearbeitet würde, wie der Erstrequest. =:-)

Gruß, Cybaer

[Edgar Ehritt]

Huhu,

"Der ETag-header beinhaltet eine SEHR WAHRSCHEINLICH EINDEUTIGE Referenz einer angeforderten Resource bezüglich ihrer inhaltlichen Veränderung."

Nein. Der ETag-Header sagt (zumindest beim Apache) *überhaupt nichts* über Inhalt bzw. Inhaltsveränderung aus! Man darf ihn also z.B. nicht verwenden, wenn man eine inhaltlich identische Resource über eine Serverfarm ausliefern möchte.

Da wären dann, trotz gleichen Inhalts, die ETags unterschiedlich, und ob ein 304er oder 200er kommt, wäre nur davon abhängig, ob der Folgerequest *zufällig* vom selben Server bearbeitet würde, wie der Erstrequest. =:-)

Header ETag beinhaltet die letzte Modifitierungszeit. (Sicher gibt es auch Leute, deren Programme, wenn diese eine resouce -anfassen-, nicht mit einem touch() Ursprünglichkeit regenerieren. system administratoren habe ich jedenfalls nicht bei der Albernheit erwischen können, ein mtime-wegkonfigurierte Server zu führen. Und was anderes fällt mir spontan nicht an Deinem Vorhalt ein, weil ich nichts konkretes sehe :/ )

Gruß aus Berlin!
eddi

[Cybaer]

Hi,

Header ETag beinhaltet die letzte Modifitierungszeit.

Irrelevant.

Er beinhaltet auch die (Node-)Position der Datei. Und auf einer anderen Platte, hast Du eine andere Position, einen anderen ETag-Content, und das war's dann mit dem Caching ...

Wenn der ETag-Content sich ändert, kann der Dateiinhalt immer noch der gleiche sein. Also ist er kein Kriterium ob sich eine Datei wahrscheinlich geändert hat.

Gruß, Cybaer

[Edgar Ehritt]

Re:

Header ETag beinhaltet die letzte Modifitierungszeit.
Irrelevant.

Irrtum, weil _genau_ das ist der Gegenstand des Disputs.

Gruß aus Berlin!
eddi

[Cybaer]

Hi,

Header ETag beinhaltet die letzte Modifitierungszeit.
Irrelevant.
Irrtum, weil _genau_ das ist der Gegenstand des Disputs.

Nein. Es geht um Caching. Und in Folge dessen, ob eine Datei inhaltlich geändert wurde. Inhaltliche Änderungen werden mit dem ETag-Header, so wie ihn Apache generiert - man muß es ja nicht so machen, ich sende z.B. ggf. einen Datenhash (oder einen weniger rechenintensiven Hash) -, nicht erfasst. Der Value des ETags ist ja nicht standardisiert.

Wer hilfsweise nur das letzte Modifizierungsdatum als Änderungskriterium werten möchtest (und darauf läuft dein Hinweis, daß dieses Datum, zumindest beim Apache, in den ETag-Content doch mit einfließt ja hinaus), der sollte den Last-Modified-Header einsetzen.

Beide Header sind fürs Caching gleichrangig.

Gruß, Cybaer

[Edgar Ehritt]

Re:

Header ETag beinhaltet die letzte Modifitierungszeit.
Irrelevant.
Irrtum, weil _genau_ das ist der Gegenstand des Disputs.

_genau_ -> Genauigkeit ist der Punkt.

Nein. Es geht um Caching. Und in Folge dessen, ob eine Datei inhaltlich geändert wurde. Inhaltliche Änderungen werden mit dem ETag-Header, so wie ihn Apache generiert - man muß es ja nicht so machen, ich sende z.B. ggf. einen Datenhash (oder einen weniger rechenintensiven Hash) -, nicht erfasst. Der Value des ETags ist ja nicht standardisiert.

Richtig. Der Teufel steckt bekanntlich im Detail.

Wer hilfsweise nur das letzte Modifizierungsdatum als Änderungskriterium werten möchtest (und darauf läuft dein Hinweis, daß dieses Datum, zumindest beim Apache, in den ETag-Content doch mit einfließt ja hinaus), der sollte den Last-Modified-Header einsetzen.

Eine detaillierte Betrachtung der Konfigurationsmöglichkeiten für den "nicht standardisierten" Etag vermag bei Deinem Vorhalt Licht ins Dunkle bringen. Erst ab diesem Punkt hast Du meine Zustimmung.

...und Du willst mir die Dunkelheit lehren? *pff*

Gruß aus Berlin!
eddi

[Cybaer]

Hi,

_genau_ -> Genauigkeit ist der Punkt.

Dann bin ich ja beruhigt! ;)

Richtig. Der Teufel steckt bekanntlich im Detail.

Eben. Und hier sagt der Teufel, daß (beim Apache) selbst dann ein anderer ETag gesendet werden kann, wenn sich nichts am Dateiinhalt geändert hat.

Möchtest Du dem ernsthaft widersprechen?

Ich kann's echt nicht nachvollziehen. =:-o

Eine detaillierte Betrachtung der Konfigurationsmöglichkeiten für den "nicht standardisierten" Etag vermag bei Deinem Vorhalt Licht ins Dunkle bringen. Erst ab diesem Punkt hast Du meine Zustimmung.

Dann habe ich jetzt also deine Zustimmung? :)

Ansonsten: Welcher der Punkte bezieht sich deiner Meinung nach auf den Datei-*Inhalt*? Node-Position, Dateigröße oder Mod-Datum?

Der Rückschluß auf den Inhalt ist IMHO ungefähr so, als wenn Du anhand der Mitteilung einer noch nie gesehenen Brieffreundin, sie hätte Körbchengröße DD, schließt, sie wäre beim Schönheitschirurgen gewesen (kann sein, muß aber nicht). Andererseits nimmst Du an, daß sie nicht dort war, weil sie eine normale Körbchengröße hat, aber von der Nase, die sie sich hat richten lassen, weißt Du nichts. :)

BTW: Ist das gequotete nur als Zitat, oder als Nicht-Zustimmung zu werten?

...und Du willst mir die Dunkelheit lehren? *pff*

Im Zweifel gibt's solange auf die Nuß, bis dir schwarz vor Augen wird. ;->

Gruß, Cybaer

[Edgar Ehritt]

Hallo Cybaer,

Eben. Und hier sagt der Teufel, daß (beim Apache) selbst dann ein anderer ETag gesendet werden kann, wenn sich nichts am Dateiinhalt geändert hat.

na dann lass uns doch mal die Wahrscheinlichkeit genauer betrachten. Wie wahrscheinlich ist es, dass man seine zu servierenden Dateien von Partition zu Partition verschiebt, damit wir über den INode reden müssen? Oder wie sinnvoll mag es sein, in einem Lastenverbund nicht FileEtag MTime [Size] zu konfigurieren?

Es läuft doch nicht jeder auf Windows 95!

Möchtest Du dem ernsthaft widersprechen?

Naja klar doch. Wenn da schon so ein schön großer Haufen Korinthen ist, mache ich devel-like doch auch da mein Geschäft. ^,-
Was war Dir denn nicht genehm an "sehr wahrscheinlich eindeutige Referenz ... bezüglich ihrer inhaltlichen Veränderung", dass es Dich zwar anficht, aber keine genauere Betrachtung daraus wurde?

Dann habe ich jetzt also deine Zustimmung? :)

Hattest Du doch auch schon in "sehr wahrscheinlich eindeutige Referenz ... bezüglich ihrer inhaltlichen Veränderung".

Ansonsten: Welcher der Punkte bezieht sich deiner Meinung nach auf den Datei-*Inhalt*? Node-Position, Dateigröße oder Mod-Datum?

Alle drei; so wie von Dir genannt, haben sie eine aufsteigende Relevanz.

Der Rückschluß auf den Inhalt ist IMHO ungefähr so, als wenn Du anhand der Mitteilung einer noch nie gesehenen Brieffreundin, sie hätte Körbchengröße DD, schließt, sie wäre beim Schönheitschirurgen gewesen (kann sein, muß aber nicht). Andererseits nimmst Du an, daß sie nicht dort war, weil sie eine normale Körbchengröße hat, aber von der Nase, die sie sich hat richten lassen, weißt Du nichts. :)
Im Zweifel gibt's solange auf die Nuß, bis dir schwarz vor Augen wird. ;->

Cybaer, such Dir doch bitte einfach Dein doppelt D woanders als bei mir, ich bin kein Bodybuilder! Ich bin auch nicht interessiert an Ersatzbefriedigungen oder Lückenbüßerei für sexuell - äh - 'nicht hundertprozentig' Ausgelastete.

Gruß aus Berlin!
eddi

[Cybaer]

Hi,

na dann lass uns doch mal die Wahrscheinlichkeit genauer betrachten. Wie wahrscheinlich ist es, dass man seine zu servierenden Dateien von Partition zu Partition verschiebt, damit wir über den INode reden müssen?

IMHO 0%.

Aber ich schrieb ganz zu Anfang ausdrücklich (und bezog damit meine Aussage auch ausdrücklich darauf): "Serverfarm"

"Load Balancing" ist IMHO kein Exotenthema. Und schon beim Load Balancing mit 2 Servern haben beide Dateien auf den beiden (*nix-)Serven unterschiedliche INodes.

Wenn man nun nicht daran denkt (kommt vor!), dann kommt, auch das schrieb ich, bei jedem Request ein anderer ETag, je nachdem, welcher Server den jeweiligen Request zufälligerweise beantwortet.

Und sicher: einem aufmerksamen Webmaster sollte so etwas nicht passieren, aber es passiert halt nunmal. Und ich finde, der Hinweis darauf, nebst der Klarstellung, daß der ETag-Wert standardmäßig beim Apache sich nicht aus dem Dateiinhalt ergibt (dann würde das Problem ja nicht existieren), ist in einem Forum für Webentwickler IMHO nicht verkehrt, oder? =;-)

Was war Dir denn nicht genehm an "sehr wahrscheinlich eindeutige Referenz ... bezüglich ihrer inhaltlichen Veränderung", dass es Dich zwar anficht, aber keine genauere Betrachtung daraus wurde?

Daß das nur bei Single-Servern gilt - und daß da ein falscher Umkehrschluß vorliegt, der irreführend ist.

Beides schrieb ich, und nur darum geht es.

Cybaer, such Dir doch bitte einfach Dein doppelt D woanders als bei mir,

Och, ich steh eher auf deutlich kleinere Größen ... :)

Ich bin auch nicht interessiert an Ersatzbefriedigungen oder Lückenbüßerei für sexuell - äh - 'nicht hundertprozentig' Ausgelastete.

Nicht? Wärst Du trotzdem so freundlich, das Stück Seife aufzuheben, welches mir gerade entglitt? >>;->

Gruß, Cybaer

[Edgar Ehritt]

Re:

na dann mache ich es Dir eben gleich und suche mir nur das raus, was für mcih wichtig ist:

Oder wie sinnvoll mag es sein, in einem Lastenverbund nicht FileEtag MTime [Size] zu konfigurieren?

IMHO 0%.

aha.

Gruß aus Berlin!
eddi

[Cybaer]

Hi,

na dann mache ich es Dir eben gleich und suche mir nur das raus, was für mcih wichtig ist:

Im Unterschied zu dir, habe ich nicht am Thema vorbeigeredet. Wenn Du schon zu Beginn überliest, daß es um Serverfarmen/Load Balancing geht, ist das einzig dein Problem ...

(Und diese freundliche Formulierung ist einzig meiner guten Erziehung geschuldet.)

Gruß, Cybaer

[Edgar Ehritt]

Hallo,

Wenn Du schon zu Beginn überliest, daß es um Serverfarmen/Load Balancing geht, ist das einzig dein Problem ...

Wer seid Beginn nicht mitdenken will, streicht sich auch die Antworten so zusammen, wie er sie braucht.

Nein. Der ETag-Header sagt (zumindest beim Apache) *überhaupt nichts* über Inhalt bzw. Inhaltsveränderung aus!

Rückst Du von diesem Irrglauben nun ab, Häretiker? ^,-

Gruß aus Berlin!
eddi

[Cybaer]

Hi,

Wer seid Beginn nicht mitdenken will, streicht sich auch die Antworten so zusammen, wie er sie braucht.

Du meinst, spätestens wenn man erkannt hat, daß der andere auf dem falschen Gleis ist, soll ihm auf das falsche Gleis folgen? >;->

Nein. Der ETag-Header sagt (zumindest beim Apache) *überhaupt nichts* über Inhalt bzw. Inhaltsveränderung aus!
Rückst Du von diesem Irrglauben nun ab, Häretiker? ^,-

Bist Du irre? Natürlich nicht ... =:->

Es ging mir darum aufzuzeigen, unter welchen Bedingungen deine leichtfertig gemachte Aussage sich in (Un)wohlgefallen auflöst. Solange es diese Bedingungen also gibt ... :)

Es "funzt" heißt halt, daß es *wirklich* "funzt". Und wenn man dann sagt: Obacht, der Anschein trügt, die Wirklichkeit sieht anders aus und deswegen "funzt" das in einem Fall nicht, dann *kann* die Auflösung nicht sein, daß es doch "funzt" ... >;->

So jetzt mal rein meta-physisch, dialektisch, webdesignerisch gesprochen ... ;)

Gruß, Cybaer

[Edgar Ehritt]

Re:

Wer seid Beginn nicht mitdenken will, streicht sich auch die Antworten so zusammen, wie er sie braucht.
Du meinst, spätestens wenn man erkannt hat, daß der andere auf dem falschen Gleis ist, soll ihm auf das falsche Gleis folgen? >;->

Jain. Es kommt doch auch darauf an, was die tatsächliche Intention des Handelns ist. Hinterher schön reden, wenn man auf dem falschen Gleis ist, lernt man mit den Jahren offensichtlich sehr gut.

Nein. Der ETag-Header sagt (zumindest beim Apache) *überhaupt nichts* über Inhalt bzw. Inhaltsveränderung aus!
Rückst Du von diesem Irrglauben nun ab, Häretiker? ^,-
Bist Du irre? Natürlich nicht ... =:->

Dann spiele weiter Scheibe und rede an den Tatsachen, die ich erst benennen musste, vorbei.

Es ging mir darum aufzuzeigen, unter welchen Bedingungen deine leichtfertig gemachte Aussage sich in (Un)wohlgefallen auflöst. Solange es diese Bedingungen also gibt ... :)

Warum hast Du es dann nicht getan? Warum musste ich das tun? Sieht bei Dir Klärung immer so aus, dass man Dir, mit Verlaub, den Arsch abputzen muss?

Ganz oben wurdest Du mit "Und was anderes fällt mir spontan nicht an Deinem Vorhalt ein, weil ich nichts konkretes sehe" aufgefordert, zu demonstrieren, was Du meinst. Es stand Dir offen auf die Konfigurationsvarianten, auf die Du Deine leichtfertige Aussage stützt, aufzuzeigen. Du hast es nicht getan. (Punkt)

Es "funzt" heißt halt, daß es *wirklich* "funzt". Und wenn man dann sagt: Obacht, der Anschein trügt, die Wirklichkeit sieht anders aus und deswegen "funzt" das in einem Fall nicht, dann *kann* die Auflösung nicht sein, daß es doch "funzt" ... >;->

Genauigkeit war Dir nicht gegeben, und lapidar vom default auszugehen, wenn Du über Serverkonfigurationen philosophierst, ist verabsäumtes Mitdenken. Ja, ja, Cybaer, mir mit Standard zu kommen - da such Dir jemand anderen, der eben doppelt D hat!

Warum musste ich aufzeigen, dass es geht? Warum hast Du nicht darauf hingewiesen, dass es, vom default ausgehend, Umgebungen geben kann, die _lediglich eine Anpassung der Konfiguration_ verlangen?

Fakt ist, dass FileEtag alle Möglichkeiten, die von Dir als Hürden benannt wurden, konfigurativ berücksichtigen kann. Jemand, der mitdenkt und die Materie kennt, wird sich von Dir eben wie von einem Webdesigner angequatscht fühlen...
RTFM!

Gruß aus Berlin!
eddi

[Cybaer]

Hi,

Es ging mir darum aufzuzeigen, unter welchen Bedingungen deine leichtfertig gemachte Aussage sich in (Un)wohlgefallen auflöst. Solange es diese Bedingungen also gibt ... :)

Warum hast Du es dann nicht getan?

Habe ich bereits im ersten Posting getan:

"wenn man eine inhaltlich identische Resource über eine Serverfarm ausliefern möchte ... die ETags unterschiedlich ..., (das Caching) davon abhängig, ob der Folgerequest *zufällig* vom selben Server bearbeitet würde, wie der Erstrequest."

Wenn's nicht deutlich genug war, daß es nicht um das Verschieben einer Datei zw. mehreren "Partitionen" eines Rechners ging: Sorry.

Fakt ist, dass FileEtag alle Möglichkeiten, die von Dir als Hürden benannt wurden, konfigurativ berücksichtigen kann.

Und man kann auch auf Last-Modified ausweichen, oder (wenn man den ETag selbst verwaltet) auch mit einem wirklichen Kriterium bezügl. des Inhalts ausstatten. Wurde alles genannt ...

Jemand, der mitdenkt und die Materie kennt, wird sich von Dir eben wie von einem Webdesigner angequatscht fühlen...

Dummerweise kennen (offensichtlich) viele die Materie nicht (und sei es, daß sie was von Inhalt reden, wo indirekte Rückschlüssse gemeint sind), und ja, das ist die Aufgabe des Webdesigners (im Gegensatz z.B. zum Screendesigner), auf so etwas aufmerksam zu machen.

Den mittlerweile unerquicklichen Thread zu benden, ist von meiner Sicht aus eigentlich schon lange überfällig ...

... eigentlich seit dem ersten Posting.

EOT

Gruß, Cybaer

[Edgar Ehritt]

Re:

Keine meiner Fragen beantwortet und vorm Wesenskern außen vor geblieben.

Gruß aus Berlin!
eddi

[Cybaer]

Hi,

Und dass er für diese Resource ein "If-Modified-Since" Header an den Server schickt. Dort möchte ich dann an Hand des Datums entscheiden, ob der Browser ein 304 Status Code (not modified) zurückbekommt, oder eben eine neue Version.

Auch wenn Du schon ene Lösung gefunden hat, sei es mir erlaubt, auf meine Helferfunktionen zu verlinken:
http://Coding.binon.net/Modified

Gruß, Cybaer