[Zope] Fixing refresh problems

Alexander Staubo alex@mop.no
Tue, 22 Jun 1999 01:10:50 +0200


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