Re: best practices on setting HTTP headers and status codes

plone.app.caching can do most of this for you. The best practice would be:

1. Use the cache:ruleset zcml directive to declare which caching ruleset 
should be used for the view, based on what kind of content it returns.
2. Use plone.app.caching's control panel to configure what caching 
operations to apply for that ruleset, based on factors like whether 
you've got a proxy or not and on how aggressively you want it to be cached.

It sounds like in your case you probably want your view to be treated as 
an "item view", which you can do like this:

<configure xmlns:cache="http://namespaces.zope.org/cache">
     <cache:ruleset ruleset="plone.itemView" for=".path.to.YourView" />
</configure>

"Item views" are handled like this in the standard caching profiles:
- "without caching proxy" and "with caching proxy": weak caching 
(handles 304 responses using an ETag that will be invalidated when the 
catalog counter increments; i.e. whenever any item is modified)
- "with caching proxy (and split-view caching)": moderate caching 
(caches in proxy and handles 304 responses there using a similar ETag; 
make sure that the content type is configured to send purges to the 
proxy when it is modified)

(Note: If your view happens to be the default view for this content 
type, I think you need to configure which ruleset to use for the content 
type in the caching control panel, rather than configuring a ruleset for 
the view in zcml. But that's not the case for the view you described.)

hope this helps,
David

On 9/11/14, 1:55 PM, Héctor Velarde wrote:
> I'm working on the development of a package (collective.liveblog) that 
> has a browser view that, potentially, can be hit by thousands of 
> clients on a matter of a minute. this browser view returns some HTML 
> used to update the default view of a content type using an AJAX call. 
> the idea is not to update the whole default view, but just a small 
> part of it, for performance and user experience reasons.
>
> what I want is to return a 304 status code if the view has not changed 
> since the last time the client got it. as I want to be a good citizen, 
> I want to handle this with and without proxies (Varnish).
>
> to solve this problem I'm handling the "If-Modified-Since" request 
> header and, while working on that, I found some code in different 
> parts of the Plone core code that handles similar situations; an 
> example, for images, can be found here:
>
> https://github.com/plone/plone.app.blob/blob/master/src/plone/app/blob/download.py#L5 
>
>
> we just had a hot debate on whether or not this should be implemented 
> on the browser view.
>
> my question: is having code handling this kind of situations 
> considered a good practice or is best to leave this to 
> plone.app.caching and friends?
>
> best regards
>
>
> ------------------------------------------------------------------------------
> Want excitement?
> Manually upgrade your production database.
> When you want reliability, choose Perforce
> Perforce version control. Predictably reliable.
> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
>
>
> _______________________________________________
> Plone-developers mailing list
> Plone-developers-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/plone-developers

------------------------------------------------------------------------------
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk

_______________________________________________
Plone-developers mailing list
Plone-developers-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/plone-developers