You receive one or more error messages when you try to make an HTTP request in an application that is built on the .NET Framework 2.0


Please send me a message or leave a comment to let me know if this Post helped you! 


When you try to make an HTTP request in an application that is built on the .NET Framework, you may receive one or more of the following error messages or Exceptions.


One of the first things you should do is see what the framework is doing.  Get a System.Net trace: http://blogs.msdn.com/jpsanders/archive/2009/03/24/my-favorite-system-net-trace-configuration-file-dumps-process-id-and-date-time-information.aspx


Then you can get a description of the errors here (note this is an enumeration which is the status member of the WebException):
http://msdn.microsoft.com/en-us/library/system.net.webexceptionstatus(VS.80).aspx


Many of these errors are the same in the 1.1 .NET framework:
http://support.microsoft.com/kb/915599


Some of these errors can be trapped and immediately retried such as:


System.Net.WebExceptionStatus.ConnectFailure:
System.Net.WebExceptionStatus.KeepAliveFailure:
System.Net.WebExceptionStatus.RequestCanceled:
System.Net.WebExceptionStatus.ConnectionClosed:
System.Net.WebExceptionStatus.SendFailure:
System.Net.WebExceptionStatus.PipelineFailure:
System.Net.WebExceptionStatus.UnknownError:

 

Errors: 

 

The underlying connection was closed: The remote name could not be resolved

 

This is a DNS error.  For some reason the server name cannot be resolved.  Do you have permissions to the HOST file?  Is this a service such as ASP.NET?  See this article for help: The underlying connection was closed: The remote name could not be resolved.  Also look at this KB: http://support.microsoft.com/kb/330221

 

 

The underlying connection was closed: Unable to connect to the remote server

 

This is a connection issue.  The DNS resolved the server name but something is preventing the client from connecting to the server.  Lookup the error in this article http://support.microsoft.com/kb/915599

 

 

The underlying connection was closed: An unexpected error occurred on a receive

 

This problem occurs when the server or another network device unexpectedly closes an existing Transmission Control Protocol (TCP) connection.  Lookup the error in this article http://support.microsoft.com/kb/915599

 

 

The underlying connection was closed: An unexpected error occurred on a send

 

This problem occurs when the client computer cannot send an HTTP request. The client computer cannot send the HTTP request because the connection has been closed or is unavailable.  Lookup the error in this article http://support.microsoft.com/kb/915599.  Antivirus software can interfere with the send as well.  If the stack from the exception includes something similar to this:

System.IO.IOException: Authentication failed because the remote party has closed the transport stream.

It is possible that the server is an older server does not understand TLS and so you need to change this as specified in the 915599 kb to something like this:

ServicePointManager.SecurityProtocol= SecurityProtocolType.Ssl3;
Before you make any HTTPS calls in your application.

The underlying connection was closed: A pipeline failure occurred

 

