Hi Folks, OK.. I've narrowed this down.. but I think I've nearly reached the limit of what I can do easily. ;-) There appears to be some problem with ZServer and long "File" objects under FreeBSD (3.2 in my case) and 2.1.X. When I go back to 2.0.1 all is well... the chunk of code that *seems* to matter here is in lib/python/OFS/Image.py: RESPONSE.setHeader('Content-Length', self.size) data=self.data if type(data) is type(''): return data while data is not None: RESPONSE.write(data.data) data=data.next return '' in 2.0.1 this is just: return self.data Here's the wierd part. When I step through this code with the debugger it works! When I try to get a large object (that I've uploaded after 2.1.X) with a browser, e.g., lynx, or netscape I get a few chunks, and then the download stops. If I take this code out and replace it with the 2.0.1 code, it works. And another wierd part.. if I try to get an object that was already in Zope *before* I upgraded.. it works too! Hmmm.. stepping throught the debugger with such an object I discovered the reason why... in 2.0.1 large uploaded objects were stored as a single massive chunk... now they are multiple chunks... for some reason multiple chunks do not work reliably in this context. I think it might be a timing problem here is my 'testing.py' file I've been using for debugging: ---------------------------------------------------------------------- import sys sys.path.insert(0,'/usr/local/etc/Zope/lib/python') import ZPublisher print ZPublisher.Zope("/largeFileObject", d=1, u="") ---------------------------------------------------------------------- I set d=1 to step through and d=0 to run from the command line. if I try: python testing.py | more I get only one chunk.. and then the output stops. (something about timing and the pipe?). If I try: python testing.py > foo I get the whole file in foo. (correct headers and all BTW). Anyway.. I need to get this resolved. Any hints on trying to track down the problem would be most appreciated! thanks, -steve