2016-06-20 30 views
3

Wir haben eine MVC5/Razor-Anwendung, die letzte Woche plötzlich angefangen hat, wirklich seltsam zu handeln. Es ist auf einem Windows Server 2008 R2 (mit IIS 7.5) gehostet und das Problem begann nach der Installation von Windows-Updates letzte Woche. Bis dahin funktionierte die Anwendung gut.MVC5-Antragsformular führt zu mehreren Postanfragen beim Einreichen

Problem ist, dass, wenn ein Benutzer ein einfaches Formular aus 10 Textfeldern, 4 Textbereichen und einer Dropdown-Liste übermittelt, der Server nicht richtig reagiert, was zu einem "Error_Connection_Reset" (in Chrome)/"Page Nicht verfügbar "(in IE11).

Wir verwenden POST-Redirect-GET-Muster mit RedirectToAction in der Empfangsaktion in der Steuerung, die normalerweise zu einer 302 Antwort und Umleitung führen würde.

ist die Form, wie folgt wiedergegeben:

hat
@using (Html.BeginForm("Create", "Controller")) 
{ 
    @Html.AntiForgeryToken() 
    <div class="editor-fields"> 
     @Html.EditorFor(m => m.Model) 
    </div> 

    <div class="clear-fix"></div> 
    <div class="submit-area"> 
     <input type="submit" value="Submit" /> 
    </div> 
} 

Die Wirkung dieser Attribute:

  • [HttpPost]
  • [ValidateAntiForgeryToken]
  • [AllowAnonymous]
  • [ValidateInput(false)]

Wir verwenden auch Google Analytics und jQuery, jQuery validate, unaufdringlichen Ajax mit Optimierung (minification). Die meisten JS-Skripts sind in Scripts.Render enthalten.

Die Anwendung funktioniert einwandfrei, wenn wir von unserer eigenen Domäne darauf zugreifen, aber da alle unsere Benutzer Zugriff von außen benötigen, müssen wir diesen Fehler beheben. Dies könnte auf ein DNS-Problem hindeuten, aber unsere IT-Unterstützung sagt, DNS sieht gut aus und wurde in letzter Zeit nicht geändert.

Hier ist, was wir getan haben und fanden heraus, so weit:

  • Log-Datei in inetpub\logs\LogFiles zeigt mehr (zwischen 3 und 10) POST-Anfragen alle mit dem Statuscode 302, aber keine folgende GET-Anfrage. Und es sollte wirklich nur eine POST-Anfrage und dann eine GET-Anfrage geben!
  • Log-Datei in %windir%\System32\LogFiles\HTTPERR zeigt nichts Interessantes, nur eine Reihe von Timer_ConnectionIdle "Fehler", wenn die Website ihre Leerlauf-Timeout-Wert (das ist die Standardeinstellung 20 Minuten) erreicht.
  • Geprüfte Anfragen mit Fiddler und Dev-Tools in Chrome und IE11 und alle zeigt die gleichen Anfrage-Header. Mit Fiddler bekommen wir [Fiddler] ReadResponse() failed: The server did not return a complete response for this request. Server returned 0 bytes. In Chrome Dev Tools heißt es (failed) in der Statusspalte.
  • Deaktiviertes Caching und Komprimierung in IIS.
  • Gedreht Custom in web.config-Datei aus
  • Added <modules runAllManagedModulesForAllRequests="true"> in web.config
  • Gesuchter Google und SO nach Antworten, aber bisher ohne Erfolg
  • das kürzlich installierte Updates von Windows Update .NET 4.5 in Bezug auf überprüft .2 und damit verbundene Knowledge Base-Artikel, aber nichts, was
  • wurde schien im Zusammenhang mit diesem Problem erwähnt wirklich
  • Edit: Auch wir aktivierter Tracing Anforderungsfehler, aber wir nur nicht Anforderungsprotokolle für einen fehlenden favicon.ico in inetpub\logs\FailedReqLogFiles Ordnern
erhalten

Lustige Sache ist, dass, wenn ich ein Häkchen in "Deaktivieren Cache" in Chrome Dev Tools, die Anwendung auch gut funktioniert. Dies könnte darauf hindeuten, dass es sich um ein Caching-Problem handelt, weshalb wir auch versucht haben, Output Caching im IIS einzuschalten.

Unser nächster Schritt wäre, entweder einen neuen Server (Windows 2012 und eine neuere Version von IIS) zu starten und die Anwendung dort oder zu installieren WireShark auf unserem aktuellen Server installieren, um Anfragen weiter zu untersuchen. Aber wenn jemand dieses Verhalten erfahren hat und eine Lösung dafür kennt, dann reparieren wir es lieber für den Moment. Also, bitte, wenn jemand helfen kann, bitte Rat.

Antwort

0

Da das Problem anscheinend nur bei Benutzern außerhalb unserer Domäne auftrat, dachten wir, dass dieses Problem mit unserer Firewall zusammenhing. Daher kontaktierten wir unseren Firewall-Anbieter und bestätigten, dass ein Problem mit der neuesten Version der Firewall vorliegt Software. Wie es passierte, wurde die Firewall-Software am selben Tag aktualisiert, als Windows-Updates auf unserem Server installiert wurden, was wahrscheinlich ein wenig Verwirrung verursachte. Nach dem Zurücksetzen auf die vorherige Version der Firewall-Software ist das Problem verschwunden und alles funktioniert wieder wie erwartet. Puh!