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.

War es hilfreich?

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).

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top