Obtention d'une exception EOF via l'appel https

Question

Demande de code https. Ceci est mon code

HttpWebRequest request = (HttpWebRequest)WebRequest.Create(UploadUrl); 
      request.Method = "POST"; 
      request.KeepAlive = false; 
      request.Credentials = new NetworkCredential(userid, testpwd); 

      postData = "<root></root>"; 
      request.ContentType = "application/x-www-form-urlencoded"; 

      byte[] postDataBytes = Encoding.UTF8.GetBytes(postData); 
      request.ContentLength = postDataBytes.Length; 

      Stream requestStream = request.GetRequestStream(); 
      requestStream.Write(postDataBytes, 0, postDataBytes.Length); 
      requestStream.Close(); 

      using (HttpWebResponse response = (HttpWebResponse)request.GetResponse()) 
      { 
       StreamReader responseReader = new StreamReader(response.GetResponseStream(), Encoding.UTF8); 
       var result = responseReader.ReadToEnd(); 
       responseReader.Close(); 
       Console.WriteLine(result); 
      } 

Ce code a été en cours d'exécution bien mais tout d'un jet soudain exception suivante

System.Net.WebException 

Le message d'exception est: La connexion sous-jacente a été fermée: Une erreur inattendue est survenue sur un envoi.

Trace de pile: à System.Net.HttpWebRequest.GetRequestStream (TransportContext & contexte) à System.Net.HttpWebRequest.GetRequestStream() à CustomerProcessor.Delivery.Deliver (teneur en String, Int32 ProductCategory, identificateur de chaîne , String xsltFile)

l'exception est une exception interne: une exception: System.IO.IOException le message d'exception est: reçu une EOF ou 0 inattendus octets à partir du flux de transport.

Trace de pile: à System.Net.FixedSizeReader.ReadPacket (byte [] buffer, Int32 offset, compte Int32) à System.Net.Security.SslState.StartReadFrame (byte [] buffer, Int32 readBytes, AsyncProtocolRequest asyncRequest) à System.Net.Security.SslState.StartReceiveBlob (byte [] buffer, AsyncProtocolRequest asyncRequest) à System.Net.Security.SslState.CheckCompletionBeforeNextReceive (message ProtocolToken, AsyncProtocolRequest asyncRequest) à System.Net.Security.SslState.StartSendBlob (Byte [] incoming, Int32 count, AsyncProtocolRequest asyncRequest) à System.Net.Security.SslState.ForceAuthentication (Boolean receiveFirst, Octet [] buffer, AsyncProtocolRequest asyncRequest) à System.Net.Security.SslState.ProcessAuthentication (LazyAsyncResult lazyResult) à System.Net.TlsStream.CallProcessAuthentication (état de l'objet) à System.Threading.ExecutionContext.runTryCode (Object userData) à System.Runtime.CompilerServices.RuntimeHelpers .ExecuteCodeWithGuaranteedCleanup (Code TryCode, CleanupCode backoutCode, Object userData) à System.Threading.ExecutionContext.RunInternal (ExecutionContext executionContext, ContextCallback callback, État de l'objet) à System.Threading.ExecutionContext.Run (ExecutionContext executionContext, Callback Contexte Callback, état Object) à System.Net.TlsStream.ProcessAuthentication (résultat LazyAsyncResult) à System.Net.TlsStream.Write (tampon Byte [], décalage Int32, taille Int32) à System.Net.PooledStream.Write (Byte [] tampon, Int32 offset, taille Int32) à System.Net.ConnectStream.WriteHeaders (Boolean async)

Est-il possible de voir ce qui pourrait être la cause de cette problème?

Answer 1

Ajouter cet appel avant demande m'a aidé:

ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3; 

Donc, si vous utilisez https tentent de changer le SecurityProtocol par défaut.

Answer 2

Je ne sais pas pourquoi (d'autant plus que ça va à l'encontre des docs que j'ai vus sur le sujet) mais j'ai trouvé que laisser de côté l'affectation de RequestLength. Au lieu de cela, écrivez simplement dans le flux de requête sans définir l'en-tête.

Cela a aussi l'avantage que:

using(Stream stm = req.GetRequestStream()) 
using(StreamWriter sw = new StreamWriter(stm)) 
{ 
    sw.Write(postData); 
} 

est à mon avis plus simple, ainsi que d'avoir plus d'avantages dans les cas où les données est plus grande et pièce écrite par pièce, ou vient de quelque chose comme un XMLWriter qui peut être configuré pour écrire directement dans le flux en question.

Answer 3

Autre cause possible: si vous utilisez Windows Server 2003, il ne prend en charge que SSL 2.0, SSL 3.0, TLS 1.0. Tous ces protocoles sont maintenant recommandés pour être désactivés à la lumière des exploits récents qui ont été trouvés pour ces protocoles, de sorte que vous pouvez trouver qu'un serveur étroitement sécurisé ne peut pas être connecté à partir de Windows Server 2003 alors que ça ira de votre machine de développement. Il n'y a rien que vous puissiez réellement faire à propos de cette situation si ce n'est de demander à l'équipe de l'administrateur du serveur de destination d'autoriser TLS1.0 ou de mettre à niveau votre serveur de production.

Source de soutien SSL sur Win2k3Server: http://blogs.msdn.com/b/kaushal/archive/2011/10/02/support-for-ssl-tls-protocols-on-windows.aspx

Answer 4

Mon expérience est tout aussi elRobbo décrit. Je dois mettre à niveau le serveur Win2k3 vers Win2k8.

ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3 

est supporté seulement 4,5 .net, qui ne sont pas pris en charge dans Win2k3 ...

Answer 5

Cela a fonctionné pour moi:

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12; 

J'ai mis cette ligne avant de créer la demande web .