[Zope] Netscape/Zope cache problem - view frame source

[Sam Gendler]

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