0

Has the HttpWebRequest.Timeout Property behavior changed between .NET 3.5 and 4.0? The documentation seems to imply so:

From the .NET 3.5 MSDN doc:

Timeout is the number of milliseconds that a subsequent synchronous request made with the GetResponse method waits for a response, and the GetRequestStream method waits for a stream. If the resource is not returned within the time-out period, the request throws a WebException with the Status property set to WebExceptionStatus.Timeout.

The .NET 4.0 doc adds this sentence right in the middle:

The Timeout applies to the entire request and response, not individually to the GetRequestStream and GetResponse method calls.

This seems to be a rather large change. The "entire request and response" could mean the entire time spent sending the request and receiving the response. This seems to contradict the previous sentence, since waiting for the response stream to be ready might be quick -- basically just the time for the server to retrieve/prepare the response -- but receiving the entire response over the stream could take a long time.

Has anyone compared this behavior between 3.5 and 4.0?

Jordan Rieger
  • 3,025
  • 3
  • 30
  • 50

1 Answers1

1

If you look at the code example on the .net code (msdn doc page that you reference) the request and response are two separate operations therefor the timeout operation on the request is copied to the response. So if the default is 100 ms it is 100 ms for the request and 100 ms for the response not an elapsed time of 100 for both.

Note that if you anticipate long running requests or responses consider asynchronous operations instead.

Mike Beeler
  • 4,081
  • 2
  • 29
  • 44
  • So why then does it say "The Timeout applies to the entire request and response, not individually to the GetRequestStream and GetResponse method calls"? It sounds like that's exactly the opposite behavior to what you're describing. – Jordan Rieger Nov 23 '12 at 06:20
  • 1
    This is a classic problem between those that construct the documentation and the developers. This is not the first case of badly worded documentation that I have seen, besides I verified the function in the source. – Mike Beeler Nov 23 '12 at 13:06
  • I've definitely seen bad MSDN docs before (http://stackoverflow.com/questions/9689839/msdn-documentation-error-if-the-procedure-is-shared-all-its-local-variables-a and http://stackoverflow.com/questions/12207222/decimal-10-9-variable-cant-hold-the-number-50-sql-server-2008 if you're bored and care to read :-) When you say you verified the function in the source, do you mean with something like Reflector or ILSpy? If so I really appreciate that. Either way I am going to submit a documentation bug report on Connect. – Jordan Rieger Nov 25 '12 at 01:47
  • Thanks for submitting the bug to connect! – Mike Beeler Nov 25 '12 at 07:20