Kiedy lub kiedy wyrzucić HttpResponseMessage podczas wywoływania ReadAsStreamAsync?

Question

Używam System.Net.Http.HttpClient do wykonywania komunikacji HTTP po stronie klienta. Mam wszystkie HTTP w jednym miejscu, oddzielone od reszty kodu. W jednym przypadku chcę odczytać zawartość odpowiedzi jako strumień, ale konsument strumienia jest dobrze odizolowany od miejsca, w którym odbywa się komunikacja HTTP i strumień jest otwarty. W miejscu odpowiedzialnym za komunikację HTTP pozbywam się wszystkich rzeczy z HttpClient.

Test

Jednostka ta nie powiedzie się Assert.IsTrue(stream.CanRead):

[TestMethod] 
public async Task DebugStreamedContent() 
{ 
    Stream stream = null; // in real life the consumer of the stream is far away 
    var client = new HttpClient();   
    client.BaseAddress = new Uri("https://www.google.com/", UriKind.Absolute); 

    using (var request = new HttpRequestMessage(HttpMethod.Get, "/")) 
    using (var response = await client.SendAsync(request)) 
    { 
     response.EnsureSuccessStatusCode(); 
     //here I would return the stream to the caller 
     stream = await response.Content.ReadAsStreamAsync(); 
    } 

    Assert.IsTrue(stream.CanRead); // FAIL if response is disposed so is the stream 
} 

ja zazwyczaj staram się wrzucać wszystkiego IDisposable na możliwie najwcześniejszym wygody, ale w tym przypadku umieszczenia HttpResponseMessage dysponuje również Stream wrócił z ReadAsStreamAsync.

Wygląda na to, że kod wywoławczy musi wiedzieć i przejąć na własność wiadomość z odpowiedzią, a także strumień, lub pozostawić wiadomość z odpowiedzią i nie pozwolić, by finalizator sobie z nią poradził. Żadna z tych opcji nie wydaje się właściwa.

This answer mówi o nie wyrzucaniu HttpClient. Co powiesz na HttpRequestMessage i/lub HttpResponseMessage?

Czy brakuje mi czegoś? Mam nadzieję, że zachowam niedostrzegalny kod HTTP, ale pozostawienie tych wszystkich nieporządanych obiektów wbrew zwyczajowi!

Answer 1

Więc wydaje się, że kod wywołujący musi wiedzieć i wziąć własność komunikacie odpowiedzi, jak również strumień, czy mogę zostawić komunikat odpowiedzi niezdyspergowanego i niech ofertę finalizatora z nim. Żadna z opcji nie wydaje się właściwa.

W tym konkretnym przypadku nie ma finalizatorów. Ani HttpResponseMessage ani HttpRequestMessage nie implementują finalizatora (i to dobrze!). Jeśli nie pozbędziesz się któregokolwiek z nich, zostaną zebrane śmieci, gdy GC się pojawi, a uchwyt do ich bazowych strumieni zostanie zebrany, gdy to nastąpi.

Dopóki używasz tych obiektów, nie wyrzucaj ich. Po zakończeniu, pozbyć się ich. Zamiast owijać je w oświadczeniu using, zawsze możesz jednoznacznie wywołać Dispose, gdy skończysz. Tak czy inaczej, zużywający się kod nie musi mieć żadnej wiedzy na temat żądań HTTP.

Answer 2

Możesz również przyjąć strumień jako parametr wejściowy, dzięki czemu dzwoniący ma pełną kontrolę nad typem strumienia, jak również jego usuwanie. A teraz możesz także wyrzucić httpResponse, zanim kontrola opuści metodę.
Poniżej jest metoda rozszerzenie dla HttpClient

public static async Task HttpDownloadStreamAsync(this HttpClient httpClient, string url, Stream output) 
    { 
     using (var httpResponse = await httpClient.GetAsync(url).ConfigureAwait(false)) 
     { 
      // Ensures OK status 
      response.EnsureSuccessStatusCode(); 

      // Get response stream 
      var result = await httpResponse.Content.ReadAsStreamAsync().ConfigureAwait(false); 

      await result.CopyToAsync(output).ConfigureAwait(false); 
      output.Seek(0L, SeekOrigin.Begin);     
     } 
    }