I'm running into a few problems getting file caching to work correctly with the Local File System product. I am using the version 2.1.0 source distribution. The first problem has to do with the index_html() method of the File class in OFS/image.py. Line 188 says: if self._p_mtime > ms: RESPONSE.setStatus(304) return RESPONSE What this seems to say to me is, "If my modification time is later than the modification time of the cached file then send a 304 (Not Modified) response." If I'm not mistaken, this is exactly the opposite of what the HTTP specification says about the If-Modified-Since header. So, line 188 should say: if self._p_mtime <= ms: ... Secondly, once that modification is made I noticed that the DateTime class seems to be making slight rounding errors when parsing the http date string which is also throwing off the caching. To test this, I wrote a very simple http proxy so I can see what's being sent back and forth. I also added some debugging output to the image.py file. ms=DateTime(ms).timeTime() import time print 'ms:', time.ctime(ms), '(%.8f)' % ms print 'mtime:', time.ctime(self._p_mtime), '(%.8f)' % self._p_mtime print 'not modified:', self._p_mtime <= ms if self._p_mtime <= ms: Here's an example transaction that should send a 304 response. send: 'GET /local/gifs/python.gif HTTP/1.0\015\012' send: 'user-agent: Mozilla/4.6 [en] (WinNT; I)\015\012' send: 'accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, image/png, */*\015\012' send: 'authorization: Basic YWRtaW46bGV0bWVpbg==\015\012' send: 'accept-encoding: gzip\015\012' send: 'if-modified-since: Wed, 15 Sep 1999 21:11:30 GMT; length=649\015\012' send: 'cookie: tree-s="eJyLjlZ3hANPW/XYWAAtiQTP"\015\012' send: 'proxy-connection: Keep-Alive\015\012' send: 'referer: http://localhost:8080/local/gifs\015\012' send: 'host: localhost:8080\015\012' send: 'accept-charset: iso-8859-1,*,utf-8\015\012' send: 'accept-language: en\015\012' send: '\015\012' reply: 'HTTP/1.0 200 OK\015\012' reply: server: Zope/Zope 2.0.0b5 (binary release, python 1.5.2, win32-x86) ZServer/1.1b1 reply: content-length: 649 reply: content-type: image/gif reply: connection: close reply: last-modified: Wed, 15 Sep 1999 21:11:30 GMT reply: date: Thu, 09 Dec 1999 22:11:00 GMT Here's the debug output: ms: Wed Sep 15 14:11:29 1999 (937429889.99999952) mtime: Wed Sep 15 14:11:30 1999 (937429890.00000000) not modified: 0 As you can see, the request header says: if-modified-since: Wed, 15 Sep 1999 21:11:30 GMT; length=649 and the response header says: last-modified: Wed, 15 Sep 1999 21:11:30 GMT but the DateTime class converts this time to: Wed Sep 15 14:11:29 1999 which is off by one second, so it thinks that the file has in fact been modified. The workaround I came up with for this is to round off the time value generated by the DateTime class. ms=DateTime(ms).timeTime() ms = round(ms, 1) If I am correct, and this is actually a problem with the DateTime class, I would like to see it fixed, though. I'm not sure whether my third problem is a problem with Zope or my web browser (Netscape 4.6). What happens is that once the browser sends a request with an 'If-Modified-Since' header and the server responds with 200 (OK) instead of 304 (Not Modified), the browser never sends an 'If-Modified-Since' header again unless I restart the browser or clear the cache. In other words, if it tries to use the cached file and finds that it's out of date then it never tries to use the cached file again. I suspect that this is a problem with Netscape, though, and there's nothing I can really do about it. I am interested in any and all feedback regarding these problems. I would like to know if I have found some valid bugs here and should submit them to the collector. Thanks, --jfarr