SOAP-Dienste Anrufe von IIS 5.1 (XP) Ablaufen
-
20-09-2019 - |
Frage
Wir haben eine ASP.NET Web-Anwendung in IIS ausgeführt wird, die Soaphttpclientprotocol-Klasse verwendet SOAP, Anrufe zu tätigen. In den letzten Tagen mehrere XP-Maschinen zu berichten Timeout-Fehler haben damit begonnen, wenn SOAP-Dienste Anrufe.
Stack-Trace aus einem Test-App:
System.Net.WebException: The operation has timed out
at System.Web.Services.Protocols.WebClientProtocol.GetWebResponse(WebRequest request)
at System.Web.Services.Protocols.HttpWebClientProtocol.GetWebResponse(WebRequest request)
at System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[] parameters)
at TestWS.localhost.Service1.HelloWorld() in C:\Prototypes\TestWS\Web References\localhost\Reference.cs:line 78
at ASP.default_aspx.__Renderform1(HtmlTextWriter __w, Control parameterContainer) in c:\Inetpub\wwwroot\TestWS\Default.aspx:line 17
Verwenden von TCP / Trace und Wireshark können wir sehen, dass der Header der Anforderung gesendet wird, aber nicht den Inhalt. Allerdings ist die Content-Length HTTP Parameter korrekt ist, es ist fast so, als ob der Inhalt Strom nicht gewesen gespült hat.
Wir vermuten, dass ein Microsoft-Update dieses Problem verursacht hat. Potenziell KB970430 , KB971737 und KB968389 . Das Problem scheint zu IIS 5.x (XP-Version von IIS) isoliert werden.
Lösung
UPDATE . Dies erwies sich als ein Problem mit ESET sein Anti-Virus auf dem Web-Server ausgeführt wird und Durchführung on-the-fly Überprüfung von HTTP-Verbindungen vom Webserver auf einen SOAP-Server
Ausführliche Beschreibung : Für die Aufzeichnung ist dies ein Fehler im HTTP-Protokoll Handhabung in .NET. Das Szenario ist wie folgt:
Client sendet Header von HTTP POST:
POST /WS/Test.asmx HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; MS Web Services Client Protocol 2.0.50727.3603)
Content-Type: text/xml; charset=utf-8
SOAPAction: "http://testuri.org/HelloWorld"
Host: loadtest-app
Content-Length: 288
Expect: 100-continue
Connection: Keep-Alive
Der Inhalt wird nicht wegen der Expect gesendet: 100-Continue. Der Server antwortet nun:
HTTP/1.1 100 Continue
An diesem Punkt der Client reagiert nicht. Eine Abhilfe hierfür ist die 100-weiter zu deaktivieren, die im wesentlichen der Request-Header und Inhalte zwingen in einem Chunk gesendet werden. Dies kann mit der web.config getan werden:
<system.net>
<settings>
<servicePointManager expect100Continue="false"/>
</settings>
</system.net>
Wenn wir jedoch auch clientseitige Ablaufprotokollierung auf dann ein Protokoll Ausnahme Schalter ausgelöst besagt, dass CR sollte von LF in HTTP-Header folgen. Es erscheint in der .Net-Netzwerk-Logik irgendwo etwas zerbrechlich Code. Und um dies zu rekapitulieren ist nur ein Problem mit ASP.NET in IIS 5.1 (die Version, die läuft auf XP).