Wann oder wenn HttpResponseMessage beim Aufrufen von ReadAsStreamAsync zu disponentieren?

Question

Ich verwende die System.Net.Http.HttpClient, um einige clientseitige HTTP-Kommunikation zu tun. Ich habe das gesamte HTTP an einer Stelle, abstrahiert vom Rest des Codes. In einer Instanz möchte ich den Antwortinhalt als Stream lesen, aber der Konsument des Streams ist gut isoliert von dem Ort, an dem die HTTP-Kommunikation stattfindet und der Stream geöffnet wird. An dem für die HTTP-Kommunikation zuständigen Ort entsorge ich alle HttpClient Sachen.

Diese Einheit Test wird bei Assert.IsTrue(stream.CanRead) fehlschlagen:

[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 
} 

Ich versuche normalerweise von etwas IDisposable zum frühestmöglichen Komfort zu entsorgen, aber in diesem Fall Entsorgung der HttpResponseMessage verfügt auch die Stream von ReadAsStreamAsync zurückgegeben.

So scheint es, als ob der aufrufende Code über die Antwortnachricht sowie den Stream wissen und die Verantwortung übernehmen muss, oder ich lasse die Antwortnachricht unangetastet und lasse den Finalizer damit umgehen. Keine der beiden Optionen fühlt sich richtig an.

This answer spricht über nicht die HttpClient entsorgen. Wie wäre es mit dem HttpRequestMessage und/oder HttpResponseMessage?

Bin ich etwas fehlt? Ich hoffe, dass der Verbrauchercode von HTTP keine Ahnung hat, aber all diese unangepassten Objekte zu lassen, geht gegen das Jahr der Gewohnheit!

Answer 1

So scheint es, wie der aufrufende Code kennen muss und Eigentum der Antwortnachricht sowie den Strom nehmen, oder ich lasse die Antwortnachricht undisposed und die Finalizerthread mit ihnen umgehen lassen. Keine der Optionen fühlt sich richtig an.

In diesem speziellen Fall gibt es keine Finalizer. Weder HttpResponseMessage noch HttpRequestMessage implementieren einen Finalizer (und das ist eine gute Sache!). Wenn Sie keinen von beiden entsorgen, werden sie Garbage Collected erhalten, sobald der GC startet, und der Handle zu ihren zugrunde liegenden Streams wird gesammelt, sobald dies passiert.

Solange Sie diese Objekte verwenden, verfügen nicht. Einmal fertig, entsorgen sie. Statt sie in eine using-Anweisung einzufügen, können Sie immer explizit Dispose aufrufen, sobald Sie fertig sind. In beiden Fällen muss der konsumierende Code kein Wissen besitzen, das HTTP-Anfragen zugrunde liegt.

Answer 2

Sie können den Stream auch als Eingabeparameter verwenden, damit der Aufrufer die vollständige Kontrolle über den Typ des Streams hat und verfügbar ist. Und jetzt können Sie auch httpResponse absetzen, bevor die Kontrolle die Methode verlässt.
Unten ist die Erweiterungsmethode für 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);     
     } 
    }