MultiPartBody: Impossible to add multiple Body Parts with the same name

[romanett]

What are you generating using Kiota, clients or plugins?

API Client/SDK

In what context or format are you using Kiota?

Nuget tool

Client library/SDK language

Csharp

Describe the bug

I am using an existing API with the Atteached API Spec.

It expects a multipart body with an array of files:

e.g swagger Editor lets you paste multiple files:

However the KIOTA Multipart body uses a dictionary based on the Part name, so this does not allow you to create such a body:

            body.AddOrReplacePart<byte[]>("files", "text/plain", file, "test.txt");
            body.AddOrReplacePart<byte[]>("files", "text/plain", file, "test2.txt");

 if(!_parts.TryAdd(partName, value))
 {
     _parts[partName] = value;
 }

This creates such a request:

RequestRaw:

--d11b4f38539b40fbb6a300dfddcede33
Content-Type: text/plain
Content-Disposition: form-data; name="files"; filename="test.txt"

Test

--d11b4f38539b40fbb6a300dfddcede33--

However I want to create such an request:

--d11b4f38539b40fbb6a300dfddcede33
Content-Type: text/plain
Content-Disposition: form-data; name="files"; filename="test.txt"

Test

--d11b4f38539b40fbb6a300dfddcede33
Content-Type: text/plain
Content-Disposition: form-data; name="files"; filename="test2.txt"

Test2

--d11b4f38539b40fbb6a300dfddcede33--

Expected behavior

Be able to create a multipart body with multiple elements with the same name.

How to reproduce

Generate client with attached API spec.

Try to add multiple files

Open API description file

openapi: 3.0.1
info:
  title: Test
  version: 1.0.0.0
paths:
  /v6/mailbox/messages:
    put:
      summary: Insert a message into a Mailbox
      description: |
        ## This endpoint inserts a message into the specified mailbox.
        **Returns** an object with ids for the newly created message
      operationId: putMessageV6
      requestBody:

        content:
          multipart/form-data:
            schema:
              $ref: '#/components/schemas/CreateMessage'
            encoding:
              files:
                contentType: application/octet-stream
      responses:
        '200':
          description: |
            The id of the created message is returned.
components:
  schemas:
    CreateMessage:
      type: object
      properties:
        files:
          type: array
          items:
            type: string
            description: |-
              files to upload.

              ### curl example:

              ```-F 'files=@sample.txt;type=text/plain'```
            format: binary
      description: |
        ### curl example:
        ```-F 'files=@sample.txt;type=text/plain;'```

Kiota Version

1.23.0

Latest Kiota version known to work for scenario above?(Not required)

No response

Known Workarounds

Configuration

OS: Windows 10
Architecture x64
.Net 9

Debug output

Click to expand log

```

</details>


### Other information

Repro project will follow

[baywet]

Hi @romanett
Thank you for using kiota and for reaching out.

I have transferred your issue to the kiota dotnet repo. Even though this implementation issue is in all languages, we can start by addressing it in dotnet and work our way to the other languages once we have a solution here.

Since the dictionary is private, changing the key to be a Tuple<string, string> part name and file name should not be a problem. And the lookup for addition/replacement/removal should remain O(1). The only "important" change is that now the remove method needs to accept a file name optional parameter. Making it an optional parameter would be binary breaking, so we should instead rely on methods overloads.

Does that make sense to you?

Is this something you'd like to submit a pull request for provided some guidance?

[romanett]

@baywet thanks for the update I will propose a PR next week.

[romanett]

@baywet changing the dictionary to Tuple<string, string> will break existing RemovePart / GetPartValue for cases where a FileName is specified, but not using the new mehthod overload inclduing filename.

We have two options here.

1. Mark the RemovePart / GetPartValue overloads as deprecated and warn about the issue
2. Make the use of fileName as second part of the dictionary key optional by introducing a property that is false by default, like AllowDuplicatePartNames -> if false always set fileName to null in the key

Please see my attached PR which also adds a test showcasing the issue