ETag

joerg schrieb:

@flo Du forderst ja einen richtig! Aber sehr gut ich glaube danach kann ich noch mehr verbessern!

Da hast du Recht, Jörg! Zwei dicke rote Minus-Zeichen in Flo´s Tool gehen einfach nicht!!!
Mein Provider supported mod_expires nicht, also habe ich es in TypoScript versucht.
Mein Header sieht nun so aus:
HTTP/1.1 200 OK
Date: Tue, 16 Mar 2010 21:12:41 GMT
Server: Apache/2.2
Last-Modified: Mon, 15 Mar 2010 21:37:36 GMT
ETag: "60435d6-2f75-b0836800"
Accept-Ranges: bytes
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 4028
Content-Type: text/html
Trotzdem komme ich auf keinen grünen Zweig (Haken)!
Das ETag ist immer gleich und Last-Modified liegt auch länger zurück. Reicht das nicht?

So, ich hab noch einen Artikel zu der ganzen Geschichte geschrieben:

floern.com/blog/teile-der-website-cachen-lassen

Raptor schrieb:

Dein ETag und Last-Modified ist nicht funktionsfähig. Es reicht nicht einfach den Header zu setzen.

Hilf mir auf die Sprünge. Du hast geschrieben:
"Die HTTP-Header "Last-Modified" und "ETag" ermöglichen dem Client, den Server anzufragen, ob die Ressource seit dem letzten Besuch geändert worden ist, wodurch die Ressource nur dann heruntergeladen wird, wenn sie zwischenzeitlich geändert wurde."
Deinen aktuellen Blog habe ich auch gelesen und bin nicht auf die Ursache meines Fehlers gestoßen.
Sehe ich den Wald vor lauter Bäumen nicht?

Eigentlich ist das Prinzip recht einfach:

1. Der Client ladet wie normal die Datei herunter. Im Header dieser Datei steht der ETag: "a429e02-5bd3-dc894". Soweit so gut wie auch simpel.
2. Der Client braucht die Datei erneut: Er sendet wie zuvor eine Anfrage an den Server, aber noch mit folgendem Request-Header: If-None-Match: "a429e02-5bd3-dc894".
3. Der Server prüft, ob der ETag noch aktuell ist bzw. ob es noch derselbe ist.
4.a. Wenn der ETag nicht mehr derselbe ist, wird die Datei wie normal an den Client gesendet (siehe Punkt 1).
4.b. Wenn der ETag übereinstimmt, wird die Datei nicht an den Client gesendet, stattdessen schickt er den Status-Code "304 Not Modified" zurück, was dem Client signalisiert, dass er die Datei aus dem Cache nehmen muss.

Punkt 1 zu erfüllen ist recht einfach (eine PHP-Zeile).
Punkt 2 hat nichts mit dem Server zu tun.
Punkt 3 ist der entscheidende. Und hier scheitert\'s wohl.

Hallo

@ Lutz

Der Etag wird automatisch in der Regel ermittelt und nicht vorgegeben! So habe ich das nun verstanden!

