2016-06-28 38 views
6

Qual è la procedura migliore per chiamare Dispose (o meno) su HttpRequestMessage e HttpResponseMessage con asp.net core?Non chiamare Dispose su HttpRequestMessage e HttpResponseMessage in asp.net core

Esempi:

https://github.com/aspnet/Security/blob/1.0.0/src/Microsoft.AspNetCore.Authentication.Google/GoogleHandler.cs#L28-L34

protected override async Task<AuthenticationTicket> CreateTicketAsync(ClaimsIdentity identity, AuthenticationProperties properties, OAuthTokenResponse tokens) 
    { 
     // Get the Google user 
     var request = new HttpRequestMessage(HttpMethod.Get, Options.UserInformationEndpoint); 
     request.Headers.Authorization = new AuthenticationHeaderValue("Bearer", tokens.AccessToken); 

     var response = await Backchannel.SendAsync(request, Context.RequestAborted); 
     response.EnsureSuccessStatusCode(); 

     var payload = JObject.Parse(await response.Content.ReadAsStringAsync()); 
     ... 
    } 

e https://github.com/aspnet/Security/blob/1.0.0/src/Microsoft.AspNetCore.Authentication.Facebook/FacebookHandler.cs#L37-L40
Entrambi gli esempi non sono chiamando Dispose

Potrebbe essere questa un'omissione? o c'è una ragione valida dietro di esso, forse perché il metodo è asincrono?

Modifica 1: ovviamente il CG finirà per finalizzarli, ma è questa la migliore pratica per farlo in questa circostanza e perché?

Edit 2: gli esempi sopra riportati sono parte di componenti fondamentali asp.net middleware

+0

verrà smaltito una volta fuori dal campo di applicazione e non in uso (asincrono). –

+0

Naturalmente il CG finirà per finalizzarli, ma è questa la migliore pratica per farlo in questa circostanza e perché? – PaulMiami

+0

Se la chiamata viene chiamata prima del termine del metodo asincrono, verranno generate eccezioni. –

risposta

4

Aprii un problema del repository github dove gli esempi di codice appartengono.

https://github.com/aspnet/Security/issues/886

Non è importante in questi scenari. Lo smaltimento di una richiesta o di una risposta chiama solo Dispose nel relativo campo Contenuto. Tra le diverse implementazioni di HttpContent, solo StreamContent deve eliminare tutto. Il SendAsync predefinito di HttpClient memorizza completamente il contenuto della risposta e smaltisce lo stream, quindi non c'è nulla che il chiamante debba fare.

Ma al fine di non ottenere bug strani lungo la linea, è meglio smaltire tali oggetti. MemoryStream è un'altra classe che spesso non è disponibile a causa della sua attuale implementazione sottostante.

https://stackoverflow.com/a/234257/6524718

Se siete assolutamente sicuri che non si vuole passare da un MemoryStream ad un altro tipo di flusso, non sta andando per farti del male a non chiamare Dispose. Tuttavia, in genere è una buona pratica in parte perché se cambi mai per utilizzare un flusso diverso, non vuoi essere morso da un bug difficile da trovare perché hai scelto la via d'uscita facile all'inizio. (D'altra parte, c'è l'argomento YAGNI ...)

L'altra ragione per farlo in ogni caso è che una nuova implementazione può introdurre risorse che sarebbero state liberate su Dispose.