[Ben]

Und nochmals, (ich lebe wieder -)
ich habe in einer Datei folgenden Code gefunden:

PHP-Code:

header("Last-Modified: " . gmdate("D, d M Y H:i:s") ." GMT"); 


Diese Datei wird sozusagen als "auto_prepend_file" genutzt und in jede aufrufende Datei eingebunden.

Hier steht: http://www.faqs.org/rfcs/rfc2616

14.29 Last-Modified

The Last-Modified entity-header field indicates the date and time at
which the origin server believes the variant was last modified.

Last-Modified = "Last-Modified" ":" HTTP-date

An example of its use is

Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT

The exact meaning of this header field depends on the implementation
of the origin server and the nature of the original resource. For
files, it may be just the file system last-modified time. For
entities with dynamically included parts, it may be the most recent
of the set of last-modify times for its component parts. For database
gateways, it may be the last-update time stamp of the record. For
virtual objects, it may be the last time the internal state changed.

An origin server MUST NOT send a Last-Modified date which is later
than the server's time of message origination. In such cases, where
the resource's last modification would indicate some time in the
future, the server MUST replace that date with the message
origination date.

An origin server SHOULD obtain the Last-Modified value of the entity
as close as possible to the time that it generates the Date value of
its response. This allows a recipient to make an accurate assessment
of the entity's modification time, especially if the entity changes
near the time that the response is generated.

HTTP/1.1 servers SHOULD send Last-Modified whenever feasible.

Der vorletzte Absatz ist mir nicht klar.

This allows a recipient to make an accurate assessment
of the entity's modification time, especially if the entity changes
near the time that the response is generated.

Jau, und?

Warum genau soll dieser header gesendet werden?
Danke für die Erklärung.

Grüße, Ben.

[MrNiceGuy]

Die Verwendung ist sehr sinnvoll und auch einigermaßen einfach: Man nehme an, du hast ein Script, das Bilder generiert für eine Gallery oder sonstiges (Wasserzeichen, was auch immer). Dann hast du z.B. das Datum der letzten Änderung der Datei, die aus der Datei selber ersichtlich ist. Wenn du diese als LAST-MODIFIED mitschickst, bekommst du bei der nächsten Anfrage dieses Datum mit dem Request an den Server geschickt, kannst es auslesen und mit dem Datum der ursprünglichen Datei vergleichen. Stimmt es überein, reicht es in dem Falle einen HTTP-Status-Code 304 Not Modified zu schicken und danch die Berechnung der Seite abzubrechen. Es wird dann die Grafik aus dem Cache des Browsers genommen. Diese Art des Cachings kann man auch auf andere Bereiche übertragen (Letzte Änderung im Forum, Gästebuch, etc.). Es spart eine Menge Traffic, wenn sich der Inhalt einer Seite seltener ändern sollte.

Ob es immer in der Praxis so gut funktioniert, wie es die Theorie vorgibt, kann ich nicht sagen, ich weiß nur, dass es bei mir bisher immer sehr gut funktioniert hat.

[Ben]

Ah, gute Erklärung. Danke.

Habe diese Codezeile tatsächlich in einer sehr, sehr, sehr, sehr häufig aufgerufenen Datei gefunden. Das erklärt dann Vieles.

Hat jemand eventuell eine Art "Tutorial" oder so zur effektiven und optimierten Verwendung solcher Header? Interessantes Thema.

Danke im Voraus. Grüße, Ben.

[Byrel]

Ich verwende es in einigen PHP Websites damit eben nicht immer alles neu gesendet werden muss.
Du findest das Last-Modified Datum im IF-MODIFIED-SINCE Header, weshalb du das einfach überprüfen kannst

Nützlich sind auch noch ETag, Expires, Content-Encoding etc.

Btw: Es reicht auch

PHP-Code:

header ("Last-Modified: " . date (DATE_RFC822)); 


MfG Byrel

[MrNiceGuy]

Ganz grob sollte vielleicht folgender Beispielcode helfen!?

PHP-Code:

<?php

$arrayMonth = array ('Jan' => 1,
                     'Feb' => 2,
                     'Mar' => 3,
                     'Apr' => 4,
                     'May' => 5,
                     'Jun' => 6,
                     'Jul' => 7,
                     'Aug' => 8,
                     'Sep' => 9,
                     'Oct' => 10,
                     'Nov' => 11,
                     'Dec' => 12
                     );

$arrayResponseHeader = apache_request_headers ();

$integerFileTime = filecdate ('pfad/zur/dat.ei');

