Opened by rosti at 2011-03-30 15:14
User since
2011-03-19
3520 Artikel
BenutzerIn
![[Homepage]](/battie/theme/default/homepage.gif)
2011-03-19
3520 Artikel
BenutzerIn
Moin;
es ist richtig, derzeit werte ich IF_MODIFIED_SINCE im Script nicht aus, sondern setze nur den LAST_MODIFIED in die Response. Das ist mir möglich, weil im CMS auch die "mtime" hinterlegt ist und {lastmod} eines der Attribute für die auszugebende Ressource ist.
Möglich wäre auch, einen ETag zu generieren, tatsächlich empfehlen Suchmaschinenbetreiber jedoch, Lastmod zu verwenden.
Sofern der Webserver entsprechend konfiguriert ist, vergleicht er IF_MODIFIED_SINCE (Request) mt LAST_MODIFIED was er vom CGI bekommt, sendet bei Übereinstimmung einen 304 und schließt die Verbindung. Da hatte ich gestern einen Denkfehler, es ist klar, dass der Webserver das CGI startet, ansonsten hätte er keinen Vergleich (danke Bianca).
Mit Cookies hat das alles nichts zu tun, aber es macht keinen Sinn, etwa einen Hinweis "Bitte Cookie annehmen" in eine Seite einzubauen, die mit einem LastMod ausgeliefert wird, denn die nimmt der Browser in den Cache und cacht auch den Hinweis, obwohl der Browser den Cookie angenommen hat.
Fazit: Den Request-Header IF_MODIFIED_SINCE im CGI auswerten zu müssen, hängt von der Konfiguration des Webservers ab, also ob der Server die Zeiten vergleicht und sich um den 304 kümmert, oder das im CGI programmiert werden muss. Allein aufgrund dieser Abhängigkeit ist es gut, den IF_MODIFIED_SINCE auch im CGI auszuwerten, im CGI einen 304 zu senden und die weitere Auslieferung von Content zu stoppen.
Die Frage habe ich so noch nicht gestellt. Da wäre zunächst zu klären, ob der Webserver zuerst den Cookie sendet und danach den 304 oder umgekehrt. Im ersten Fall vermute ich, dass der Browser den Cookie annimmt, im Zweiten nicht. AAAberrrrrr:
Edit: Quatsch, der Status kommt _immer_ zuerst :)
Sofern diese Frage wirklich akut werden sollte, würde ich das mal testen und unbedingt in die RFCs schauen, was dazu steht. Wenn es nicht gerade ein Non-parsed-Header-Script ist, was das CGI sendet, bestimmt der Webserver die Reihenfolge der Response-Header.
Bis dann ;)
Rolf
Edit: Test, Annahme Cookie bei 304, gesendet wird er und FF speichert ihn.
Last edited: 2011-03-31 09:14:10 +0200 (CEST)
es ist richtig, derzeit werte ich IF_MODIFIED_SINCE im Script nicht aus, sondern setze nur den LAST_MODIFIED in die Response. Das ist mir möglich, weil im CMS auch die "mtime" hinterlegt ist und {lastmod} eines der Attribute für die auszugebende Ressource ist.
Möglich wäre auch, einen ETag zu generieren, tatsächlich empfehlen Suchmaschinenbetreiber jedoch, Lastmod zu verwenden.
Sofern der Webserver entsprechend konfiguriert ist, vergleicht er IF_MODIFIED_SINCE (Request) mt LAST_MODIFIED was er vom CGI bekommt, sendet bei Übereinstimmung einen 304 und schließt die Verbindung. Da hatte ich gestern einen Denkfehler, es ist klar, dass der Webserver das CGI startet, ansonsten hätte er keinen Vergleich (danke Bianca).
Mit Cookies hat das alles nichts zu tun, aber es macht keinen Sinn, etwa einen Hinweis "Bitte Cookie annehmen" in eine Seite einzubauen, die mit einem LastMod ausgeliefert wird, denn die nimmt der Browser in den Cache und cacht auch den Hinweis, obwohl der Browser den Cookie angenommen hat.
Fazit: Den Request-Header IF_MODIFIED_SINCE im CGI auswerten zu müssen, hängt von der Konfiguration des Webservers ab, also ob der Server die Zeiten vergleicht und sich um den 304 kümmert, oder das im CGI programmiert werden muss. Allein aufgrund dieser Abhängigkeit ist es gut, den IF_MODIFIED_SINCE auch im CGI auszuwerten, im CGI einen 304 zu senden und die weitere Auslieferung von Content zu stoppen.
Quote..ob ein Cookie bei einem 304 genommen wird.
Die Frage habe ich so noch nicht gestellt. Da wäre zunächst zu klären, ob der Webserver zuerst den Cookie sendet und danach den 304 oder umgekehrt. Im ersten Fall vermute ich, dass der Browser den Cookie annimmt, im Zweiten nicht. AAAberrrrrr:
Edit: Quatsch, der Status kommt _immer_ zuerst :)
Sofern diese Frage wirklich akut werden sollte, würde ich das mal testen und unbedingt in die RFCs schauen, was dazu steht. Wenn es nicht gerade ein Non-parsed-Header-Script ist, was das CGI sendet, bestimmt der Webserver die Reihenfolge der Response-Header.
Bis dann ;)
Rolf
Edit: Test, Annahme Cookie bei 304, gesendet wird er und FF speichert ihn.
Code: (dl
)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
http://test/
GET / HTTP/1.1
Host: test
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: de-de,de;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
If-Modified-Since: Tue, 29 Mar 2011 18:34:48 GMT
Cache-Control: max-age=0
HTTP/1.1 304 Not Modified
Date: Thu, 31 Mar 2011 07:06:46 GMT
Server: Apache/2.2.14 (Win32) PHP/5.3.0
Connection: Keep-Alive
Keep-Alive: timeout=5, max=100
Set-Cookie: PICOSHOP=09a39c33fcd459e07503b88d82507509; path=/
----------------------------------------------------------
http://test/nv.css
GET /nv.css HTTP/1.1
Host: test
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3
Accept: text/css,*/*;q=0.1
Accept-Language: de-de,de;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Cookie: PICOSHOP=09a39c33fcd459e07503b88d82507509
If-Modified-Since: Wed, 30 Mar 2011 10:51:37 GMT
Cache-Control: max-age=0
HTTP/1.1 304 Not Modified
Date: Thu, 31 Mar 2011 07:06:47 GMT
Server: Apache/2.2.14 (Win32) PHP/5.3.0
Connection: Keep-Alive
Keep-Alive: timeout=5, max=99
----------------------------------------------------------
Last edited: 2011-03-31 09:14:10 +0200 (CEST)