FormData parameters of type 'file' get sent as 'System.Byte[]' instead of the buffer contents.

[baronfel]

Description

Given an operation that has a parameter of type 'file' whose location is 'formData', the resulting Request logic correctly makes a BodyType of FormData, but the coerceString method taked the Expr representing the byte[] parameter and calls Object.ToString() on it, resulting in the bad representation.

We should either expand the coerceString function in OperationCompiler.fs to understand the difference defTypes, or find a way to use the ByteArrayConverter to reduce code duplications.

Repro steps

1. use this swagger.yaml:

swagger: "2.0"
info:
  version: "1.0.0"
  title: Test

# during dev, should point to your local machine
host: localhost:3001

# format of bodies a client can send (Content-Type)
consumes:
  - application/json
# format of the responses to the client (Accepts)
produces:
  - application/json

paths:
  /:    
    post:
      parameters:
      - name: foo
        in: formData
        required: true
        type: file
      responses:
        200:
          description: Success
          schema: 
            type: string

2. try to send a byte array using the generated client for this yaml

Expected behavior

The byte array contents should appear in the body in the form foo=XXXXX, where XXXX are the bytes.

Actual behavior

The result is file=System.Byte[]

Known workarounds

None

Related information

• Operating system: OSX El Capitan
• Branch: SwaggerProvider 0.5.6 from Nuget
• .NET Runtime, CoreCLR or Mono Version: Mono 4.6.2

[sergey-tihon]

@baronfel Thank you for so detailed description.
Do you know how to write ASP.NET Web API controller that will generate formData file parameter?
https://github.com/fsprojects/SwaggerProvider/blob/master/tests/Swashbuckle.OWIN.Server/UpdateControllers.fs

[baronfel]

I'll try and create a repro in just a bit, but I'm operating from a hand crafter swagger.yaml so I'll have to go research how swashbuckle expects controller actions that represent file data to look.

[baronfel]

I've taken some more time on this tonight, and it seems that the blocker is that FSharp.Data.Http doesn't support multipart data at all. I'm working on that to unblock this feature. The Issue on that repo is fsprojects/FSharp.Data#811.

It's a big one though :(

[sergey-tihon]

@baronfel do you alternatives for Http.fs (file) that we can use? We need something that work on PCL profile 259 ... We use FSharp.Data just because it was simple for the beginning

[baronfel]

I suppose the leading contenders would be System.Net.HttpClient, which I've used before for multipart content, and also Haf's Httpfs. I can see of either of those are profile 259 compliant

[sergey-tihon]

Should be addressed by #131 in OpenApiClientProvider