So:
replace

request.GetResponse();

by

request.GetResponse().Close();

And it will work! (I’ve been searching on the same problem for quite a while now)
Upping the connection limit because of this is a bad idea (and against the RFC guidelines: max 2 concurrent connections)

<connectionManagement>
<clear/>
<add address="*" maxconnection="100" />
</connectionManagement>

– It appears the clear tag is necessary, since before adding that line I was still only able to maintain two connections. My guess is that some default ASP.NET configuration sets maxconnection="2" so you have to remove that first.

Thanks again, and I hope this is helpful to your readers if they are working with web projects.

While your suggestion may in fact work, I wonder if it’s the best way to go about resolving the two concurrent connection limitation.

Off the top of my head I can’t think of any good reasons why it would be wrong to Abort the request except that it seems a bit of a "hack." I have typically seen the Abort method used when you need to abort an asynchronous web request if a specified period of time has expired (e.g. the resouce is unavailable), not to Abort an otherwise successful request/response.

The HttpWebRequest does not implement IDisposable, so I don’t believe there’s any reason to explicitly try to close, abort, or otherwise dispose of the object (unlike HttpWebResponse, which does implement IDisposable).

Any reason you’d rather Abort the method instead of change the underlying configuration to allow more than two concurrent connections?

Thank you for sharing your idea!

The reason I’m in this mess is that all the example code (even on MSDN) doesn’t close the connection and so reaches this 2 connection limit.

I just added a Request.Abort(); after dealing with the response and all seems well for an unlimited number of times now!