Il server non può impostare il tipo di contenuto dopo che le intestazioni HTTP sono state inviate - rintracciare questo valore

Question

Uno dei nostri utenti sta riscontrando un errore nella nostra applicazione web. Non siamo riusciti a duplicare questo problema e sospettavo che fosse collegato alla rete. Ho avuto l'utente provare l'applicazione utilizzando il loro notebook nel loro ufficio e la loro casa, e ha confermato che il problema si verifica solo nel loro ufficio.

Ho eseguito l'accesso al server e ho guardato il visualizzatore di eventi subito dopo aver provato nel loro ufficio e il seguente avviso era nel log.

Sono in perdita su come iniziare a rintracciarlo. Eventuali suggerimenti?

Event Log Viewer di seguito:

Codice evento: 3005 Messaggio di evento: si è verificata un'eccezione non gestita. Event time: 6/20/2012 6:32:45 PM Event time (UTC): 20/06/2012 10:32:45 PM ID evento: ebf8f628a9b3457cbea117c8c2da2186 Sequenza eventi: 2970 Evento evento: 26 Codice di dettaglio evento: 0 Istruzioni per l'applicazione:

Application domain: /LM/W3SVC/50/ROOT-1-129847041933281152 
Trust level: Full 
Application Virtual Path:/
Application Path: c:\websites\foobar.acme.com\ 
Machine name: MyServer Process information: 
Process ID: 15152 
Process name: w3wp.exe 
Account name: NT AUTHORITY\NETWORK SERVICE Exception information: 
Exception type: HttpException 
Exception message: Server cannot set content type after HTTP headers have been sent. Request information: 
Request URL: http://foobar.acme.com/Project/Evaluate/ResultsXML.aspx?step=89&uid=4397&rnd=hhf8oe 

Request path: /Project/Evaluate/ResultsXML.aspx 
User host address: 192.168.102.1 
User: 
Is authenticated: False 
Authentication Type: 
Thread account name: NT AUTHORITY\NETWORK SERVICE Thread information: 
Thread ID: 12 
Thread account name: NT AUTHORITY\NETWORK SERVICE 
Is impersonating: False 
Stack trace: at System.Web.HttpResponse.set_ContentType(String value) at System.Web.UI.Page.SetIntrinsics(HttpContext context, 
Boolean allowAsync) at 
System.Web.UI.Page.ProcessRequestWithNoAssert(HttpContext context) 
at System.Web.UI.Page.ProcessRequest(HttpContext context) at 
ASP.error_aspx.ProcessRequest(HttpContext context) at 
System.Web.HttpServerUtility.ExecuteInternal(IHttpHandler handler, 
TextWriter writer, Boolean preserveForm, Boolean setPreviousPage, 
VirtualPath path, VirtualPath filePath, String physPath, Exception 
error, String queryStringOverride) 
Custom event details: 

Answer 1

potrebbe avere a che fare con integrato versus mode gasdotto classica. Confronta i tuoi due ambienti e assicurati che non differiscano da questo punto di vista.

IIRC in modalità pipeline integrata è possibile ripristinare o rimuovere le intestazioni dopo che sono state scritte; nella modalità classica non puoi.

Se non si conosce la differenza, controllare l'articolo this.

Answer 2

Sto aggiungendo una seconda risposta nel caso in cui ho completamente frainteso la domanda quando ho scritto la prima risposta. In questa risposta presumo che esista esattamente un server e questo è un problema specifico per browser/utente.

1. Verificare che l'errore che hai postato non è un rosso herring-- controllare i registri eventi per altri eventi e assicurarsi che accade solo quando l'utente incontra il suo errore.

2. prega di descrivere il comportamento associato con l'errore (ad esempio quello che fa 500 messaggio di errore la visualizzazione del browser?? Errore di sistema di qualche tipo? Disconnessione di rete?)

3. Controllare il traffico proveniente dal browser (ad esempio guardare ai registri IIS). Il tuo server non si preoccupa di nulla riguardo all'utente diverso da come appare nel traffico. In particolare, tengo d'occhio le differenze tra le intestazioni di accettazione, che possono essere specifiche del browser e che potrebbero attivare un diverso percorso logico nel server, uno che tenta di impostare il tipo di contenuto su qualcosa che il browser dell'utente accetterà.

Ecco la mia supposizione selvaggia in risposta per ora:

Lo scopo di ResultsXml.aspx è quello di restituire un documento di qualche tipo; quel documento richiede un'app esterna (come un visualizzatore PDF o XML); lo restituisce con un content-disposition di inline; e il criterio di sicurezza locale del computer dell'ufficio disabilita la memorizzazione nella cache. In questo caso l'app visualizzatore di terze parti non troverà il file perché la cache non sarà presente.

Se mi sbaglio, si prega di inviare quanto sopra, e mi terrò indovinare :)