I'm still chasing the problem, and I got it to work at one point. There seems to be a related bug in Zope in OFS/Image.py, where the conditional test for "modified since X" is backward: ---- cut here ---- ms=REQUEST.get_header('If-Modified-Since', None) if ms is not None: ms=string.split(ms, ';')[0] ms=DateTime(ms).timeTime() if self._p_mtime > ms: RESPONSE.setStatus(304) # Not Modified Since Then return RESPONSE ---- cut here ---- If the object's modification time is (>) than the directive, then it *has* been modified since that time, and the code should *not* return status 304. So I reversed it... And now it works -every other time-. In fact, if I just comment out the entire "If-Modified-Since" stuff, and let every image appear new, it also fails every other time. <grr> By failure, what I mean is that you bring up a GIF image in the browser, and hit reload (no SHIFT key). The first time it updates the image, the second time is receives an HTTP response Content-Length of zero. Under Netscape 4.61 under Linux (HTTP/1.1), this causes the browser to segfault if you then ask it to 'view the source' of that document. Under Netscape 2.02 for OS/2 (HTTP/1.0), it pops up a dialog box that it got an empty document. Under Netscape 4.04 for OS/2 (HTTP/1.1), it spins forever waiting for some data to arrive. And if I run it thru a proxy like Webdebug.py, for tracing, it hangs Webdebug.py, doing a read on a socket that never gets data and you can no longer access Webdebug's HTML logging features since it is blocked. <sigh> I've done two 20-hour days on this so I'm going to bed. If anyone knows the HTTP/1.x spec quite well and can tell me why "IF-MODIFIED-SINCE" request headers can't just be ignored (albeit w/performance hit) with no ill effects, I'd appreciate it hearing about it. Otherwise tomorrow it's into the RFCs... -Jeff Rush P.S. The other gotcha on this problem was that the Expires: header *MUST* be set to the "LAST-MODIFICATION* date. I tried stuffing the current date and the server's "DATE:" header into it with odd results. The time lag btw LAST-MOD and DATE was ~17 secs (human click response time) and the refresh would -fail- for those 17 seconds after an image was modified (browser would not even -ask- for the image), but then work after that (browser would then start sending IF-MODIFIED-SINCE requests). And the tip that holding down the SHIFT key while clicking refresh to bypass the cache was worth it's weight in gold. When I do that, the images -always- update correctly. Turns out doing that causes the browser to never send any IF-MODIFIED-SINCE requests, just simple GETs. On Wed, 20 Oct 1999 11:27:30 +0100, Robin Becker wrote:
In article <199910182316.JAA00991@mbuna.arbhome.com.au>, Anthony Baxter <anthony@interlink.com.au> writes
"Jeff Rush" wrote I'm pulling my hair out here over what is probably a simple HTTP issue. I have a Zope method that stuffs a new image into a Zope Image object, based on the content of the page where the method is called.
The problem is that the image is not updated until I exit the browser, and then flush all of it's caches manually.
I've turned off any proxy support, configured Netscape 4.x with the [...]
Am I missing something simple?
Yep. Browsers suck. They cache images regardless. The disgusting hack is to always call your image with the current time in the URL - eg. <img src="/your/image/method?dummy_ts=<dtml-var "ZopeTime().timeTime()">"> /your/image/method should feel entirely free to ignore dummy_ts.
This way the image has a different URL, and so the browser doesn't use a cached one.
When you're producing on-the-fly live statistics as a graph, this hideous misfeature is a complete pain in the clacker.
Anthony
I tried to do image reloads with javascript and it doesn't work (it's the URL that's cached). Seems that some of the surfcam sites use some kind of java to do this and it seems to work. Real overkill though so I've reverted to adding a spurious ?timestring as a cache fooler. Causes the browser to fill up memory and disk caches. -- Robin Becker
_______________________________________________ Zope maillist - Zope@zope.org http://www.zope.org/mailman/listinfo/zope
(Related lists - please, no cross posts or HTML encoding!
To receive general Zope announcements, see: http://www.zope.org/mailman/listinfo/zope-announce
For developer-specific issues, zope-dev@zope.org - http://www.zope.org/mailman/listinfo/zope-dev )