Rob Page wrote:

...

I've tried playing with different cache options in Netscape, and in order to make it show me the source of the failed method, I must go into Preferences and hit "Clear Memory Cache" and "Clear Disk Cache". Has anyone else experienced this problem, and if so, have you found a workaround?

I'm running the libc5 version of Netscape 4.7 on a Debian Linux box with Zope 2.0.0.

This seems to be the frustratingly lame behavior on linux, winnt, win 9x and solaris!!! If I recall correctly, this cache stuff has been broken througout 4.x I've not been able to find an acceptable workaround other than the one you mention above.

Frustrating as hell, isn't it?

--Rob

A couple of suggestions. In your standard_html_header, set a response header of 'Cache-Control: no-cache' or 'Cache-Control: max-age=0'. Just remove this line before making the site go live, or set it to be inserted if a certain variable is set. Then access the page with http://url?variable_name=1. Alternatively, if you hold down the shift key when you hit reload, it forces the browser to reload the document. To be honest, I have been building network caches for about 3 years now, and I have never seen any misbehaviour on the part of netscape. I suspect that if you are having problems, it is something going on inside of Zope. In all my years of working with netscape, if you set the memory and disk cache size to zero, netscape doesn't cache ANYTHING. All other settings result in netscape caching objects, but sending If-Modified-Since requests to zope. That means that if you change an object more than once a day, zope is probably going to respond with a Not-Modified response, which will cause netscape to serve the object out of its cache. If you want better cache behaviour, zope needs to support the HTTP/1.1 ETag header, which allows you to mark an object as expired with finer granularity than a single day. Instead, every new version of the object gets a new ETag, so if the ETag is different, the object is different. I just did a little test, and couldn't help but notice that Zope claims to support HTTP/1.1, in that it will respond to a 1.1 request with a 1.1 response. It even did a persistent connection. However, when I sent a 1.0 request at it, including a Connection: keep-alive header, it still failed to do a persistent connection. Since IE is the only browser that sends http/1.1 requests, we are certainly losing a lot of efficiency when using ZServer. I haven't checked to see how Apache deals with pcgi requests that have a content-length. It may or may not do persistent connections, with or without chunking the data. Someone should probably look into it, though. The efficiency of servers goes WAY up with persistent connections. As an example, doing static GET requests from 32 client machines to IIS 4.0 on a particular hardware setup resulted in about 1000 transaction/second. When we ran the exact same test with Persistent Connections, IIS was able to product >4000 transactions/second. Since Zope seems to produce an entire object in memory before serving it, allowing us to provide a content-length and therefore persistent connections, we should be taking advantage of the performance gains. More importantly, someone should think about enable HTTP/1.1 chunking, which would allow Zope to serve an object as it gets rendered, instead of waiting until the entire thing gets generated in memory. This will save memory and improve latency dramatically, which causes a user to perceive a massive increase in performance, even if the net gain really isn't that large, just because the object STARTS to appear much more quickly. Of course, this is, once again, an IE only advantage, since it does 1.1 --sam