Multipart POST not working for me

[stevemcmillen]

I'm having an issue posting a multipart form request with POSTMan where some of the items have binary data. I think POSTMan has an error with the boundary.

I want to post a form that has three parts:
Part 1: name=photo (an image)
Part 2: name=metadata (text metadata in json format)
Part 3: name=thumbnail (a small image)

I can post the same data via CURL (See command below) and the server receives it correctly but when I submit with POSTMan, I get a general error from the server.

Error on the server reported by Java when parsing the form data is "Missing Start Boundary".

Following is output from POSTMan "Preview". The boundary reported in the headers seems to not match the actual boundary used.

POST /v1/media_photos HTTP/1.1
Host: ****
Authorization: ****
Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryp7MA4YWxkTrZu0gW
Cache-Control: no-cache
Postman-Token: 9b823259-ee15-16fe-6aa0-cd094d23286e

----WebKitFormBoundaryE19zNvXGzXaLvS5C
Content-Disposition: form-data; name="photo"; filename="Canon_CanonEOS_4800x3200.jpg"
Content-Type: image/jpeg


----WebKitFormBoundaryE19zNvXGzXaLvS5C
Content-Disposition: form-data; name="metadata"; filename="metadata.json"
Content-Type: application/json


----WebKitFormBoundaryE19zNvXGzXaLvS5C
Content-Disposition: form-data; name="thumbnail"; filename="thumbnail.jpg"
Content-Type: image/jpeg


----WebKitFormBoundaryE19zNvXGzXaLvS5C

And here is the CURL command that POSTMan suggests:

curl -X POST -H Authorization: *** -H Content-Type:multipart/form-data; boundary=----WebKitFormBoundaryp7MA4YWxkTrZu0gW -H Cache-Control:no-cache -H Postman-Token:298b7786-7f5b-9fce-d290-e51e5d13c915 -F photo= -F metadata= -F thumbnail= http://***/v1/media_photos

And here's a CURL command that works:

curl --header "Authorization: ***" -F "photo=@flower.jpg"  -F "thumbnail=@src.jpg" -F metadata='{"file_size":879394}' http://***/v1/media_photos

[a85]

Are you using the Interceptor? Might be related to #561

[stevemcmillen]

No. Its not enabled.

When I click "Preview" to see the request (before submitting), I got the above out of POSTMan. Seemd like the boudary= in the headers does not match the one used in the body:

boundary=----WebKitFormBoundaryp7MA4YWxkTrZu0gW

               ----WebKitFormBoundaryE19zNvXGzXaLvS5C

Shouldn't they be the same?

[a85]

The "Preview" boundary is not the same as the one that is sent. It's there for illustrating how the request would look like. The final request is sent by Chrome which adds the request boundary automatically. You can inspect the final request in Chrome's Network Inspector too to see if things are going through properly: http://blog.getpostman.com/index.php/2013/09/18/legacy-app-update-cookies-and-devtools-for-v0-9-x/

[stevemcmillen]

After comparing wireshark output for curl and postman, I realize that by not including the Content-Type: multipart/form-data header in Postman, I was able to successfully post the multi-part message. I still think its a POSTMan bug. Or maybe its a Chrome bug.

In curl, when I do not include the Content-Type header, it adds it and if I do set the Content-Type header, it modifies it to add the boundary. But in Postman, if I set the Content-Type header, the trace in wireshark shows that it is not appended with the boundary and the API falls on the server complaining about not finding boundary.

Here are my results viewing trace in wireshark:

curl with Content-Type: multipart/form-data
Content-Type: multipart/form-data; boundary=----------------------------247947f6cc02

curl w/o content type:
Content-Type: multipart/form-data; boundary=----------------------------771d82f4b7d6

Postman with Content-Type: multipart/form-data
Content-Type: multipart/form-data

Postman w/o Content-Type set:
Content-Type: multipart/form-data; boundary=----WebKitFormBoundarylTMBUUyXqgLqmAdj

[a85]

@stevemcmillen I think the issue is that the custom Content-Type header overrides the default Content-Type header that should be sent. I think Postman should just not allow a custom header for form-data as that'll be added anyway.

[Vratislav]

