Le serveur ne peut pas définir le statut après l'envoi des en-têtes HTTP IIS7.(5)

Question

Le serveur ne peut pas définir le statut après l'envoi des en-têtes HTTP IIS7.(5)

Parfois, je fais exception dans mon environnement de production:

information sur le procédé

ID de Processus: 3832

nom du procédé: w3wp.exe

Account name: NT AUTHORITYNETWORK SERVICE

information sur les exceptions

Type d'Exception: système.Web.HttpException

message D'Exception: le serveur ne peut pas définir le statut après l'envoi des en-têtes HTTP.

Demande d'informations

URL de la Requête: http://www.myulr.pl/logon

chemin de la demande: / connexion

user host adresse: 10.11.9.1

Utilisateur: user001

est authentifié: vrai

Type D'Authentification: Formulaires

Thread account name: NT AUTHORITYNETWORK SERVICE

Fil d'information

ID de Thread: 10

Thread account name: NT AUTHORITYNETWORK SERVICE

usurpe: False,

Stack trace: at System.Web.HttpResponse.set_StatusCode(Int32 value) at  
System.Web.HttpResponseWrapper.set_StatusCode(Int32 value) at  
System.Web.Mvc.HandleErrorAttribute.OnException(ExceptionContext filterContext) at  
System.Web.Mvc.ControllerActionInvoker.InvokeExceptionFilters(ControllerContext controllerContext, IList(1) filters, Exception exception) at  
System.Web.Mvc.ControllerActionInvoker.InvokeAction(ControllerContext controllerContext, String actionName) at System.Web.Mvc.Controller.ExecuteCore() at  
System.Web.Mvc.MvcHandler.<>c__DisplayClass8.<BeginProcessRequest>b__4() at  
System.Web.Mvc.Async.AsyncResultWrapper.<>c__DisplayClass1.<MakeVoidDelegate>b__0() at  
System.Web.Mvc.Async.AsyncResultWrapper.<>c__DisplayClass8(1).<BeginSynchronous>b__7(IAsyncResult _) at  
System.Web.Mvc.Async.AsyncResultWrapper.WrappedAsyncResult(1).End() at   
System.Web.Mvc.MvcHandler.EndProcessRequest(IAsyncResult asyncResult) at  
System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() at  
System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& ompletedSynchronously)

Je n'ai pas remarqué cette erreur sur mon environnement d'essai que dois-je vérifier?

j'utilise ASP.NET MVC 2 (Release Candidate 2)

66

asp.net-mvc http iis-7

demandé sur Joel Coehoorn 2010-03-05 01:21:53

10 réponses

score 58 · Answer 1

Je suis d'accord avec Vagrant sur la cause:

votre action a été en cours d'exécution, l'écriture de balisage de flux de réponse
le flux a été libéré forçant les en-têtes de réponse à obtenir écrit avant que l'écriture de balisage pourrait commencer.
votre vue a rencontré une erreur d'exécution
gestionnaire d'Exception coups de pied en essayant de définir le code d'état à quelque chose de non-200
Échoue parce que les en-têtes ont déjà été envoyés.

où je ne suis pas d'accord avec Vagrant est le remède" cause no errors in binding " - vous pouvez encore rencontrer des erreurs d'exécution en vue binding par exemple des exceptions de référence nulles.

une meilleure solution pour cela est de s'assurer que Response.BufferOutput = true; avant tout bytes sont envoyés au flux de réponse. par exemple dans votre action controller ou On_Begin_Request dans l'application. Cela permet les transferts de serveur, cookies / headers à définir, etc. droit de la voie jusqu'à la réponse de fin naturelle, ou l'appel d'extrémité/chasse d'eau.

bien sûr aussi vérifier que le tampon n'est pas rincé/réglé à false plus bas dans la pile aussi.

référence MSDN: HttpResponse.BufferOutput

score 44 · Answer 2

juste pour ajouter aux réponses ci-dessus. J'ai eu ce même problème quand j'ai commencé à utiliser ASP.Net MVC et moi faisions une réponse.Rediriger pendant une action de controller:

Response.Redirect("/blah", true);

au lieu de retourner un Response.Redirect action j'aurais dû retourner un RedirectAction :

return Redirect("/blah");

score 14 · Answer 3

