CapturedMultipartContent doesn't really capture content

[bchavez]

Hey Todd,

Hope you are well & safe. Also, congrats on your 3.0 release! And thank you for all you do.

I think I may have found a small bug in the library:

void Main()
{
   var test = new HttpTest();
   test.RespondWith("OK");
                  
   "https://foo.com/upload".PostMultipartAsync( bc => {
      bc.AddString("key", "value");
   });

   test.ShouldHaveCalled("https://foo.com/upload")
      .With(fc =>
      {
         var content = fc.HttpRequestMessage.Content as CapturedMultipartContent;
         content.Parts.Length.Should().Be(1);
         return true;
      });
}

The reason I think CapturedMultipartContent doesn't capture the content is:

1. The base class MultipartContent is used as a storage container for the items being added:
   

   Flurl/src/Flurl.Http/Content/CapturedMultipartContent.cs

   Line 125 in 1185099

   base.Add(content);

   
   

   Flurl/src/Flurl.Http/Content/CapturedMultipartContent.cs

   Line 22 in 1185099

   public HttpContent[] Parts => this.ToArray();

2. The MultipartContent in System.Net.Http clears the _nestedContent on .Dispose():
   https://github.com/dotnet/runtime/blob/be9d38c8586af55ac848392fedf0076760e6cccc/src/libraries/System.Net.Http/src/System/Net/Http/MultipartContent.cs#L126-L137

3. The HttpRequestMessage is disposed of after the request completes in FlurlRequest. And the content is already gone and cleared by the time we make the assertion.
   

   Flurl/src/Flurl.Http/FlurlRequest.cs

   Line 198 in 1185099

   request.Dispose();

Let me know if you'd like me to create a PR to fix the issue. If performance is a concern, perhaps there could be:

if inTestMode
   keep an additional copy in a local list
else
   use parent container

Best regards,
Brian

[tmenier]

Thanks for reporting. Ick. I agree, "captured" should imply not clearing that collection. I'll take a crack at fixing. Maybe overriding Dispose is the cleanest way, unless you have other ideas.

[tmenier]

...Actually, capturing to a different collection is a little cleaner, and more in line with what CapturedStringContent does. I have no overhead concerns - it's a redundant collection but it references the same object instances as the original.

[tmenier]

Fixed & released in 3.0.1