Re: [Zope-dev] Where best to intercept a request to send a 304 response in Zope 2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin Aspeli wrote: Laurence Rowe wrote: 2009/12/31 Martin Aspelioptilude+li...@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 tsea...@palladion.com Palladion Software Excellence by Designhttp://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- ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Where best to intercept a request to send a 304 response in Zope 2
Tres Seaver wrote: You can lock the status and body of the response, which causes subsequent attempts to set them to fail silently. Oh, that's great! I even remember reading that code and it never struck me. Thanks a lot! Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Where best to intercept a request to send a 304 response in Zope 2
2009/12/31 Martin Aspeli optilude+li...@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. Laurence ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Where best to intercept a request to send a 304 response in Zope 2
Laurence Rowe wrote: 2009/12/31 Martin Aspelioptilude+li...@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 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Where best to intercept a request to send a 304 response in Zope 2
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? Cheers, Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
