Can't encode a multipart part without a filename

[HoneyryderChuck]

Using the JS layer to do a multipart request isn't so straightforward if uploading complex parts other than files.

// this will assign a random filename and application/octet-stream
const attachment = http.file(videoFile);
// this will be video.mp4 with the video/mp4
const attachment = http.file(videoFile, 'video.mp4', 'video/mp4');

// this should encode metadata as a json part, which does.... with a filename="null"!!!
const attachment = http.file(JSON.stringify({name: "Jack"}), null, 'application/json');

There should therefore be a new method, ex. http.part or something, where the filename is omitted.

[mstoykov]

Hi @HoneyryderChuck,

The current way the whole multipart body generation works has a lot of ... problems(#747 #1382 #1571) among ... others.

The current plan fixed for this is to discourage the actual usage of the k6 in a method in favor of using a FormData polyfill (maybe specifically written for k6) after the merging of #1776. It is actually a thing that I plan on actually testing and getting ready, but haven't gotten to.

There are also plans for a new HTTP API, because of the problems above and .. others. But that maybe will just include some internal FormData, maybe not 🤷‍♂️

[HoneyryderChuck]

I'm not entirely familiar with how the FormData polyfill would turn out in the end, and what are the plans for a new API. However, I think that a "quickfix" for this, at least until all this evolves, is for the http.file API not to add a filename parameter to the part encoding when the value is null. Would this be something to consider?

[mstoykov]

There are 2 problems:

1. the current state of the multipart support being so broken in so many different ways is in part as a result of many other previous quick fixes, so quick fixes :)
2. w/e quick fix we make isn't going to make it in the next release that comes out in 2 weeks (hopefully). But the release will include the ability for a FormData polyfill to fix it(the PR above). And even if the polyfill needs fixes it is just JS that you load, so we(all of us) can change and customize it outside of the k6 release cycle ;). It will also fix a lot (if not all) of the reported problems with the current multipart support in k6.

So, no, we are unlikely to make a quick fix :)

You can of course make one yourself and compile k6 with it and use it. Although I will argue that if you can do that, you can build from the PR I linked above and use the polyfill as is and it will likely work better and will be compatible with the future k6 ;)

[mirzaprangon]

I will bump this issue.

I was trying to send a json data and a file in a mulitpart request, which I could not using k6. The openapi looks like below:

openapi: 3.0.3
info:
  version: "1"
  title: Multiple Content Types for same request
paths:
  /multiplecontentpath:
    post:
      requestBody:
        content:
          mutlipart/form-data:
            schema:
              type: object
              properties:
                coordinates:
                  $ref: '#/components/schemas/coordinates'
                file:
                  type: string
                  format: binary
      responses:
        201:
          description: Successfully created
          headers:
            Location:
              schema:
                type: string
components:
  schemas:
    coordinates:
      type: object
      required:
        - lat
        - long
      properties:
        lat:
          type: number
        long:
          type: number

How are things regarding multipart/form-data ?

[codebien]

Hey @mirzaprangon,
sorry for the late response.

Did you try the FormData polyfill, it should cover this case. Just make sure to follow what is suggested here: grafana/k6-jslib-formdata#4 (comment).

In the future, we plan to have native support for FormData web API in k6. Unfortunately, this is not yet on our short-term roadmap.

Let me know if it helps.