POSTing to /pictures REST API fails with Parameter 'data' is required

Posted in General by Stuart Langridge Fri Apr 01 2016 10:16:10 GMT+0000 (UTC)·3·Viewed 2,141 times

I'm trying to save a picture, and Buddy consistently rejects what looks to me like a valid request. I'm sending a POST body thus: ----------------------buddy-ubuntu-uploader content-disposition: form-data; name="data"; filename="pic.jpg" Content-Type: image/jpeg Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAgGBgcGBQgHBwcJCQ...(shortened for convenience) ----------------------buddy-ubuntu-uploader content-disposition: form-data; name="body" Content-Type:application/json {"readPermissions":"App","tag":"Birmingham, GB","writePermissions":"App"} ----------------------buddy-ubuntu-uploader (with content-type multipart/form-data; boundary=----------------------buddy-ubuntu-uploader) The error I get back is: { "status": 400, "error": "ParameterMissingRequiredValue", "errorNumber": 513, "message": "Parameter data. Parameter 'data' is required and must be passed as non-empty value.", "request_id": "56fe440f02f8d113f412b877" } I've tried using the JavaScript SDK in the Console with the following code: var validjpeg = unescape("%FF%D8%FF%E0%00%10JFIF%00%01%02%00%00d%00d%00%00%FF%EC%00%11Ducky%00%01%00%04%00%00%00%00%00%00%FF%EE%00%0EAdobe%00d%C0%00%00%00%01%FF%DB%00%84%00%1B%1A%1A)%1D)A%26%26AB%2F%2F%2FBG%3F%3E%3E%3FGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGG%01%1D))4%264%3F((%3FG%3F5%3FGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGG%FF%C0%00%11%08%00%08%00%19%03%01%22%00%02%11%01%03%11%01%FF%C4%00a%00%01%01%01%01%00%00%00%00%00%00%00%00%00%00%00%00%00%04%02%05%01%01%01%01%00%00%00%00%00%00%00%00%00%00%00%00%00%00%02%04%10%00%02%02%02%02%03%01%00%00%00%00%00%00%00%00%00%01%02%11%03%00A!%12%F0%13%041%11%00%01%04%03%00%00%00%00%00%00%00%00%00%00%00%00%00!1aq%B1%12%22%FF%DA%00%0C%03%01%00%02%11%03%11%00%3F%00%A1~k%ADN%B6K0%EA%E0%19%829%91%3Anc_%99%8Ah%B6%E3%EAp%08%A8%00U%98%EEH%227%1Cc%19%AF%A5h%B8%05%24%9A~%99%F5%B3%22%20U%EA'%CD%8C%EBN1%91%9DA%FF%D9") var f = new File([validjpeg], "filename.jpg",{type:"image/jpeg"});'/pictures', {data: f, tag: "tagorama", readPermissions: "App", writePermissions: "App"}, function(err, result) { console.log(err, result); }); This returns an error of "Invalid image data", but importantly that seems to be because it isn't working; the request it sends contains no content! It looks like this: ------WebKitFormBoundaryyNFqr61QbcxfgWBb Content-Disposition: form-data; name="data"; filename="filename.jpg" Content-Type: image/jpeg ------WebKitFormBoundaryyNFqr61QbcxfgWBb Content-Disposition: form-data; name="body"; filename="blob" Content-Type: application/json ------WebKitFormBoundaryyNFqr61QbcxfgWBb-- with no actual content in the parts. So, I don't understand what I'm doing wrong, and I have been unable to get a valid request done to compare them. Help?
Stuart Langridge
Apr 1, 2016


If I just upload the photo, without the associated metadata, then it works. So I send a multipart/form-data request with one part, "data", and I don't send the json at all. This is directly contrary to the documentation, but it works. :-)

Stuart Langridge
Apr 1, 2016

OK. I have now established that this is a bug in my client-side framework. However, it's arguably a Buddy bug too.

If you send a multipart/form-data request with header Content-Type: multipart/form-data; boundary=whatever, then everything works. If, however, you send a multipart/form-data request with header Content-Type: multipart/form-data; charset=UTF-8; boundary=whatever then Buddy will fail to parse the incoming request. The client framework I'm using forcibly adds a charset declaration to outgoing Content-Type headers, which they clearly shouldn't do, but equally Buddy ought to not fail on such requests! I suspect you are doing something slightly dodgy like assuming that a Content-Type multipart header only contains two parts or something equally naughty, rather than parsing it properly :-)

Any chance of a fix?

Bradley Serbus
Apr 5, 2016

Hi Stuart,

Thanks for tracking this down. I'll contact our dev team to get a timeline on a fix. Please contact me at [email protected] for follow-up.


Markdown is allowed