[Zope-dev] Where best to intercept a request to send a 304 response in Zope 2

Martin Aspeli optilude+lists at gmail.com
Tue Jan 5 22:14:25 EST 2010


Laurence Rowe wrote:
> 2009/12/31 Martin Aspeli<optilude+lists at gmail.com>:
>> Hi,
>>
>> A few of us are playing with some caching tools, trying to get to a more
>> sane and less monkey patch-laden approach than CacheFu
>> (Products.CacheSetup), for use with Zope 2.12.
>>
>> It is relatively easy to set response headers, e.g. in an
>> IPubBeforeCommit event handler.
>>
>> However, we also need to be able to intercept a request to send a 304
>> response if the underlying object has not been modified.
>>
>> CacheFu monkey patches ZPT rendering to avoid the actual rendering if a
>> 304 response is being sent, returning an empty string instead. I'd
>> rather not have such patches, though, and anyway this only work with
>> things rendered as ZPTs. It also doesn't avoid any pre-work that a view
>> may do before rendering its template, if indeed it has one.
>>
>> Another thought was to use IPubAfterTraversal, at which point we have
>> the object to publish and security checks have been completed. However,
>> ZPublisher.Publish goes straight from that into mapply().
>>
>> Can anyone think of a good way to do this? Maybe we need to add some
>> kind of condition around mapply(), e.g. to do not nothing if there's a
>> 304 response header, or some other marker?
>
> I think this is analogous to 404 Not Found errors. It should be
> possible to handle them with the combination of:
>
>    * raise a NotModified exception in an IPubAfterTraversal handler
>    * in a NotModified exception view, setStatus 304 Not Modified an
> return an empty string.

Yep, I actually got there in the end on my own. The way that the 
exception *type/class name* is used to determine the status is pretty 
evil, but so long as the exception is actually called NotModified, it 
works. Setting it explicitly doesn't, since it gets overridden.

See plone.caching's hooks.py for an implementation. I also had to tell 
Plone's error_log (in plone.app.caching's setuphandlers.py) not to log 
the exception, since zpublisher_error_hook always logs the exception 
even if there's a view on it.

Martin

-- 
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book



More information about the Zope-Dev mailing list