le serveur HTTP ne renvoie pas l'en-tête de réponse au client tant que vous n'avez pas spécifié une erreur ou que vous n'avez pas commencé à envoyer des données. Si vous commencez à renvoyer des données au client, alors le serveur doit d'abord envoyer la tête de réponse (qui contient le code d'état). Une fois que la tête a été envoyé, vous ne pouvez plus mettre un code d'état dans l'en-tête, évidemment.

Voici le problème habituel. Vous démarrez la page, et envoyez quelques tags initiaux (i.e. <head> ). Le serveur envoie ensuite ces balises au client, après avoir d'abord envoyé L'en-tête de réponse HTTP avec un statut de succès supposé. Maintenant vous commencez à travailler sur la viande de la page et de découvrir un problème. Vous ne pouvez pas envoyer d'erreur à ce point parce que l'en-tête de réponse, qui contiendrait le statut d'erreur, a déjà été envoyé.

la solution est la suivante: avant de générer du contenu, vérifiez s'il va y avoir des erreurs. Alors seulement, lorsque vous avez affirmé qu'il n'y aura pas de problèmes, vous pouvez alors commencer à envoyer du contenu, comme la balise.

dans votre cas, il semble que vous ayez une page de connexion qui traite une demande de poste à partir d'un formulaire. Vous jetez probablement un HTML initial, puis vérifiez si le nom d'utilisateur et le mot de passe sont valides. Au lieu de cela, vous devez authentifier l'utilisateur/mot de passe en premier, avant de générer tout HTML du tout.

score 11 · Answer 4

j'ai eu le même problème avec le réglage StatusCode et puis Response.End dans HandleUnauthorizedRequest méthode de AuthorizeAttribute

var ctx = filterContext.HttpContext;
ctx.Response.StatusCode = (int)HttpStatusCode.Forbidden;
ctx.Response.End();

si vous utilisez .NET 4.5+, ajouter cette ligne avant Response.StatusCode

filterContext.HttpContext.Response.SuppressFormsAuthenticationRedirect = true;

si vous utilisez .NET 4.0, essayez SuppressFormsAuthenticationRedirectmodule .

score 9 · Answer 5

Que Diriez-vous de vérifier ceci avant de faire la redirection:

if (!Response.IsRequestBeingRedirected)
{
   //do the redirect
}

score 3 · Answer 6

vous essayez en fait de rediriger une page qui a une réponse à lancer. Donc tout d'abord vous gardez les informations que vous avez jeter dans un tampon en utilisant response.buffer = true au début de la page et puis le rincer si nécessaire en utilisant response.flush cette erreur sera corrigé

score 1 · Answer 7

je me souviens de la partie de cette exception:" ne peut pas modifier les en - têtes d'information-headers déjà envoyés par " se produisant en PHP. Cela s'est produit lorsque les en-têtes étaient déjà envoyés dans la phase de redirection et que toute autre sortie était générée, par exemple:

echo "bonjour"; en-tête ("Location: ) http://stackoverflow.com ");

Pardonnez-moi et corrigez-moi si je me trompe, mais j'apprends encore les Technologies de la SP et j'essayais d'aider.

score 1 · Answer 8

Je m'excuse, mais j'ajoute mes 2 cents au fil juste au cas où quelqu'un aurait le même problème.

J'ai utilisé L'authentification des formulaires dans mon application MVC
mais certaines actions du contrôleur étaient "anonymes" , c'est-à-dire permises aux utilisateurs non authentifiés
parfois dans ces actions je voudrais encore veut que les utilisateurs soient redirigés vers le formulaire de connexion à certaines conditions
à faire que - j'ai ceci dans ma méthode d'action: return new HttpStatusCodeResult(401) - et ASP.NET est super agréable à détecter cela, et il redirige l'utilisateur à la page de connexion! Magique, non? Il a même le paramètre approprié ReturnUrl , etc.

mais vous voyez où je veux en venir? J' retour 401 . Et ASP.NET redirige l'utilisateur. Qui est essentiellement renvoie 302 . Un code d'état est remplacé par un autre.

et certains Les serveurs IIS (juste quelques!) jeter cette exception. Certains n'en ont pas. - Je ne l'ai pas sur mon test serevr, seulement sur mon serveur de production (n'est-ce pas toujours le cas o_O)

je sais que ma réponse est essentiellement de répéter ce qui est déjà dit ici, mais parfois il est juste difficile de comprendre où cette réécriture se produit exactement.

score 0 · Answer 9

si quelqu'un a encore ce problème.Essayez d'utiliser à la place de ovverriding

 public void OnActionExecuting(ActionExecutingContext context)
    {
        try
        {

            if (!HttpContext.Current.User.Identity.IsAuthenticated)
            {
                if (!HttpContext.Current.Response.IsRequestBeingRedirected)
                {

                    context.Result = new RedirectToRouteResult(
                new RouteValueDictionary {  { "controller", "Login" }, { "action", "Index" } });
                }
            }

        }
        catch (Exception ex)
        {
               new RouteValueDictionary { { "controller", "Login" }, { "action", "Index" } });
        }

    }

score 0 · Answer 10

nous avons eu la même erreur - donc cela peut être utile à certains.

pour nous, la cause était très simple. Un changement d'interface a déconcerté un utilisateur final et il a appuyé sur le bouton arrière du navigateur au "mauvais" moment après la soumission d'un formulaire (bien sûr, nous aurions probablement dû utiliser un modèle PRG, mais nous ne l'avons pas fait).

nous avons réglé le problème et l'utilisateur n'appuie plus sur le bouton arrière. Le problème est résolu.

Las etiquetas más populares

Le serveur ne peut pas définir le statut après l'envoi des en-têtes HTTP IIS7.(5)

10 réponses