HttpClient et HttpClientHandler doivent-ils être éliminés entre les requêtes ?

Question

System.Net.Http.HttpClient y System.Net.Http.HttpClientHandler dans .NET Framework 4.5 mettent en œuvre IDisposable (via System.Net.Http.HttpMessageInvoker ).

El using La documentation de la déclaration dit :

En règle générale, lorsque vous utilisez un objet IDisposable, vous devez le déclarer et l'instancier dans une instruction using. l'instancier dans une instruction using.

Cette réponse utilise ce modèle :

var baseAddress = new Uri("http://example.com");
var cookieContainer = new CookieContainer();
using (var handler = new HttpClientHandler() { CookieContainer = cookieContainer })
using (var client = new HttpClient(handler) { BaseAddress = baseAddress })
{
    var content = new FormUrlEncodedContent(new[]
    {
        new KeyValuePair<string, string>("foo", "bar"),
        new KeyValuePair<string, string>("baz", "bazinga"),
    });
    cookieContainer.Add(baseAddress, new Cookie("CookieName", "cookie_value"));
    var result = client.PostAsync("/test", content).Result;
    result.EnsureSuccessStatusCode();
}

Mais les exemples les plus visibles de Microsoft n'appellent pas à l'aide. Dispose() soit explicitement, soit implicitement. Par exemple :

• El article de blog original annonçant la disparition de HttpClient.
• L'actuel Documentation MSDN pour HttpClient.
• BingTranslateSample
• GoogleMapsSample
• Banque mondialeEchantillon

Dans le annonce quelqu'un a demandé à l'employé de Microsoft :

Après avoir vérifié vos échantillons, j'ai vu que vous n'avez pas effectué l'action "dispose" sur l'instance HttpClient. sur l'instance HttpClient. J'ai utilisé toutes les instances de HttpClient avec l'instruction using dans mon application et j'ai pensé que c'était la bonne méthode puisque HttpClient implémente l'interface IDisposable. Suis-je sur la bon chemin ?

Sa réponse était :

En général, c'est correct, bien qu'il faille faire attention avec avec "using" et async, car ils ne se mélangent pas vraiment dans .Net 4. pouvez utiliser "await" dans une déclaration "using".

En fait, vous pouvez réutiliser le même HttpClient autant de fois que vous le souhaitez. généralement, vous ne les créerez pas et ne les jetterez pas tout le temps.

Le deuxième paragraphe est superflu pour cette question, qui ne concerne pas le nombre de fois que vous pouvez utiliser une instance de HttpClient, mais la question de savoir s'il est nécessaire de s'en débarrasser lorsque vous n'en avez plus besoin.

(Mise à jour : en fait, ce deuxième paragraphe est la clé de la réponse, comme indiqué ci-dessous par @DPeden).

Mes questions sont donc les suivantes :

1. Est-il nécessaire, compte tenu de l'implémentation actuelle (.NET Framework 4.5), d'appeler Dispose() sur les instances HttpClient et HttpClientHandler ? Clarification : par "nécessaire", je veux dire s'il y a des conséquences négatives à ne pas disposer, comme des risques de fuite de ressources ou de corruption de données.

2. Si ce n'est pas nécessaire, serait-ce de toute façon une "bonne pratique", puisqu'ils implémentent IDisposable ?

3. Si c'est nécessaire (ou recommandé), est-ce que ce code mentionné ci-dessus en le mettant en œuvre en toute sécurité (pour .NET Framework 4.5) ?

4. Si ces classes ne nécessitent pas d'appeler Dispose(), pourquoi ont-elles été implémentées comme IDisposable ?

5. S'ils l'exigent, ou s'il s'agit d'une pratique recommandée, les exemples de Microsoft sont-ils trompeurs ou dangereux ?

Answer 1

Le consensus général est que vous n'avez pas (ne devriez pas) avoir besoin de disposer de HttpClient.

C'est ce qu'ont déclaré de nombreuses personnes qui sont intimement liées à son fonctionnement.

Ver Le billet de blog de Darrel Miller et un billet connexe de SO : L'exploration de HttpClient entraîne une fuite de mémoire pour référence.

Je vous suggère aussi fortement de lire le chapitre HttpClient de Concevoir des API Web évolutives avec ASP.NET pour connaître le contexte de ce qui se passe sous le capot, en particulier la section "Cycle de vie" citée ici :

