[Zope] Fixing refresh problems

Alexander Staubo alex@mop.no
Mon, 21 Jun 1999 20:25:36 +0200


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