[BUG] HeaderCollection attribute doesn't seem to work with POSTs

[uhfath]

As described in docs I use [HeaderCollection] attribute to supply some dynamic headers to my requests:

[Get("/{bucket}")]
Task<ListBucketResult> ListObjectsAsync(string bucket, ListObjectsRequest request, [HeaderCollection]IDictionary<string, string> headers, CancellationToken cancellationToken = default);

[Post("/{bucket}/{key}?uploads")]
Task<InitiateMultipartUploadResult> CreateMultipartUploadAsync(string bucket, string key, [HeaderCollection]IDictionary<string, string> headers, CancellationToken cancellationToken = default);

While it works perfectly with GETs it just doesn't work the same way with POSTs:

One or more errors occurred. (The type System.Collections.Generic.Dictionary`2[[System.String, System.Private.CoreLib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e],[System.String, System.Private.CoreLib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e]] is not supported because it implements IDictionary.)
   at System.Threading.Tasks.Task.ThrowIfExceptional(Boolean includeTaskCanceledExceptions)
   at System.Threading.Tasks.Task`1.GetResultCore(Boolean waitCompletionNotification)
   at System.Threading.Tasks.Task`1.get_Result()
   at TestMinioClient.Program.Main(String[] args) in D:\Projects\TestMinioClient\Program.cs:line 237

Also with GETs everything is working when supplied header collection is null. But an exception (value is null) is thrown when using the same with POSTs.

Tested using 6.0.24

[james-s-tayler]

Interesting. We've got a test where [HeaderCollection] is used in conjunction with POST and that works fine, though the difference I can see here is that test includes a [Body] in the method signature. Looking at the code sample and the stacktrace my initial suspicions are that 1) it's trying to serialize the [HeaderCollection] dictionary for some reason, and 2) your method signature is causing it to do so for some reason. Gut feel is a bug triggered by not having a [Body]. Will investigate.

Edit: Suspicions confirmed. I have managed to create a failing test for this when [HeaderCollection] is present on a POST request with no [Body] attribute.

Looks like the logic in RestMethodInfo.cs attempts to find what it considers to be the Body and if [Body] is present it will use that, else it has some logic which makes certain assumptions. In this case it's as I suspected - it's guessing that the HeaderCollection is the Body of the request, hence this behavior.

Looks like I missed a spot there. Will update that logic to ignore parameters with attribute [HeaderCollection]

[james-s-tayler]

@uhfath I have opened a PR to fix this.

[uhfath]

@james-s-tayler thanks for taking a look into this and fixing the issue. Will test as soon as I get the chance.

[james-s-tayler]

@uhfath no worries. Looks like the fix will be released in 6.0.42 so you'll have to wait until that's available in NuGet https://www.nuget.org/packages/Refit/

refit 6.0.38

The automatic type-safe REST library for Xamarin and .NET

[ChrisPulman]

Issue notified as resolved.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.