if (array_key_exists ('If-Modified-Since', $arrayResponseHeader) === TRUE)
{
  $arrayTime = preg_split ('°[\s,\:]{1,}°i', $arrayResponseHeader['If-Modified-Since']);
  
  $integerDay = $arrayTime[1];
  $integerMonth = $arrayMonth[$arrayTime[2]];
  $integerYear = $arrayTime[3];
  $integerHour = $arrayTime[4];
  $integerMinute = $arrayTime[5];
  $integerSecond = $arrayTime[6];
  
  $integerTime = mktime ($integerHour, $integerMinute, $integerSecond, $integerMonth, $integerDay, $integerYear);
  
  if ($integerFileTime == $integerTime)
  {
    header ('HTTP/1.1 304 Not Modified');
    exit;
  }
}

header ('Last-Modified: '.gmdate ('D, d M Y H:i:s', $integerFileTime));

// Bild bearbeiten und ausgeben...

?>

[Ben]

Hallo,
interessant. Danke.

Du meinst aber wohl eher filectime, oder? filecdate gibbet nämlich nicht.

Also, es geht dabei nicht unbedingt um Bilder, sondern um ganz normalen Content. Ist das darauf auch anzuwenden?
Sorry, wenn ich mich etwas dumm anstelle .

Grüße, Ben.

[robo47]

Zitat von Ben

Hallo,
interessant. Danke.

Du meinst aber wohl eher filectime, oder? filecdate gibbet nämlich nicht.

Also, es geht dabei nicht unbedingt um Bilder, sondern um ganz normalen Content. Ist das darauf auch anzuwenden?
Sorry, wenn ich mich etwas dumm anstelle .

Grüße, Ben.

auch wenn der html-kram oftmals kleiner ist als die ganzen bilder, klar ist es auch hier sinnvoll, spart dir ja traffic

[Ben]

Nun, es ist ja so. Direkt wird man das kaum anwenden können, denke ich mal, weil der Inhalt ja nicht fix auf einer .html-Seite oder so steht, sondern aus einer Datenbank und via Templateengine ausgegeben wird.

Das heißt, dass ich ja nicht wirklich eine Datei habe, deren letzte Aktualisierung ich testen kann.
Ich wollte eher erfragen, ob es so etwas "in der Art" auch für normalen Content gibt.

Klar, was ich meine?

[robo47]

du musst nur in der Datenbank speichern wann die jeweilige Seite das letzte mal geändert wurde und den wert nutzen anstatt der abfrage wann die datei das lette mal verändert wurde.

Ich wollte eher erfragen, ob es so etwas "in der Art" auch für normalen Content gibt.

Klar, was ich meine?

nicht so ganz

[Ben]

Zitat von robo47

du musst nur in der Datenbank speichern wann die jeweilige Seite das letzte mal geändert wurde und den wert nutzen anstatt der abfrage wann die datei das lette mal verändert wurde.

Jau, aber das ist dann ja wieder irgendwie .. hmm, das sind ja dann im Ernstfall zwei Abfragen anstatt einer. Allerdings sollte das in Seitenbereichen, die nicht so häufig aktualisiert werden dann trotzdem positiv ausfallen, also eine Erleichterung bringen, ne?

Frage ist nur, wo jetzt der Unterschied zu einem "normalen" Cache, sei es selbst implementiert, aus einem Framework oder oder oder .. ist.

Grüße, Ben.

[robo47]

Zitat von Ben

hmm, das sind ja dann im Ernstfall zwei Abfragen anstatt einer. Allerdings sollte das in Seitenbereichen, die nicht so häufig aktualisiert werden dann trotzdem positiv ausfallen, also eine Erleichterung bringen, ne?

du holst doch irgendwo eh die Daten aus der Datenbank ab, imho kein 2tes Query, sondern viel mehr nur 1 Feld mehr das du abholen musst.

Frage ist nur, wo jetzt der Unterschied zu einem "normalen" Cache, sei es selbst implementiert, aus einem Framework oder oder oder .. ist.

Grüße, Ben.

Der Unterschied liegt darin, dass es erstmal kein Cache ist, sondern noch vor dem Cache sitzt und einen Client der eine saubere Anfrage sendet sagt, dass die Daten noch die gleichen wie bei der letzten Anfrage sind und somit nichtmal den Cache des Systems bemühen muss, sondern der Browser den Browsercache bemüht, somit spart es 2 Sachen, CPU-Last + Traffic, während der Cache erstmal nur CPU-Last spart.

mfg
robo47

[Ben]

Zitat von robo47

