Home/ Questions/Q 8824213
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-14T06:33:19+00:00

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

  • 0

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);
}
Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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.

    • 0