Just wanted to say that this cost me 8 hours of debugging when I thought I have something wrong with my Java application. I had the custom Content-Type header present with the correct multipart/form-data value and that was the issue.

[JasonLawrenceDuncan]

Ugh - same here! I was pulling my hair out over how such a simple thing was failing and this was it!

[dlancea]

Can this issue be reopened?

I also ran into this bug. If Postman is going to present a cURL command, it should be correct. The way it is now, this is going to be incorrect for all POST commands with form data.

[rakeshjoezoo]

Same issue here.

[eduedix]

+1

[squallssck]

+1 ... it cost me a whole night to debug my java code until I found the post works in a purl post html...then, I remove the custom header " content-type multipart/form-data" in postman, it works...

[gautiermichelin]

+1 very interested in a postman solution

[Sam-Gram]

+1 Same issue, I want to use the multipart upload with an additional content type. This currently will not work due to this bug.

[paulcullin]

+1 multipart/related requests do not work either. If you remove all request headers, but have JSON post body data plus a file attachment, postman automatically adds a Content-Type=application/json header back in. If you specify Content-Type=multipart/related, the post body data gets reset to plain text which will not be accepted by endpoints expecting body data as JSON.

[greggalbreath]

Why is this closed if this is still an issue? I have wasted time also, assuming that my application was wrong.

[Zooeee]

Is this still not solved?

[a85]

I am not sure what is the bug here? I believe we have another bug tracking that adding custom content-types individually for each multipart data.

[a85]

multipart form uploads work just fine. Just don't specify a custom Content-Type. Your content-type is going to fail otherwise because the form-data boundary is determined by the XHR library internally. If you want to use your Content-Type, then you will have to construct your request separately and paste it as text in the "Raw" mode.

[Sam-Gram]

Sometimes I need a custom Content-type, and also need multipart. I finally learned cURL because of this bug.

[stevemcmillen]

The only problem is that folks its not obvious you can't set a content-type header when doing multi-part but clearly that breaks the request. This can take some time to figure out why. I think what would help folks is if POSTMan did one of the following:

1. Show Warning in the Headers tab if Content-Type header added and "form-data" selected in the body tab
2. Do not allow Content-Type selection if multi-part body
3. Automatically ignore / overwrite Content-Type header if submitting a multi-part body

#1 seems like a better solution since it make it obvious to the user what is wrong

[chrisco512]

Definitely cost me 5-6 hours of time not realizing the fix was to remove the Content-Type header altogether. This is not very transparent. Would recommend a warning tooltip or something similar.

[albertdev]

The only problem is that folks its not obvious you can't set a content-type header when doing multi-part but clearly that breaks the request. This can take some time to figure out why. I think what would help folks is if POSTMan did one of the following:

1. Show Warning in the Headers tab if Content-Type header added and "form-data" selected in the body tab
2. Do not allow Content-Type selection if multi-part body
3. Automatically ignore / overwrite Content-Type header if submitting a multi-part body

3B) Variant of number 3: detect that the custom content-type header starts with "multipart/" and append the newly generated boundary parameter to the Content-Type header before sending.

I want to use this to send a multipart/mixed or even some custom type starting with multipart/ while keeping the convenience of the "form-data" body GUI type.

[albertdev]

For my case though, Postman could also look for the custom Content-Type header containing multipart/mixed and check if it already contains a boundary= parameter, then use that one instead of generating a new one.

Maybe I should create a new feature request.

[baselsalam]

@albertdev that's exactly what I expected postman to do. Honor the boundary if I include it in the header.

[hernanBeiza]

@albertdev How did you manage to run postman and form-data?

[albertdev]

@hernanBeiza

How did you manage to run postman and form-data?

Badly. I simply tested my API with some custom code as a client instead.

[ghost]

Not sure if things have changed recently but now the problem i have is content type is multipart/form-data for the main header. But inside the boundary it has application/octet-stream whereas my file is json so it should be application/json

Is there a way to say my uploaded file is of type application/json and dont think it is application/octet-stream

[techyaura]

I got the same issue, but when i set the header [ enctype : multipart/form-data ], i got the result.

[LusciousPear]

Same, this happened to me as well with a few nights of wasted debugging time.

[yoqu]

question +1

[dylandechant]

