If you have a control (i.e.
SyndicationGenerator) that alters the page output to produce a custom stream, you will notice on a v3 system that the cache header information for the response always contains information for the web part page that contains the control and not the values you supplied.
This obviously problematic if you need to set the cache header for your application. Controlling cache values is a common requirement for many applications (as with the SGWP).
In v2, you could easily set the cache headers as you would with any other asp.net request.
this.Page.Response.AppendHeader (SyndicationGenerator.HeaderETag, this.ETagHeader);
this.Page.Response.AppendHeader (SyndicationGenerator.HeaderLastModified, this.LastModifiedHeader);
And that was all you needed to do....
In v3, your controls will need to instruct SharePoint to not override your cache settings. SharePoint basically add the cache and etag values at the very last possible moment in time - unfortunately, this is a tad bit too late for your code as it has already run.
To circumvent the override behavior, in v3 you will need to add the following to your code...
// V3: Disable cache headers...
System.Web.HttpContext.Current.Items ["DisableSettingBrowserCacheHeaders"] = "somestringvalue";
The value of the string doesn't matter, SharePoint basically checks to see if the object "DisableSettingBrowserCacheHeaders" exists and if it does, SharePoint will not stamp it's own cache and etag values into the response.
-Maurice