2013-06-14 24 views
10

Sto avendo un momento terribile per la risoluzione di questo problema. Sto anche passando un periodo terribile riproducendolo costantemente da un'applicazione all'altra..NET 4.5 HttpClient PUT o POST su SSL fallisce sempre

In determinate circostanze, che non riesco a identificare, effettuare chiamate PUT e POST utilizzando i risultati HttpClient nella seguente eccezione.

Si è verificato un errore durante l'invio della richiesta.

Interno Eccezione:
La connessione sottostante è stata chiusa: si è verificato un errore imprevisto in una trasmissione.

Eccezione interna:
Questa operazione non può essere eseguita su un oggetto risultato asincrono completato.

Tutto sembra funzionare con HTTP, questo accade solo su HTTPS.

certificati sono validi, ma ho provato a regolare il ServicePointManager.ServerCertificateValidationCallback += (s, c, ch, es) => true;

Ho provato a fissare client.DefaultRequestHeaders.ExpectContinue = false;

ho provato, quello che sembra come un milione di altre cose, che vanno da intestazioni, autenticazione, ecc

Qualcuno ha idea di cos'altro posso controllare, provare, ecc.?

Codice frammento:

// this is my registration in my IoC container... 
var handler = new HttpClientHandler 
{ 
    UseDefaultCredentials = true, 
    Credentials = CredentialCache.DefaultNetworkCredentials, 
}; 

var client = HttpClientFactory.Create(handler); 
client.BaseAddress = new Uri(Properties.Settings.Default.BaseUrl); 
client.DefaultRequestHeaders.Add("X-CustomHeader", "value"); 

// _client is constructor injected into my class... 
var response = await _client.PutAsJsonAsync("api/resource/" + id, model).ConfigureAwait(false); 
response.EnsureSuccessStatusCode(); // <-- never executes... 

UPDATE:

Se mi tolgo il ConfigureAwait(false) funziona benissimo.

Nota, questa è un'app WPF, in particolare, questa è un'estensione di Visual Studio. Tuttavia, ho un 4 applicazione ASP.NET MVC con lo stesso identico problema, e che l'applicazione non chiama ConfigureAwait(false) affatto ...

UPDATE 2:

ho aggiornato il frammento di codice da includere l'istanziazione della classe HttpClient. L'unica cosa che non è inclusa nello snippet di codice è il tipo di modello e la dichiarazione. Dovrebbe essere irrilevante, in quanto è una classe serializzabile con tutte le proprietà auto senza tipi complessi.

UPDATE 3:

Non so se questo è rilevante, ma ho trovato un paio di cose che guardano strano per me.

Quando si esegue il codice precedente, in Fiddler, è possibile ottenere una 401 sul POST, seguito da 2 CONNECT s' che determinano le seguenti risposte HTTP:

HTTP/1.1 200 connessione stabilita
Connection: close

AGGIORNAMENTO 4:

ho cambiato il mio codice di registrazione CIO di essere questo:

var handler = new HttpClientHandler 
{ 
    UseDefaultCredentials = true, 
    Credentials = CredentialCache.DefaultCredentials, 
}; 

var client = HttpClientFactory.Create(handler); 
client.BaseAddress = new Uri(Properties.Settings.Default.BaseUrl); 
client.DefaultRequestHeaders.Add("X-CustomHeader", "value"); 

e ora non riesce, ma quando apro Fiddler e lascia decrittografare il traffico ... funziona!

UPDATE 5:

credo che questo deve essere un problema di server, o un problema di cert. Qualche consiglio su cosa controllare da qui sarebbe molto apprezzato. I certificati sono validi e rilasciati da una CA affidabile.

UPDATE 6:

Più debug e la ricerca guasti. L'eccezione si verifica prima che venga invocato il ServicePointManagerCertificateValidationCallback.

+0

Mostra un estratto del codice di invio effettivo. –

+0

Aggiunto snippet di codice, ma in realtà è solo l'utilizzo di base. Nulla di bello. – Adam

+0

Stai eliminando '_client' prima che la richiesta venga completata? Puoi pubblicare una riproduzione minimale? –

risposta

2

Ho appena finito di risolvere un problema simile con HttpClient. Risulta che stavo ricevendo un avviso SNI durante l'handshake SSL, che ha causato il blocco di HttpClient a tempo indeterminato. Prova a eseguire WireShark/tcpdump e verifica se ricevi un avviso Nome non riconosciuto TLSv1 o qualsiasi altro tipo di avviso di handshake. HttpClient non sembra gestirli correttamente in base ai miei test.

0

Ho avuto lo stesso problema e l'ho risolto installando l'ultimo aggiornamento del framework .NET (4.5).