Bien que HttpClient implémente indirectement la fonction IDisposable l'utilisation standard de HttpClient ne consiste pas à s'en débarrasser après chaque requête. L'objet HttpClient est conçu pour vivre aussi longtemps que aussi longtemps que votre application a besoin d'effectuer des requêtes HTTP. Le fait qu'un objet existe à travers de multiples requêtes permet de définir un endroit pour DefaultRequestHeaders et vous évite d'avoir à respécifier les éléments suivants comme CredentialCache et CookieContainer à chaque demande, comme cela était comme cela était nécessaire avec HttpWebRequest.

Ou même ouvrir DotPeek.

Answer 2

D'après moi, appeler Dispose() n'est nécessaire que lorsqu'il s'agit de verrouiller des ressources dont vous aurez besoin plus tard (comme une connexion particulière). C'est toujours recommandé de libérer les ressources que vous n'utilisez plus, même si vous n'en avez plus besoin, simplement parce que vous ne devriez pas généralement de conserver des ressources que vous n'utilisez pas (jeu de mots).

L'exemple de Microsoft n'est pas nécessairement incorrect. Toutes les ressources utilisées seront libérées lorsque l'application se terminera. Et dans le cas de cet exemple, cela se produit presque immédiatement après l'exécution de la commande HttpClient a fini d'être utilisé. Dans ce cas, l'appel explicite de Dispose() est quelque peu superflue.

Mais, en général, quand une classe implémente IDisposable il est entendu que vous devez Dispose() de ses instances dès que vous êtes prêt et capable. Je dirais que c'est particulièrement vrai dans les cas tels que HttpClient où il n'est pas explicitement documenté si les ressources ou les connexions sont maintenues/ouvertes. Dans le cas où la connexion sera réutilisée [bientôt], il est préférable de ne pas utiliser la fonction Dipose() Vous n'êtes pas "totalement prêt" dans ce cas.

Voir aussi : Méthode IDisposable.Dispose y Quand appeler Dispose

Answer 3

Dans mon cas, je créais un HttpClient à l'intérieur d'une méthode qui effectuait l'appel de service. Quelque chose comme :

public void DoServiceCall() {
  var client = new HttpClient();
  await client.PostAsync();
}

Dans un rôle de travailleur Azure, après avoir appelé cette méthode de manière répétée (sans disposer du HttpClient), elle échouerait finalement avec le message suivant SocketException (échec de la tentative de connexion).

J'ai fait du HttpClient une variable d'instance (en le disposant au niveau de la classe) et le problème a disparu. Je dirais donc que oui, disposez du HttpClient, en supposant qu'il est sûr (vous n'avez pas d'appels asynchrones en cours) de le faire.

Answer 4

Dans une utilisation typique (réponses<2GB), il n'est pas nécessaire de disposer des HttpResponseMessages.

Les types de retour des méthodes HttpClient doivent être éliminés si le contenu de leur flux n'est pas entièrement lu. Sinon, le CLR n'a aucun moyen de savoir que ces flux peuvent être fermés avant la collecte des déchets.

• Si vous lisez les données dans un byte[] (par exemple avec GetByteArrayAsync) ou une chaîne de caractères, toutes les données sont lues, il n'y a donc pas besoin de disposer.
• Les autres surcharges lisent par défaut le flux jusqu'à 2 Go (HttpCompletionOption is ResponseContentRead, HttpClient.MaxResponseContentBufferSize default is 2GB).

Si vous avez défini l'option HttpCompletionOption sur ResponseHeadersRead ou si la réponse est supérieure à 2 Go, vous devez procéder à un nettoyage. Cela peut être fait en appelant Dispose sur le HttpResponseMessage ou en appelant Dispose/Close sur le flux obtenu à partir du contenu du HttpResonseMessage ou en lisant complètement le contenu.

Le fait d'appeler Dispose sur le HttpClient dépend de la volonté d'annuler ou non les demandes en attente.

Answer 5

Je pense que l'on devrait utiliser le modèle singleton pour éviter d'avoir à créer des instances de HttpClient et de les fermer tout le temps. Si vous utilisez .Net 4.0, vous pouvez utiliser l'exemple de code ci-dessous. Pour plus d'informations sur le modèle singleton, consultez le site suivant aquí .

class HttpClientSingletonWrapper : HttpClient
{
    private static readonly Lazy<HttpClientSingletonWrapper> Lazy= new Lazy<HttpClientSingletonWrapper>(()=>new HttpClientSingletonWrapper()); 

    public static HttpClientSingletonWrapper Instance {get { return Lazy.Value; }}

    private HttpClientSingletonWrapper()
    {
    }
}

Utilisez le code ci-dessous.

var client = HttpClientSingletonWrapper.Instance;