Last-modified header aanpassen naar datum laatste post/edit

[Spider.007]

Al enige tijd zit ik mij wat af te vragen. Wat is de reden dat alle pagina's op GoT met het Last-Modified attribuut op de huidige tijd worden verstuurd? Ook worden er een aantal header meegestuurd om te voorkomen dat er gecached wordt (Zoals een Expires in 1997, en een no-store, no-cache enz...)

Ik weet dat GoT een zo goed als onbeperkte hoeveelheid bandbreedte kan gebruiken. Toch denk ik dat het browsen op GoT een stuk sneller kan worden gemaakt als er in de list_messages een stukje code komt dat de echte last modified date (op basis van laatste edit/addition) wordt teruggestuurd. De browser hoeft hierdoor niet de hele pagina opnieuw van de server te halen. Vanwaar de angst voor caching?

[Harm]

Is dat niet wat de optie 'Gebruik http 304 headers' doet?

[Spider.007]

Dat klinkt wel logisch; ik heb deze optie echter altijd al aan gehad. Ik zie hiermee geen verschil in de serverresponses.. Ik zal eens kijken of het uitmaakt als ik hem uit, en weer aanschakel

Helaas; dit maakt geen enkel verschil;

code:

Expires: Mon, 26 Jul 1997 05:00:00 GMT
Last-Modified: Sat, 24 Jan 2004 18:32:12 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0

Bij een topic waar de laatste aanpassing op 'Saturday 24 January 2004 19:06' is gedaan

[ Voor 45% gewijzigd door Spider.007 op 24-01-2004 19:34 ]

[Kees]

Alsof IE (toch nog de meest gebruikte browser) zich daaraan houd..

Magoed tis niet iets voor LA, dus -> BUG

[Spider.007]

Kees schreef op 24 januari 2004 @ 20:36:
Alsof IE (toch nog de meest gebruikte browser) zich daaraan houd..

Dat weet ik eigenlijk niet. Is dat een reden om het niet in te bouwen?

Magoed tis niet iets voor LA, dus -> BUG

Ik was in de veronderstelling dat dit express niet was gedaan; door Harm's post werd ik mij bewust van het feit dat dit al geimplementeerd was; maar alleen niet werkte

[ACM]

Wijzigingen HTTP-resonse-headers van GoT

is al es gedaan en werkte niet zo goed.
en de 304-header die je kan laten terugsturen werkt ook niet bijzonder goed in IE.

[ Voor 44% gewijzigd door ACM op 24-01-2004 22:12 ]

[Spider.007]

Dat bericht was ik inderdaad nog niet tegengekomen op mijn zoektocht; het is wel interessant om te lezen. Alleen begrijp ik niet precies wat er nou misgaat? Klopt mijn redenatie dat in de ideale situatie:

• Last-modified op de laatste toevoeging/edit tijd staat
• Expires op een ruime tijd (+1 jaar ofzo) staat
• Cache-Control de waarde must-revalidate bevat

En wat gaat er dan precies fout in IE? Dat bij het posten van het bericht de pagina niet ververst wordt? Als goed is kan de server toch met een 200 ipv een 304 reageren na een edit/addition na de if-modified tijd?

[Harm]

Spider.007 schreef op 25 januari 2004 @ 13:34:
En wat gaat er dan precies fout in IE? Dat bij het posten van het bericht de pagina niet ververst wordt? Als goed is kan de server toch met een 200 ipv een 304 reageren na een edit/addition na de if-modified tijd?

Jup, maar daar kan IE niet goed mee omgaan en dus werkt het niet naar behoren in die browser .

[Spider.007]

In hoeverre is een browserspecifieke uitzondering hier wenselijk?

[chem]

IE is een stinkbrowser die geen snol van cacheing headers begrijpt, en dat *(@*(^# MS vindt het weer nodig om hun eigen headers te bedenken (hoe verzin je het).

Dus als ik me aan de standaard hou (wat heel mooi zou werken, incl. e-tag etc.), dan snapt IE het niet.

Als je de 304-headers aanzet zou je trouwens de versie met etags etc. moeten krijgen, dat gaat blijkbaar nog verkeerd. Ik zal kijken waardoor dat komt.

[Spider.007]

chem schreef op 25 januari 2004 @ 15:06:
IE is een stinkbrowser die geen snol van cacheing headers begrijpt, en dat *(@*(^# MS vindt het weer nodig om hun eigen headers te bedenken (hoe verzin je het).

Dus als ik me aan de standaard hou (wat heel mooi zou werken, incl. e-tag etc.), dan snapt IE het niet.

Als je de 304-headers aanzet zou je trouwens de versie met etags etc. moeten krijgen, dat gaat blijkbaar nog verkeerd. Ik zal kijken waardoor dat komt.

Dat lijkt me een goed idee; mag ik hieruit lezen dat je gaat kijken naar een mogelijkheid tot het perfectioneren (lees repareren ) van de 304 header voor niet IE browsers

[chem]

De 304-header heeft altijd perfect gewerkt, en Mozilla etc. hanteerden hem perfect (incl. tussenliggende proxies).
Maar ja, IE he...

[Spider.007]

code:

HTTP/1.1 200 OK
Date: Sun, 25 Jan 2004 14:21:02 GMT
Server: Apache/1.3.29 (Unix) PHP/4.3.4 mod_gzip/1.3.19.1a
X-Served-By: Acidalia, Acidalia
X-Powered-By: PHP/4.3.4
Expires: Mon, 26 Jul 1997 05:00:00 GMT
Last-Modified: Sun, 25 Jan 2004 14:21:02 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
[...]

Zoals je ziet zijn Date en Last-Modified gelijk aan elkaar. Ook is een expiredatum ingesteld die al enige tijd achter ons ligt. De Cache-Control headers geven samen met de Pragma header opdracht aan de browser om niet te cachen. Dit is met Mozilla / Firebird 0.7; met een aangevinkt "Gebruik http 304 headers" vakje.

[ Voor 2% gewijzigd door Spider.007 op 25-01-2004 15:40 . Reden: ik zag het licht :P ]

[chem]

Typo
check de AT maar, die is netjes voorzien van de juiste headers.
Fixed in 1.9.2