Bug: multipart/form-data requests sent from Apidog Web are missing the boundary parameter

Get Support
1

Hi team!

When sending a multipart/form-data POST request that includes a file using the Apidog Web client, the boundary parameter is missing from the auto-generated Content-Type header. This results in a malformed request that servers cannot parse, leading to a server-side exception and a 500 Internal Server Error.

Environment

API Client: Apidog (Web Version, we have our documentation hosted on Apidog.)

Browser: Google Chrome, zen (I didn't test other browsers, but pretty sure most of them are same behavior)

Server Framework: Spring Boot

Expected Result

Apidog Web should automatically generate a valid Content-Type header that includes a unique boundary parameter.

Example:

Content-Type: multipart/form-data; boundary=----WebKitFormBoundary7MA4YWxkTrZu0gW

The server should successfully parse this request and process the file upload.

Actual Result

The "Actual Request" view in Apidog confirms that the Content-Type header is sent incorrectly, without any boundary:

Content-Type: multipart/form-data

The receiving server throws a parsing exception. In our case, the Java Spring server log shows:
Java

org.apache.tomcat.util.http.fileupload.FileUploadException: the request was rejected because no multipart boundary was found

The client receives a 500 Internal Server Error in response due to the server’s inability to parse the request.

2

Hi Hojin Yang,

The web version doesn’t automatically generate the request header. Could you try downloading the Apidog client and use it instead?

3

in apidog client, I know it works.

This bug is pretty critical since we are planning to provide api documentation to our customer.

Obviously, client will try to send api request by apidog web version…

4

Hi Hojin Yang,

Thank you for your feedback. I’ve forwarded this issue to our technical team, and we’ll work on optimizing the logic for this part.

5

Thanks.

Let me know when you guys fixed this problem.

6

Hi Hojin Yang,

From our end, we couldn’t reproduce the issue. Did you manually add a content-type Header instead of using the auto-generated one? Please try sending the request without your manual added header.

7

Nope, actually what I did was sending api request in apidog web itself. After request has not been processed, I checked actual request section in apidog, and figured out this problem.

this is the apidog actual request that failed:

curl --location --request POST 'https://blah/api/v1/parsing/test' \
--header 'User-Agent: Apidog/1.0.0 (https://apidog.com)' \
--header 'Content-Type: multipart/form-data' \
--header 'Authorization: Bearer demo_api' \
--header 'Accept: */*' \
--header 'Host: test_url' \
--header 'Connection: keep-alive' \
--form 'file=@"cmMtdXBsb2FkLTE3NTY5NjU0NTgwNzItNw==/데이터 패브릭 리서치 가이드.pdf"'

I did mask host and api key, but other than that, everything is completely same with apidog actual request.

8

I really need this feature work since our customer will try-out api in documentation hosted by apidog…

9

Could you try using the “No Proxy” option in your docs site setting and try to send it in your docs site? Please refer to the documentation Request proxy in shared docs - Apidog Docs for instructions.

652b762a-251d-4d35-a290-4dc55ca20a8c.jpeg
652b762a-251d-4d35-a290-4dc55ca20a8c.jpeg1774×674 95 KB

10

After setting no proxy option in your docs, request has been rejected due to cors issue…