Open HoneyryderChuck opened 3 years ago
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 :man_shrugging:
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?
There are 2 problems:
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 ;)
Stop please
Sent from my iPhone
On 8 Jan 2564 BE, at 10:24 AM, Mihail Stoykov notifications@github.com wrote:
There are 2 problems:
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 :) 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 ;)
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.
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 ?
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: https://github.com/grafana/k6-jslib-formdata/issues/4#issuecomment-2064603614.
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.
Using the JS layer to do a multipart request isn't so straightforward if uploading complex parts other than files.
There should therefore be a new method, ex.
http.part
or something, where the filename is omitted.