What's extra super weird is that it returns a correct Date field. Look at this HTTP output: HTTP/None 200 OK Server: Zope/Zope 1.11.0pr1 (binary release, python 1.5.1, win32-x86) ZServer/1.1b1 Date: Tue, 22 Jun 1999 00:08:26 GMT Content-Type: text/html Content-Length: 5974 Last-Modified: Mon, 21 Jun 1999 23:08:17 GMT It may not look funny until you consider that this document was modified 9 seconds before the GET request occurred. In other words: The Date field is correct; Last-Modified is off by an hour. -- Alexander Staubo http://www.mop.no/~alex/ "It has taken the planet Earth 4.5 billion years to discover it is 4.5 billion years old." --George Wald
-----Original Message----- From: zope-admin@zope.org [mailto:zope-admin@zope.org]On Behalf Of Brian Lloyd Sent: 21. juni 1999 19:44 To: 'Alexander Staubo'; Zope Mailing List (E-mail) Subject: RE: [Zope] Fixing refresh problems
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
_______________________________________________ Zope maillist - Zope@zope.org http://www.zope.org/mailman/listinfo/zope
(For developer-specific issues, use the companion list, zope-dev@zope.org - http://www.zope.org/mailman/listinfo/zope-dev )