Server cannot set status after HTTP headers have been sent.

When using ProGet and hosting it in IIS with all default settings. Atleast twice a week we get the following issue which gives a false error on our build server that wants to push the new package to the nuget feed. Somehow the package is successfully put on the nuget feed but it fails to set the proper redirect status. Does anyone have a solution on how to resolve this. The only temporary way to make it dissapear is to recycle the IIS Website and applicationpool. however it returns after a while again.

Logged: 20-4-2016 09:19:27
Level: Error
Category: HTTP
Message: An error occurred in the web application: Server cannot set status after HTTP headers have been sent.

STACKTRACE

URL: http:/[MyURL]/nuget/trunk/FindPackagesById()?id='DocumentFormat.OpenXml'
Referrer: (not set)
User: (unknown)
User Agent: NuGet Client V3/3.4.2.0 (Microsoft Windows NT 6.3.9600.0, VS Professional/14.0)
Stack trace: at System.Web.HttpResponse.set_StatusCode(Int32 value)
at Inedo.ProGet.WebApplication.SimpleHandlers.NuGet.ODataHandler.WriteError(HttpContext context, Int32 statusCode, String message, String fullMessage)
at Inedo.ProGet.WebApplication.SimpleHandlers.NuGet.ODataHandler.<ProcessRequestAsync>d__11.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at System.Web.TaskAsyncHelper.EndTask(IAsyncResult ar)
at System.Web.HttpApplication.CallHandlerExecutionStep.OnAsyncHandlerCompletion(IAsyncResult ar)

Product: ProGet
Version: 4.0.9

This is basically an error displaying the error message; unfortunately the underlying error might be obscured, so it's hard to say what it is. You shouldn't get this error with the integrated web server, so if it's a persistant error that might be a way to quickly diagnose until we can ship a fix in the error handling.

Bump.

I am getting quite a few of these errors every week using IIS 8.5 and ProGet 4.1.3.

Here are a few examples:

URL: https://feeds.x.com/nuget/nuget/FindPackagesById()?id='AutoFixture.AutoMoq'
Referrer: (not set)
User: (unknown)
User Agent: NuGet Client V3/3.5.0-beta2-1484 (Microsoft Windows NT 10.0.10586.0, VS Enterprise/14.0)
Stack trace:    at System.Web.HttpResponse.set_StatusCode(Int32 value)
   at Inedo.ProGet.WebApplication.SimpleHandlers.NuGet.ODataHandler.WriteError(HttpContext context, Int32 statusCode, String message, String fullMessage)
   at Inedo.ProGet.WebApplication.SimpleHandlers.NuGet.ODataHandler.<ProcessRequestAsync>d__11.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at System.Web.TaskAsyncHelper.EndTask(IAsyncResult ar)
   at System.Web.HttpApplication.CallHandlerExecutionStep.OnAsyncHandlerCompletion(IAsyncResult ar)

URL: https://feeds.x.com/administration/service
Referrer: https://feeds.x.com/administration
User: Admin
User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; Trident/7.0; rv:11.0) like Gecko
Stack trace:    at System.Web.Hosting.ISAPIWorkerRequestInProcForIIS6.FlushCore(Byte[] status, Byte[] header, Int32 keepConnected, Int32 totalBodySize, Int32 numBodyFragments, IntPtr[] bodyFragments, Int32[] bodyFragmentLengths, Int32 doneWithSession, Int32 finalStatus, Boolean& async)
   at System.Web.Hosting.ISAPIWorkerRequest.FlushCachedResponse(Boolean isFinal)
   at System.Web.HttpResponse.Flush(Boolean finalFlush, Boolean async)
   at System.Web.HttpWriter.WriteFromStream(Byte[] data, Int32 offset, Int32 size)
   at Inedo.IO.SlimMemoryStream.CopyTo(Stream destination)
   at Inedo.Web.PageFree.SimplePageBase.ProcessRequest(HttpContext context)
   at System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
   at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)
   
URL: https://feeds.x.com/administration/error-log/entry?messageId=82227
Referrer: https://localhost:448/administration
User: Admin
User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; Trident/7.0; rv:11.0) like Gecko
Stack trace:    at System.Web.Hosting.ISAPIWorkerRequestInProcForIIS6.FlushCore(Byte[] status, Byte[] header, Int32 keepConnected, Int32 totalBodySize, Int32 numBodyFragments, IntPtr[] bodyFragments, Int32[] bodyFragmentLengths, Int32 doneWithSession, Int32 finalStatus, Boolean& async)
   at System.Web.Hosting.ISAPIWorkerRequest.FlushCachedResponse(Boolean isFinal)
   at System.Web.HttpResponse.Flush(Boolean finalFlush, Boolean async)
   at System.Web.HttpWriter.WriteFromStream(Byte[] data, Int32 offset, Int32 size)
   at Inedo.IO.SlimMemoryStream.CopyTo(Stream destination)
   at Inedo.Web.PageFree.SimplePageBase.ProcessRequest(HttpContext context)
   at System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
   at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)

Sorry, I messed up. Can you please remove the company name in my previous post (in feeds.x.com)?

Thanks.

PS: Would be nice to have an edit function in these posts...

We've discovered what causes this error; it's when there's a network failure occurring after the client has disconnected.

Most likely, the root cause of the disconnects are related to the massive onslaught of long-running, simultaneous HTTP requests occurring during package restores; the intermediate network hardware/components cannot handle what is effectively a DDoS attack.

Tweaking your QoS settings might help, as will removing connectors and setting up ProGet in a load-balanced manner.

Understood!

Thanks for the quick response.

Btw, it would also be nice to have a "Clear All" button in the recent errors section, because when we start having a ton of the same error, it fills it up and we can't clear them easily.

Thanks again!