nicht angemeldet
Re:
ETag dient wohl mehr dazu, mehrere Entitäten, also Ausprägungen o.ä., einer Ressource zu unterscheiden.
Gut - dann kannst du mir vielleicht erklären, was das bedeutet, was ich da schrieb? :-)
Die PHP-Funktion stat() liefert eine Reihe von "Ausprägungen" eines Files:
Ausgabe stat() Erklärung FileETage-Direktive (apache)
[dev] => 772 -> Laufwerk
[ino] => 13065 -> inode -> INode
[mode] => 33188 -> inode protection mode
[nlink] => 1 -> Anzahl der Links
[uid] => 1000 -> Benutzer ID des Inhabers
[gid] => 100 -> Gruppen ID des Inhabers
[rdev] => 0 -> Laufwerkstyp wenn Inode-Laufwerk *
[size] => 478 -> Größe in Bytes -> Size
[atime] => 1138881639 -> Zeitpunkt des letzten Zugriffs
[mtime] => 1144313089 -> Zeitpunkt der letzten Modifizierung -> MTime
[ctime] => 1144313089 -> Zeitpunkt der letzten Änderung
[blksize] => 131072 -> k. A.
[blocks] => 8 -> Blockgröße für das Dateisystem I/O *
Mir selber Schnitzel ans Knie zu nageln, halte ich für ein wenig erfüllendes Verhalten ...
Gut und schön, aber ich habe doch auch schon genug am eigenen Knie (und seit dem Schatz auf ist zusätzlich noch eine Frikadelle am Ohr ;(
Dein Beispiel sehe ich also eher als theoretisches an - du hast zwar recht damit, aber es erscheint mir doch arg praxisfern.
Ein Szenario sind Archive (tar/zip/rar): Man erstellt sich an seiner Testumgeben ein neues Projekt, verpackt es, läd es auf den Server hoch und entpackt es über das bestehende alte. Dabei hat man aber vergessen dem entpackendem Progamm mitzuteilen, alle Files mit aktuellem timespamp zu erzeugen. Pech nur dann, wenn bestehende Files mit Files im Archiv selbe mtimes aufweisen...
Ich weiß, auch das ist konstruiert.
Das mag auf dein konstruiertes Beispiel zutreffen.
Wenn ich aber bei dynamisch erstelltem Content anhand des Änderungsdatums die Entscheidung treffen möchte, ob ich mit 304 oder 200 und erneuter Auslieferung der Ressource antworte, sehe ich im ETag keinen Vorteil gegenüber dem Last-Modified.
Vielleicht können wir uns darauf einigen, daß ETag einer möglichen Softwarekonfiguration "paranoid" entspricht.
So z. B. FF und Moz während Opera, IE und links hier weder "If-Modified-Since" oder "If-None-Match" senden.
Tun sie nicht?
Hrmpf, dann kann man sich den Aufwand ja fast sparen ...
Nicht mal Opera unterstützt Conditional Get in dieser Hinsicht?
Daß der IE hier mal wieder die Füße hochlegt, statt zu arbeiten, war zu erwarten. Auch von links als Textbrowser kann man sowas nicht wirklich erwarten. Aber das Dein heißgeliebter Opera sich hier auch eine Pause gönnt, hat mich selbst überrascht.
Da dynamisch generierte Dokumnente mit unterschiedlichen Parametern arbeiten ($_GET,$_POST, etc.) und demzufolge auch unterschiedliche Ausgaben erzeugen, wird es auf ein Ausgabepufferung hinauslaufen müssen.
Ein dynamisch generiertes Dokument kann ja bspw. auch ein RSS-Feed oder eine Weblog-Seite sein.
Deren Inhalt ändert sich nur, wenn ein neuer Eintrag oder Kommentar hinzugekommen ist.
Dies kann ich am Scriptanfang aus meiner Datenbank ermitteln - und könnte mit 304 antworten, und mir so den Traffic für das erneute Ausliefern der Daten sparen.
Da ist bei mir eine Bildungslücke. Beispiel:
http://ich.will.net/ja.php?sag=nein
http://ich.will.net/ja.php?sag=immernoch+nein
http://ich.will.net/ja.php?sag=vielleicht
Gehen Browser davon aus, daß es sich um die Resource "ja.php" hantelt, oder ist ihnen schon klar, daß hier die Resourcen "ja.php?sag=nein", "ja.php?sag=immernoch+nein" und "ja.php?sag=vielleicht" vorliegen. (Erster Fall wäre eine Katastrophe und zumindes für Moz gilt Fall zwei.)
Gruß aus Berlin!
eddi
Der Martin