0

When I call .Abort() method of the request right after calling GetResponseAsync(), the request still does not abort instantly. There is significant (2-3 sec) delay before the abort actually happens.

As it seems, HttpWebRequest is first resolving host name and setting up a connection. So if the host name is wrong, or DNS server is dead, or the host itself does not respond, .Abort() will take ages to close the connection and abort the request.

Is there a way to instantly abort the operation and close the connection without waiting for these operations (hostname lookup, host connection setup, etc.) to complete?

mephisto123
  • 1,400
  • 13
  • 38

1 Answers1

1

The DNS resolution happens synchronously and the abort won't be effective until it's complete (or failed). There isn't much you can do about it, except execute the request in a separate thread and just "forget" about it when you need to abort.

Thomas Levesque
  • 286,951
  • 70
  • 623
  • 758
  • Is there any alternative to HttpWebRequest that can support both async requests and instant abortion? – mephisto123 Jan 25 '14 at 22:31
  • @mephisto123, unfortunately, no there isn't. The framework has other APIs to communicate over HTTP (WebClient, HttpClient), but they both rely on HttpWebRequest, so they have the same issue. – Thomas Levesque Jan 25 '14 at 22:42
  • Thanks for the response. I was expecting this but didn't want to believe :( I'll mark your answer as correct. – mephisto123 Jan 25 '14 at 22:45
  • @ThomasLevesque Is it documented DNS happens synchronously? I had a [related problem](http://stackoverflow.com/q/21007112/11683). – GSerg Jan 25 '14 at 22:55
  • According to the MSDN ( http://msdn.microsoft.com/ru-ru/library/system.net.httpwebrequest.begingetresponse(v=vs.110).aspx ) manual for BeginGetResponse, it happens synchronously in old async methods. And I guess that new async/await HttpWebRequest API is just wrappers for old async methods. – mephisto123 Jan 25 '14 at 23:28
  • @mephisto123, actually, the doc for GetResponseAsync says that it doesn't block; but if you look at the implementation, you'll see that it is indeed just a wrapper around (Begin/End)GetResponse... – Thomas Levesque Jan 25 '14 at 23:38
  • GetResponseAsync doesn't block. Only because it does synchronous operations in another thread. But these operations are still synchronous as you mentioned in the answer. – mephisto123 Jan 25 '14 at 23:42
  • 2
    @mephisto123, you're correct... It *is* a wrapper around the Begin/End methods, but it *does* run in a separate thread. That's actually a bad thing: task-based async methods shouldn't start new threads; only intrinsically async methods should have an async signature... Starting a new thread should be the responsibility of the caller. – Thomas Levesque Jan 26 '14 at 00:09
  • I think it is not really creating a new thread always. Since it's using ThreadPool most likely it'll let following requests to reuse created thread after completing synchronous part of the request. Should investigate it though. – mephisto123 Jan 26 '14 at 07:24