Pipelined requests are requests sent out on the same socket without waiting for a reply (http://search.live.com/search?q=http+pipelined+request).  All HTTP 1.1 servers are required to support pipelining.  In general if you see this error it is probable related to a network related failure.  You could turn off pipelining and try to see what the underlying issue is but pipelining itself is rarely the cause of this error message.  You should retry the request if you get this error but if you get this exception multiple times, you should troubleshoot the root cause.

 

The underlying connection was closed: The request was canceled


The underlying connection was closed: The connection was closed unexpectedly

 

This occurs with the server cancels the request with a TCP RST (reset).  The server may do this because of the thread Execution Timeout Setting being too low and it is tearing down the thread that is processing the request (Thread Abort Exceptions may be logged):  http://msdn.microsoft.com/en-us/library/e1f13641.aspx

Also check and ensure the Keep-Alive timeouts on the server, load balancer and client (.NET) are set so that the client is set to less than the load balancer, which in turn is set less than the server.  See this article as well:

 

The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel

 

For a service application the whole certificate chain needs to be in the LOCAL_MACHINE store.  This means the Root in the Trusted Root Certificate and all the Intermediate Certificates in the Trusted Intermedeate store.  For applications that run in the context of the logged on user, If Internet Explorer does not have any Certificate problems, then the .NET application should work fine.  Often people will find that Internet Explorer is fine and only the ASP.NET or Service application fails.  This is because the root and intermediate certificates are installed correctly in the user store but not the local machine store.

You can dump out what the failure is by using this delegate: http://msdn.microsoft.com/en-us/library/system.net.security.remotecertificatevalidationcallback.aspx.  Finally you could use process monitor and verify that there are no access denied errors when trying to access the certificate store which would prevent reading the certificates.

 

The request was aborted: Could not create SSL/TLS secure channel

 

Lookup the error in this article http://support.microsoft.com/kb/915599  Resolution J.  It also may be that you are not supplying a client certificate.  Most likely this is an issue with TLS or SSL3 being used and the server not understanding it.

 

Error: The server committed a protocol violation

 

The Exception will tell what the HTTP protocol violation is: 

The server committed a protocol violation. Section=ResponseHeader Detail=Header
name is invalid”

Fix the server to conform to the HTTP RFCs to avoid this error.  .NET is a stickler that the HTTP Protocol be followed.

 

The underlying connection was closed: A connection that was expected to be kept alive was closed by the server

 

Specifically a Keep-Alive connection was torn down before it should have been.  This is often caused because the MaxIdleTimeout setting in the client is greater than that of the server or intermediate network device (load balancer or proxy).


 

The operation has timed out

 

This could be caused by a stale DNS entry for a proxy or if a request is not received before the socket times out.

An example of this Exception is when for example a server returns information but does not correctly set the content-length header.  The call will wait for the rest of the data (which will never come) until it throws this message.  It could be that the server takes a long time to respond (which is a different issue) and you could increase System.Net.ServicePointManager.DefaultConnectionLimit.  This could also be because you are issuing a lot of request and have not increased the DefaultMaxConnections for your application and the timeout happens waiting for a connection thread to process your request.  MaxConnections can be set in the application.config file or in code.

 

The proxy name could not be resolved

 

This is a DNS issue.  Find out what proxy it is looking for (from the System.Net trace) and find why this does not resolve in your network.

 

The request was aborted: The request cache-only policy does not allow a network request and the response is not found in cache

The request was aborted: The request could not be satisfied using a cache-only policy 

 


The request was not permitted by the cache policy. In general, this occurs when a request is not cacheable and the effective policy prohibits sending the request to the server. You might receive this status if a request method implies the presence of a request body, a request method requires direct interaction with the server, or a request contains a conditional header. 


If you do this and the file in not cached, then you will get this error.



 

 

Comments (18)

  1. Stefan says:

    Very useful, thanks! I’ve been having a lot of issues hunting down some unhelpful exceptions in a .NET CF application – this post is a huge help towards understanding and diagnosing them.

  2. Jeff Sanders says:

    Thanks for the comment.  I am glad this helped you out!

  3. Doug Collier says:

    Hi,

    Great info here – many thanks.  I have an issue here that’s interesting.  IIS7 asp.net web site that make calls out to several different types of web services.  One of them requires SSL (not TLS).  So…I set the ServicePointManager.SecurityProtocolType = SecurityProtocolType.Ssl3 | SecurityProtocolType.Tls

    Still doesn’t work.  Perhaps the remote server isn’t negotiating well.  So….I force it to Ssl3 by just doing this:  ServicePointManager.SecurityProtocolType = SecurityProtocolType.Ssl3

    Now it works.  However, I don’t want to set this setting system wide, I would much prefer to set this on a per service point basis so that I don’t affect all the other outbound web service calls we make.

    Right now, I’m using the setting above that works and immediately returning to the previous value after the call.  But, this isn’t ideal.

    Any advice?

    thanks much

    -doug

    doug.collier <at> support <dot> com

  4. Jeff Sanders says:

    Hi Doug,

    You should be able to do this (but I have not tried it yet).  Since there is only one site you are having difficulty with you can simply change the ServicePointManager.SecurityProtocolType, then call FindServicePoint (http://msdn.microsoft.com/en-us/library/system.net.servicepointmanager.findservicepoint(VS.80).aspx) and then set it back to the previous value.

    Note that you would want to do this on startup because once the ServicePoint is created, it will be used for the lifetime of your app and you cannot change this value.  Global.asax would be a good place.

    Please let me know how this works out for you!

    -Jeff

  5. Janne says:

    Thanks, your post helped, I had problems in http request over SSL and setting this

    ServicePointManager.SecurityProtocol= SecurityProtocolType.Ssl3 helped!

    – Janne

  6. Jeff Sanders says:

    That is great!  Thanks for the feedback Janne!

  7. Dennis says:

    This compilation is very helpful. We have encountered a problem that one of our programs stopped working on Windows 7: IOException: Authentication failed because the remote party has closed the transport stream.

    Setting the security protocol to only use SSL helped.

  8. Rajat Khattar says:

    Very Useful post……ServicePointManager.SecurityProtocol= SecurityProtocolType.Ssl3 one helped me a lot

  9. Falgun says:

    Nice Article, it helped me a lot. WebExceptionStatus.Connectfailure means our request is not reached to server in any case, this is what is understand… Is it right… If wrong pls correct me

  10. Jeff Sanders says:

    Hey Falgun,

    ConnectFailure means that the socket could not be opened at the TCP level.  A firewall or proxy could prevent you from reaching the server.  A good way to troubleshoot this would be to write a simple .NET console application that tries to hit the same resource and running in the context of the logged on user.

  11. Susan H says:

    Oh Hey!  Great, the ServicePointManager.SecurityProtocol= SecurityProtocolType.Ssl3; is what worked for me!  I've been looking for this answer for days!

  12. Rich says:

    Wonder if you can help…

    I'm getting the error

    System.IO.IOException: Authentication failed because the remote party has closed the transport stream.

    It is possible that the server is an older server does not understand TLS and so you need to change this as specified in the 915599 kb to something like this:

    ServicePointManager.SecurityProtocol= SecurityProtocolType.Ssl3;

    Changing the SecurityProtocol does fix this issue.

    The problem I have is, this error is only happening when commuicating with 1 particular server (not in my control) other servers happily work when the SecurityProtocol is Ssl3 | Tls.

    From my understanding setting the ServicePointManager.SecurityProtocol= SecurityProtocolType.Ssl3; is a global change and would mean all https request ould use Ssl3, I'd like the ability to set the SecurityProtocol per web request is that possible? infact why is it a static property on the ServicePointManager? why isn't a property of a servicepoint?

  13. Jeff Sanders says:

    Rich,

    This setting will affect the creation of the service point.  So you can set this before any requests to that URL, then set it back for the other service points.

  14. Anton Tykhyy says:

    I don't like juggling the ServicePointManager.SecurityProtocol setting, so here's a shameless plug for my solution to the Tls/Ssl3 problem: create a separate AppDomain to make Ssl3 requests.

    stackoverflow.com/…/how-to-use-ssl3-instead-of-tls-in-a-particular-httpwebrequest

  15. Jeff Sanders says:

    Thanks Anton, that will work as well!

  16. abhilash says:

    Great post… all related information on the same page.

    A quick question though, under the "operation has timed-out" section you have mentioned setting the MaxConnections property. I think there was a limitation in .NET 1.1 where we had to set this explicitly based on the numbers of processors and all, I think since 2.0 this need not be done due to the AutoConfig=true setting under ProcessModel. Can you please confirm if this still needs to be done for a .Net 3.5 ASP .NET application. Thanks

  17. ufuk says:

    i get this error.

    Authentication failed because the remote party has closed the transport stream

    i use Microsoft.UnifiedCommunications.AJAX.dll on my project

    the httprequest is in this dll

    how do i solve this problem?

    sorry my bad English.

  18. Jeff Sanders says:

    Hi U,

    Your English is great!

    Did you follow the suggestions in this post and the questions others had?  These hints have solved the problems most of the time. If this did not solve the issue, I would suggest you open a support incident to investigate further.  It would be too difficult to try and solve this via a Blog post!  You can do this by going to support.microsoft.com/oas .  Choose Ajax as your product.

    -Jeff