What seems evident is that newer browsers such as IE 5.0 do not heed Pragma and Expires headers correctly. The solution is to provide the Cache-Control header, which supersedes the "Pragma: no-cache" header in HTTP 1.1, thus: ... What bugs me is that ZServer doesn't handle If-Modified-Since correctly, or doesn't seem to. Telnetting to ZServer and typing a future date value doesn't elicit the expected 304 error ("Not modified").
I tried putting handling in for this recently, with pretty bad results... a number of browsers seemed to have problems with 304's implemented, so I took them back out. I could, of course, have been doing something stupid that caused the odd (hanging) behavior in some clients, so if anyone wants to implement If-Modified-Since handling, I'd be happy to roll it in if it is thoroughly tested and found not to cause any problems with any known clients...
Also, for me, ZServer returns a Last-Modified timestamp that is an hour off. The DateTime module seems to be slightly brain damaged in its handling of time zones; if a document was modified at 18:00 GMT+1 (which is my time zone), ZServer will emit:
Last-Modified: Mon, 21 Jun 1999 16:00:00 GMT
I've never been a wizard with date arithmetic, but this looks weird to me: When my local time is 18:00, this is 17:00 GMT time. Is this perhaps related to the timezone bug that Dylan Jay posted a fix for a while back?
No, this probably reflects daylight savings time not being handled correctly... which is unforunately a *hard* problem (with a capital H :). The DT module tries to deal with this as best it can, but zones for which there is no information in it's pre-fab database are probably mishandled during DST. Do you happen to know if mxDateTime or any of the other date/ time handling packages out there handle DST in arbitrary timezones? Perhaps there is something we could learn from one of those... Brian Lloyd brian@digicool.com Software Engineer 540.371.6909 Digital Creations http://www.digicool.com