hi,
Wo bzw. wie kann ich am einfachsten die HTTP-Header auslesen, die unsere Schulhomepage ausgibt? Lohnt sich da der Einsatz eines eigenen Programms, oder kann ich das auf einer dafür ausgelegten Website testen?
Im Firefox sind dafür Extensions wie die Web Developer Toolbar (die dürfte doch bei einem Webseitenersteller vermutlich eh zum Standard-Arbeitswerkzeug gehören?) sehr nützlich - da findest du das unter "Information" -> "View Response Headers".
Und wenn ich gerade keinen Browser zur Verfügung habe, der mir diese Information anzeigen mag, dann nutze ich dafür den Web Sniffer - oder andere ähnliche Tools, wie auch bspw. HTTP trace, und im self-Umfeld gab's sowas glaube ich auch noch irgendwo, finde ich aber gerade nicht.
Muss ich vielleicht mal ansehen, aber ich habe mich bisher gegen ein RSS-Feed für unsere Schulwebsite entschieden.
Wie gesagt, war nur als Beispiel gedacht, und ist ja nicht auf RSS beschränkt, sondern erklärt das Thema eigentlich generell für HTTP-Ressourcen, egal ob nun RSS oder HTML-Dokument.
Das E-Tag habe ich in seiner Bedeutung nicht verstanden, da mir die Erläuterungen in den Specs zu unverständlich waren.
Ich muss gestehen, ich auch nicht :-)
ETag dient wohl mehr dazu, mehrere Entitäten, also Ausprägungen o.ä., einer Ressource zu unterscheiden.
Das _kann_ wohl auch zur Bewertung der Aktualität der Ressource bzgl. des aktuellen Timestamps dienen, wie im vorliegenden Falle, wenn man eigentlich eine 304 Not Modified-Antwort umsetzen will - es gibt aber wohl noch andere Einsatzgebiete.
Manche Clients benutzen den Last-Modified-Header, um darauf hin bei der erneuten Anfrage ein If-Modified-Since zu generieren, um zu erfragen, ob sich die Ressource inzwischen gegenüber der gechachten Version verändert hat - manche Clients aber wohl auch den ETag.
Da wollte ich eigentlich bei Gelegenheit noch mal im Forum nachfragen, wie das mit dem ETag im speziellen aussieht - und ob man ihn implementieren sollte für so eine 304-Sache.
Bei meinen Tests funktionierte es bei allen Clients mit dem Last-Modified/If-Modified-Since-Gespan - ETag ebenfalls zu implementieren, kann man sich da also u.U. sparen.
Diese Abschnitte hatte ich verstanden und Last-Modified davon umgesetzt. Bei If-Modified-Since und ETag ist mir nicht klar geworden, wofür ich die genau einsetzen sollte, bzw. welche Information ich mit diesen Headern schicken müsste.
Last-Modified generierst du beim Ausliefern der Ressource als Response-Header, und If-Modified-Since liefert dir der Client bei einer erneuten Anfrage im Request, wenn er sich erkundigen will, ob er seine gechachte Version weiterhin verwenden, oder die Ressource erneut abrufen soll.
Hat sich die Ressource zwischenzeitlich - was du anhand der als "Wert" des Request-Headers übermittelten Datumsangabe entscheidest - nicht geändert, antwortest du nur mit einem 304-Header (ohne einen "Body")- andernfalls lieferst du die Ressource wie gewohnt unter einem (üblicherweise) 200-Header aus.
Will sich der Client damit nicht zufriedengeben, dass du ihm gesagt hast, es habe sich nichts geändert, und er will wirklich die Ressource erneut anfordern, egal ob sie sich mit der Version in seinem Cache deckt - dann wird er eine erneute Anfrage ohne If-Modified-Since stellen - die du dann ganz normal mit Auslieferung der Ressource beantwortest.
Und ETag, siehe oben - braucht man dafür nach meinem bisherigen Kenntnisstand nicht.
Kann auch sein, dass das ein Thema bzgl. der Unterschiede zwischen HTTP/1.0 und HTTP/1.1 ist - wie gesagt, vollkommen durchschaut habe ich den Einsatzzweck von ETag auch noch nicht.
Aber eigentlich ist es wirklich recht simpel.
Mit dem "eigentlich" gebe ich Dir absolut Recht. Nur im Detail kann es für Unerfahrene etwas komplex erscheinen, oder gar unverständlich klingen.
Sicher - aber sich damit zu beschäftigen, macht ja auch Spaß, oder?
gruß,
wahsaga
--
/voodoo.css:
#GeorgeWBush { position:absolute; bottom:-6ft; }
Felix Riesterer
Der Martin