In PHP Dateien müsste es ausreichen das hier einzubauen!
header(\'ETag: "\'.md5($content).\'"\');

Zumindest fünktionierte dieses bei meiner Domain http://joerghuelsermann.de/ vorhin bevor Florian Hand daran gelegt hatte!

Mit dem Last Modified muss ich erst mal in PHP Dateien noch einen Weg finden!

Was den Provider anbetrifft dann kann man nur zu einem Wechsel raten! Mein neuer ist besser und billiger als mein alter! Neben voller Gzip Unterstützung habe ich jetzt drei name Server!

@florian warum reicht es nicht den Header zu setzen?
Dann dein Link zum Get header in der Erklärung zu falsch!
Im Getheader wird mein Etag der PHP Datei erkannt und nicht als falsch angegeben!

Warum YSlow mir vorhin die Etags erst als falsch konfiguriert angeben hat für meine Dateien und nun als korrekt ausgibt kann ich nicht ganz nachvollziehen.

Kann in meinem Fall aber auch mit dem Providerwechsel zusammenhängen.
Zumindest scheint die Angelegenheit sehr komplex zu sein!
(url]http://developer.yahoo.com/performance/rules.html#etags[/url]

Gruß
Jörg

joerg schrieb:

@florian warum reicht es nicht den Header zu setzen?

Weil Punkt 3 nicht durchgeführt wird.
Wie man das mit PHP macht ist hier beschrieben:

floern.com/webscripting/if-modified-since-nachbauen

joerg schrieb:

Im Getheader wird mein Etag der PHP Datei erkannt und nicht als falsch angegeben!

Wenn du den Header "ETag" definierst, wird er auch angezeigt.
Aber kopiere mal den Inhalt des ETags in das Feld "If-None-Match" und frage damit die Seite nochmal ab.
Wenn dann der HTTP-Statuscode "304 Not Modified" zurückkommt, ist der ETag funktionsfähig, wenn nicht, hat der ETag zufälligerweise gerade gewechselt oder er ist einfach nutzlos.

UFOMelkor schrieb:

Welchen Vorteil habe ich dadurch, all\' diese Header zu senden?

Wenn alles korrekt ist: weniger Traffic.
Wobei, alle müssen es ja nicht sein, einen Teil reicht im Grunde auch schon.

Hallo Oskar

Deine Benutzer werden es dir danken weil die meisten Daten dann gecacht werden!

Last Modified und Etag unterstützt mein neuer Provider sowieso schon!

Das macht der auch nicht ohne Grund weil so Traffic gespart wird!

Eine Gzip Unterstützung wird ein guter Provider auch bei kleineren Paketen erlauben um seine Kosten zu minimieren!

Gruß
Jörg

Das es ums Cachen geht war mir schon klar
Aber im Grunde bewirkt ja jede der vier Methoden auf ihre Art und Weise, dass die Daten gecached werden.
Wenn ich das richtig sehe, dann hat man bei dem LastModified und dem ETag Header den Vorteil, dass die Dateien neu verschickt werden, wenn ich sie auf dem Server ändere. Um das selbe beim expires und max-age Header zu erreichen, müsste ich die Namen der Dateien ändern (Versionierung).

Das heißt aber auch, dass ich theoretisch immer nur eine der angegebenen Methoden benötige, oder sehe ich das falsch? Bei Steve Souders "High Performance Websites" finde ich nur bezüglich ETag und LastModified einen Hinweis:

Der If-None_Match-Header hat Vorrang vor If-Modified-Since. Sie könnten hoffen, dass wenn die ETags nicht übereinstimmen, dafür aber das Last-Modified-Datum, eine "304 Not-Modified"-Response gesendet wird aber das ist nicht der Fall. Entsprechen der HTTP/1.1-Spezifikation darf der ursprüngliche Server "KEINEN 304 (Not Modified)-Status zurückgeben, solange das nicht mit allen bedingten header-Feldern im Request übereinstimmt."

Daher scheint mir das Thema doch etwas komplexer, als schlicht und einfach alle Caching-Methoden zu aktivieren, oder liege ich jetzt ganz falsch?

Edit sagt: Ich habe die ETags mit "FileETag MTime Size" konfiguriert, alternativ habe ich auch schon "FileETag All" probiert, trotz alledem zeigt YSLOW! mir dennoch falsch konfigurierte ETags an.

UFOMelkor schrieb:
Um das selbe beim expires und max-age Header zu erreichen, müsste ich die Namen der Dateien ändern (Versionierung).

Nein, müsstest du nicht. Die Felder expires und max-age sind für die Gültigkeitsdauer eines Elements im Cache zuständig.
Der Unterschied zwischen den beiden ist die Angabe der Gültigkeitsdauer. Expires setzt einen absoluten Wert, als UTC-Datum, ab dem das Element ungültig wird.
Max-Age gibt einen relativen Wert der Gültigkeit, ab dem übertragenen Datum, an.
Sollten beide Werte vorhanden sein, wird expires vorgezogen, da expires der restrikitivere Wert mit einem absolutem Ablaufdatum ist. Ein Element kann auch ungültig werden, wenn es nicht geändert wurde.

UFOMelkor schrieb:
<snip> ...YSLOW! mir dennoch falsch konfigurierte ETags an.

Ich kenne YSLOW nicht, da ich keinen FF verwende.
Veileicht prüfst du die Ausgabe des unter ETag ausgegebenen Wertes dahingehend, als dass er in Anführungszeichen gesetzt sein muss. Das Format des ETag spielt dabei keine Rolle. Es kann sowohl ein Guid-Format als auch ein sogenannter Tick-Wert, eine Ganzzahl, sein. Entscheidend ist nur die mögliche Eindeutigkeit des Wertes.

BTW. Kann alles in der RFC zu HTTP/1.1 Header Field Definitions auf W3.org nachgelesen werden.

Servus,
Klaus

klaus_b@.NET über alles was an .NET und C# Spass macht.

klaus_b schrieb:
Nein, müsstest du nicht. Die Felder expires und max-age sind für die Gültigkeitsdauer eines Elements im Cache zuständig.

Sind sie, ja. Möchte ich allerdings aus irgendeinem Grund auf ETags und Last Modified Headers verzichten und dem User trotzdem nur bei Änderungen eine aktuelle Datei geben, gibt es die Möglichkeit die Version der Datei in den Dateinamen mit aufzunehmen. Ändert man die Datei, dann ändert man auch den Dateinamen und der Benutzer holt sich die Datei automatisch neu vom Server.
Bei Yahoo lässt sich dieses Verfahren zum Beispiel sehen.

Ich trau dem ganzen allerdings nicht ganz, da sind mit zu viele Fehler auf Seiten des Webmasters möglich und ich kenne mich gut genug um zu wissen, dass ich das Ändern der Version bestimmt mal vergessen würde.

klaus_b schrieb:
Sollten beide Werte vorhanden sein, wird expires vorgezogen, da expires der restrikitivere Wert mit einem absolutem Ablaufdatum ist.

Der Gegenteil ist der Fall, max-age wird vorgezogen, da es sich bei max-age um einen relativen Wert handelt, bei Expires um einen absoluten Wert, der bei unterschiedlicher Client- und Serverzeit zu Problemen führen kann.

Der einzige Grund, den Expires-Header noch zu setzen, scheinen die nicht HTTP 1.1 fähigen Clients zu sein. Viele gibt es davon wahrscheinlich nicht mehr, aber da es keine Arbeit macht, den Expires-Header zu setzen, schadet es ja nicht.

klaus_b schrieb:
Ich kenne YSLOW nicht, da ich keinen FF verwende.

Zum Browsen verwende ich persönlich auch lieber Opera, aber zum Testen von Webseiten gibt es IMHO nichts, was an den Firefox mit Addons heranreicht, auch wenn die anderen Browser mit Developer-Tools nachgelegt haben.

klaus_b schrieb:
Vielleicht prüfst du die Ausgabe des unter ETag ausgegebenen Wertes dahingehend, als dass er in Anführungszeichen gesetzt sein muss. Das Format des ETag spielt dabei keine Rolle.

Daran scheint es nicht zu liegen, das sieht korrekt aus:

Etag: "882ac6-10be-47fccfcab8e00"

Ich werde mich wohl hinsichtlich ETags und Last Modified noch etwas schlau machen müssen