Kann das HttpWebRequest-Timeout bei einem POST nicht länger als 100 Sekunden eingestellt werden?

8

Ich stoße auf ein Problem, bei dem HttpWebRequest einen Zeitüberschreitungswert von mehr als 100 Sekunden bei einem POST nicht berücksichtigt. Wenn es sich bei der Anforderung jedoch um einen GET handelt, wird ein Zeitüberschreitungswert von mehr als 100 Sekunden berücksichtigt. Die Timeout-Ausnahme wird beim Aufruf von .GetResponse () ausgelöst. Ich setze alle Zeitüberschreitungswerte, die ich entdecken konnte, aber es scheint, dass ich einen vermisse, oder es gibt einen Bug im Framework.

Dies ist eine C # -App, die auf das mit Visual Studio 2008 erstellte .NET Framework 3.5 abzielt. Der Webserver ist IIS 6.0 mit einer Verbindungszeitüberschreitung von 120 Sekunden, Keep-Alives aktiviert ... GET-Anforderungen werden erneut berücksichtigt Zeitüberschreitungswert, den ich angeben, POST-Anforderungen berücksichtigen das Zeitlimit, wenn & lt; = 100 Sekunden.

Hier ist mein Code:

%Vor%

Wenn ich den Timeout-Wert auf 5 Sekunden eingestellt habe, erhalte ich eine Timeout-Ausnahme nach 5 Sekunden, wie man es erwarten würde. Dies beweist, dass der Timeout-Wert nicht vollständig ignoriert wird.

Ist jemand anderes auf dieses Problem gestoßen? Wird die Verwendung der Async-Version von GetResponse dieses Problem umgehen? Irgendwelche Gedanken willkommen, ich bin seit ein paar Tagen dran.

AKTUALISIEREN

Ich kann den POST veranlassen, den Timeout-Wert einzuhalten, wenn ich keine Daten posten (was nicht sehr nützlich ist). Sobald ich jedoch irgendwelche Daten gepostet habe und ContentLength ist & gt; 0, Timeout bei 100 Sekunden. Auch sind keine Proxies beteiligt.

UPDATE 2

Dem Beispiel wurden die POST-Daten und ein Kommentar hinzugefügt, wo NICHT die Timeout-Eigenschaft

festgelegt werden sollte     
thein 20.10.2011, 21:51
quelle

2 Antworten

17

Ich habe es herausgefunden. Dies ist ein Beispiel für DRY-Codierung, die zurückkommt und mich in den Hintern beißt. Der Code oben ist eine Umschreibung meines echten Codes und als solcher wird der obige Code gut funktionieren.

Das Problem war, dass ich den Timeout -Wert festlegte, nachdem ich proxyRequest.GetRequestStream () bereits aufgerufen hatte, um die POST-Daten hinzuzufügen. Da ich sowohl die Eigenschaften Timeout als auch ReadWriteTimeout festlegte, war das kürzeste Timeout erfolgreich. Im Falle einer POST-Anfrage, obwohl das Framework ließ ich den Timeout-Wert nach einem Aufruf von GetRequestStream, ignoriert es, was Wert gesetzt wurde (und stattdessen die Standard 100 Sekunden, obwohl die Überprüfung der Timeout-Eigenschaft nach der Einstellung zeigte, war es eingestellt zu, was ich erwartete). Ich wünschte, die Timeout-Eigenschaft würde genauso funktionieren wie die ReadWriteTimeout-Eigenschaft: Wenn Sie versuchen, die ReadWriteTimeout-Eigenschaft nach dem Aufruf von GetRequestStream zu setzen, wird eine Ausnahme ausgelöst. Wenn Timeout das Gleiche tun würde, hätte mir das eine Menge Zeit gespart. Ich hätte das eher fangen sollen, aber ich werde es auf eine Lernerfahrung ansetzen.

Also die Moral der Geschichte: Setzen Sie alle Timeout-Eigenschaften für Ihre HttpWebRequest richtig, wenn Sie es erstellen.

    
thein 28.10.2011, 18:11
quelle
3

Haben Sie einen Web-Proxy zwischen Ihrem Client und dem Server? Vielleicht nutzt das ein Timeout selbst.

Ich schlage vor, dass Sie Wireshark verwenden, um zu sehen, was auf der Netzwerkebene passiert - und insbesondere, ob im Netzwerk nach 100 Sekunden etwas passiert.

    
Jon Skeet 20.10.2011 22:31
quelle