still not solved. killed my morning.

[oligriffiths]

I'm experiencing the same issue. When selecting multipart/form-data adding a file part, with the name data, I see no files being received by the server. Additionally, when clicking the code link on the right below the send button, I get this:

POST /my/url HTTP/1.1
Host: my.host
Postman-Token: 0b19b833-46cd-3a5a-4ca2-019eab425403
Content-Type: multipart/form-data; boundary=----WebKitFormBoundary7MA4YWxkTrZu0gW

------WebKitFormBoundary7MA4YWxkTrZu0gW
Content-Disposition: form-data; name="type"

photo
------WebKitFormBoundary7MA4YWxkTrZu0gW
Content-Disposition: form-data; name="data"; filename=""
Content-Type: 


------WebKitFormBoundary7MA4YWxkTrZu0gW--

The filename field contains no value. I selected a simple image, nothing fancy. However the curl output does contain almost the correct info:

curl -X POST \
  'https://my.host/my/url' \
  -H 'content-type: multipart/form-data; boundary=----WebKitFormBoundary7MA4YWxkTrZu0gW' \
  -H 'postman-token: 031d3463-7cf3-74a8-01bf-a4f5861b1f70' \
  -F type=photo \
  -F 'data=@image.jpg'

This does not work if content-type header is present, if that is removed, curl generates the correct request and files are received. Postman should not include a content-type header for multipart/form-data and curl output.

[oligriffiths]

Here is the charles debug output:

POST /my/url HTTP/1.1
Host: my.host
Connection: keep-alive
Content-Length: 140
Origin: chrome-extension://fhbjgbiflinjbdggehcddcbncdddomop
Accept-Language: en
Content-Type: multipart/form-data; boundary=----WebKitFormBoundarynaPOuvWrstplBY0y
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.115 Safari/537.36
Cache-Control: no-cache
X-Identifier: 123123123
Postman-Token: 2777da5f-5b25-86cf-2fac-3f59d00431ee
Accept: */*
Accept-Encoding: gzip, deflate, br
Cookie: tmgioct=5982249a2d78d90938463540

------WebKitFormBoundarynaPOuvWrstplBY0y
Content-Disposition: form-data; name="type"

photo
------WebKitFormBoundarynaPOuvWrstplBY0y--

Here is the postman screen:

As you can see, file is selected, but does not show in the request

[pedrolarap]

Buenas noches Oligriffiths, pudiste resolver el problema?
Me sucede exactamente lo mismo.

[reteps]

Wow I wasted some time

[patrickjamesbarry]

Came across this issue when trying to troubleshoot why my request was not working. I was setting Content-Type myself AND postman was automatically doing it behind the scenes. Not the expected behavior I was looking for and burnt some time on this (like everyone else on here).

curl -X POST \
  https://upload.service.com \
  -H 'Cache-Control: no-cache' \
  -H 'Content-Type: multipart/form-data' \
  -H 'Postman-Token: 6a97f2ea-4b16-4d45-a708-46b06004dca3' \
  -H 'content-type: multipart/form-data; boundary=----WebKitFormBoundary7MA4YWxkTrZu0gW' \
  -F '=@/Users/pbarry/Desktop/Screen Shot 2017-12-13 at 9.11.33 AM.png' \
  -F Field1=MyTest

[starkshaw]

I have a similar issue. The -XPOST in curl does not work in Postman.

[jota-oliveira]

I got the same issue, but when i set the header [ enctype : multipart/form-data ], i got the result.

Thanks a lot!

[iamprakashom]

In 2020, I am getting the same error. API is working fine when posting data from HTML form but not working from the postman. Getting error "The submitted data was not a file. Check the encoding type on the form."

Postman version - 7.32.0

[richard-bubble]

+1 - ended up writing a python script using requests, which is slightly easier to work with as a test harness than curl

[QCTW]

Got the same issue as in 2021! Increadible

[LordEvron]

And in 2022 too...still not working...

[shubhbhargav]

@LordEvron Can you open up a new issue and share the screenshots / recording of the issue? Based on the previous comments, the issue could be a custom Content-Type being added in the request (need to verify the same).

Closing this thread off to ensure that we don't miss out on any future comments / issues pertaining to this.