Der Unterschied liegt darin, dass es erstmal kein Cache ist, sondern noch vor dem Cache sitzt und einen Client der eine saubere Anfrage sendet sagt, dass die Daten noch die gleichen wie bei der letzten Anfrage sind und somit nichtmal den Cache des Systems bemühen muss, sondern der Browser den Browsercache bemüht, somit spart es 2 Sachen, CPU-Last + Traffic, während der Cache erstmal nur CPU-Last spart.

Okay. Klingt verständlich. Muss ich nochmal drüber nachdenken, aber das wird.

Zitat von robo47

du holst doch irgendwo eh die Daten aus der Datenbank ab, imho kein 2tes Query, sondern viel mehr nur 1 Feld mehr das du abholen musst.

Das wiederum verstehe ich nicht. ... ich komm mir so vor, als ob ich es eigentlich verstehen müsste, aber ich tus nicht. *g*

Ganz abgesehen davon, dass ich die Daten eh irgendwo herbekommen muss .. warum sollte ich abfragen, ob die Daten aktualisiert wurden, wenn ich eh die Daten so auslese, als ob sie aktualsiert worden wären?

Bin verwirrt.

[robo47]

Zitat von Ben

Das wiederum verstehe ich nicht. ... ich komm mir so vor, als ob ich es eigentlich verstehen müsste, aber ich tus nicht. *g*

Ganz abgesehen davon, dass ich die Daten eh irgendwo herbekommen muss .. warum sollte ich abfragen, ob die Daten aktualisiert wurden, wenn ich eh die Daten so auslese, als ob sie aktualsiert worden wären?

Bin verwirrt.

Naja, das ganze lässt sich ja über SQL sicher verbinden mit einer art IF:

Angenommen es kommt eine Anfrage mit dem passenden Header (modified since 1.1.2005) dann machst du ein Query in der form (ist jetzt leider zum Teil Pseudocode, weil ich nicht genau auf Anhieb weis wie man das mit dem IF in SQL umsetzt)

IF feld_last_modified "älter" als 1.1.2005
SELECT *,'TRUE' AS MODIFIED FROM daten
ELSE
SELECT 'FALSE' AS MODIFIED

Ansonsten ruft man die Daten einfach IMMER ab, hat so also ein großes Query mit den Daten und spart sich dann wenn das last-modified Feld einen passenden Wert hat, das parsen (template+content) und sendet nur den header, dass sich die seite nicht geändert hat.

mfg
robo47

[MrNiceGuy]

Zitat von Ben

Hallo,
interessant. Danke.

Du meinst aber wohl eher filectime, oder? filecdate gibbet nämlich nicht.

Also, es geht dabei nicht unbedingt um Bilder, sondern um ganz normalen Content. Ist das darauf auch anzuwenden?
Sorry, wenn ich mich etwas dumm anstelle .

Grüße, Ben.

Ja, sorry, hatte das ausm Kopf geschrieben und dann wohl den falschen Funktions-Namen genutzt, natürlich soll es filectime sein nicht filecdate

Du kannst es auch auf andere Dinge anwenden, du musst das "Problem" nur portieren. Anstatt filectime zur Ausfindigmachung der letzten Änderung nimmst du in einem Gästebuch zum Beispiel den aktuellsten Timestamp aus der Datenbank. Funktioniert genauso. Man kann damit Foren, Threads, Postfächer, einfach alles so programmieren, dass man nurnoch ein Minimum an Berechnung braucht. Allerdings nur, wenn sich nicht jede Sekunde in den entsprechenden Bereichen eh etwas ändert, ist ja klar, oder?

Auch im Bezug auf AJAX ist es sehr interessant, dass man die Inhalte einzelner Abfragen im JavaScript zwischenspeichern kann und bei einer Rückantwort von 304 eben diese nutzt und anderenfalls bei 200 diese überschreibt. Es ist also multifunktional

@robo: Ansich funktioniert es genau so. Da man aber unterscheiden kann, ob ein Modified-Header geschickt wurde oder nicht, macht es weniger Sinn in meinen Augen. Ich würde einfach für den Fall, dass der Client einen If-Modified-Since-Header schickt iene zusätzliche Abfrage machen, die nur das aktuellste Datum aus der DB zieht und dieses dann vergleichen. Dank der Datum-/Zeitfunktionen in MySQL kann ich ja bekanntlich aus einem DATETIME-Feld auch gleich den Timestamp zurückgeben lassen. Sollte sich etwas geändert haben, wird dann zwar eine DB-Abfrage mehr gemacht, als sonst, aber im Umkehrschluss erspare ich mir vielleicht 2, 3 oder noch mehr Abfragen, wenn sich eben NICHTS geändert hat.