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

[Tres Seaver]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Martin Aspeli wrote:
> 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,

bobo was trying really hard back in 1996. ;)

> but so long as the exception is actually called NotModified, it 
> works. Setting it explicitly doesn't, since it gets overridden.

You can "lock" the status and body of the response, which causes
subsequent attempts to set them to fail silently.


Tres.
- --
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAktEURoACgkQ+gerLs4ltQ6RxQCgm1F5fZCEVo7e3HWknAN8FyLB
pXkAnA+7pUvamS2SAaKnARI5LYRXcGem
=p7ah
-----END PGP SIGNATURE-----