-----Original Message----- From: Brian Lloyd [mailto:Brian@digicool.com] Sent: 21. juni 1999 19:41 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...

That's odd. Apache and IIS both support and use the If-Modified-Since header, and I have experienced no client-side problems with this (Netscape 3.0 and later, IE 4.0 and later). What I notice is that Apache emits the ETag header, which is something Zope (ZServer) should do, as well. It's probably not related to your problem, but it would assist browsers in caching contents.

...

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...

Never having used mxDateTime, I can't tell. However, why do we need to bother with DST at all? On Windows, at least, DST handling is generously wrapped into the time APIs (although there are functions to obtain it separately); if all you need is to obtain the current time, what's keeping you? Am I missing something? (I admit I have not studied DateTime.py a lot.) -- 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