SharePoint Publishing BlobCache error with SetResponseHeaders

Question

In my error logs I see the following error and stacktrace:

Page error: URL: /SiteCollectionImages/Push/zh-cn/Machining_calculators.jpg
Debugging enabled: False
Correlation ID: 857a397e-8063-447c-af92-b114074282b8
Message: Server cannot append header after HTTP headers have been sent.
Source: System.Web
StackTrace: at System.Web.HttpResponse.AppendHeader(String name, String value)
at Microsoft.SharePoint.Publishing.BlobCache.SetResponseHeaders(HttpContext context, BlobCacheEntry target)
at Microsoft.SharePoint.Publishing.BlobCache.SendCachedFile(HttpContext context, BlobCacheEntry target, SPUserToken currentUserToken, SiteEntry currentSiteEntry)
at Microsoft.SharePoint.Publishing.BlobCache.SendCachedFile(HttpContext context, BlobCacheEntry target, SiteEntry currentSiteEntry)
at Microsoft.SharePoint.Publishing.BlobCache.HandleCachedFile(HttpContext context, BlobCacheEntry target, Boolean anonymousUser, SiteEntry currentSiteEntry) at Microsoft.SharePoint.Publishing.BlobCache.RewriteUrl(Object sender, EventArgs e, Boolean preAuthenticate) at Microsoft.SharePoint.Publishing.PublishingHttpModule.AuthorizeRequestHandler(Object sender, EventArgs ea)
at System.Web.HttpApplication.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)

It seems that the inbuilt BlobCache attempts to set httpresponse-headers after response has been sent to server. Does anyone know how to correct this, or is it a bug in the SharePoint-platform?

Update: My web.config looks like this:

<BlobCache location="d:\BlobCache\companyname" path="\.(gif|jpg|jpeg|jpe|jfif|bmp|dib|tif|tiff|ico|png|wdp|hdp|css|js|asf|avi|flv|m4v|mov|mp3|mp4|mpeg|mpg|rm|rmvb|wma|wmv)$" maxSize="10" enabled="true" />

And it is also worth mentioning that this doesn't happen for all image-requests. Approximately 90-95% of all image request end up being propertly cached in the specified location and sent to the client with proper response codes.

Update2: Hooks into HttpApplication from HttpModules:

app.PreSendRequestContent += new EventHandler(app_PreSendRequestContent);

and some SharePoint specific code in HttpModule:

var spApp = context as SPHttpApplication;
if (spApp != null)
{
    var labelHandler = new VaryByLabelHandler();
    spApp.RegisterGetVaryByCustomStringHandler(labelHandler);
    var countryHandler = new VaryByCountryHandler();
    spApp.RegisterGetVaryByCustomStringHandler(countryHandler);
    var claimHandler = new VaryByClaimHandler();
    spApp.RegisterGetVaryByCustomStringHandler(claimHandler);
}

These types of problems are really hard to diagnose without knowing more about the environment. What custom code is running in this farm? — Tobias
Well, lots and lots actually, but what might be relevant in this case is a few custom http-modules, (handling custom 404 etc.). What confuses me is that there is no trace of them in the stacktrace, and I can really find anything in my custom handlers that causes this. Unable to reproduce in my local dev-machine as well.. — Rikard Uppström

Rikard Uppström Rikard Uppström · Accepted Answer · 2012-11-14T14:57:16

The issue was caused by what I see as a bug in the SharePoint-platform. The issue affected images stored in SiteCollection-library, but not all images. After digging deeper, and with some luch. I could see that these images had been uploaded before we turned off content approval on the list, as could be seen by using the "Manage Content & Structure"-tool. These images were still in Draft-mode. This should not be so since we turned off content approval, but for some reason this setting affected the BlobCache's ability to propertly serve them.

Exactly which images were affected could easily be observed by using Fiddler, and seeing that these images prompted a 304-response from server, whilst other were being fetched directly from client cache.

The solution was to perform a mass-checkout and mass-checkin of these images, and then they got Approval-state "Approved", and the issue was solved.

SharePoint Publishing BlobCache error with SetResponseHeaders

3 Answers