[Zope] Browser Sticky Fingers

[Jeff Rush]

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 )