Adding 2 lines to lib/python/App/ImageFile.py seems to fix it import stat RESPONSE.setHeader('Content-Length', os.stat(self.path)[stat.ST_SIZE]) Here's a diff: --- ImageFile.py.orig Tue Feb 11 17:17:04 2003 +++ ImageFile.py Mon Jun 28 11:42:38 2004 @@ -16,6 +16,7 @@ import os import time +import stat from App.config import getConfiguration from OFS.content_types import guess_content_type @@ -82,6 +83,7 @@ last_mod = long(0) if last_mod > 0 and last_mod <= mod_since: RESPONSE.setStatus(304) + RESPONSE.setHeader('Content-Length', os.stat(self.path)[stat.ST_SIZE]) return '' f=open(self.path,'rb') Steven Hayles wrote:
I think I'm seeing a bug in the 304 handling of Apache or ImageFile (as used by misc_ and p_ images such as /p_/pl the plus in a box). I have Apache working as a proxy/cache in front on ZOPE. Everything is fine until I perform a forced refresh on one of these images. ZOPE replies to Apache with a 304 status but with a Content-length header of 0. From then on, Apache serves a zero length image.
The code for FSImage and Image sets the Content-length header to the length of the data that would have been sent. Image has the comment:
# Set header values since apache caching will return Content-Length # of 0 in response if size is not set here
Does the code for ImageFile need to do similarly, or do I just need a later version of Apache?
Thanks
Steven
_______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )