From Googling around I think this means that the server closed the TCP connection.
- He might wanna try a different server to exclude issues with a particular server.
- different headers might be used for troubleshooting ( TRACE header for example would instruct the server to return the packets you sent to it).
In case of issues with the http i would not start with POST, because that's the most difficult.Instead he should try a GET first to see how the server answers.
- a network sniffer like WireShark might be used to figure out where the problem is very quickly - if one is familar with the usage of these tools.
For me a sniffer is the first choice because i can see what's going on there immediatly.
Engels Rajangam : The underlying connection was closed... This article suggests that setting WebRequest.KeepAlive to false might help with this sort of error - it defaults to true.
KeepAlive is integral part of the HTTP1.1 protocol.Therefore it is always enabled with HTTP 1.1, in contrast to 1.0, where the KeepAlive had to be enabled explicitly.Most servers support 1.1, so this is certainly not the cause of the issue.
As i already said above, POST is not a good point to start with.Once a GET is working, this would be the proof that the routines work in general and the internet connection is ok.One could then proceed to test with POST headers.
From my personal experience ( i also do a lot with these POSTs on the device)
i would say, the error message mean, there is either a problem with the internet connection itself, the server connection ( does not accept the connection) or the DNS name resolution.
I also use an errorhandler in my http send routine and whenever the errorhandler traps an error this means i do not have established an internet connection.Therefore i use this as indicator whether the connection is there or not ( due to lack of description of the error - i do not use your new library yet which returns descriptions ...;-) )
kind regards
TWELVE