Issues with the File REST API?

File Service
1

Hey guys,
did you change anything on the File REST API recently? Or do you have any issues with the API/servers?
Getting only “Corrupted multipart request. File content is absent in request body” error messages when I try to upload something to the File API.
The code worked definitely some time ago. Since then the code was not touched and the version is used by some customers.

The client application is a C++ Qt application. Hope this code sniplet helps, since this is only a small fraction, but the part which is responsible for the REST API access and upload of the file.

QEventLoop eventLoop;
QNetworkAccessManager *manager = new QNetworkAccessManager();
connect(manager, SIGNAL(finished(QNetworkReply*)), &eventLoop, SLOT(quit()));

QString ServerAddress = getApiServerAddress() + ":" + QString::number(getApiServerPort());

QHttpMultiPart *multiPart = new QHttpMultiPart(QHttpMultiPart::FormDataType);
QHttpPart zipContentPart;
zipContentPart.setHeader(QNetworkRequest::ContentDispositionHeader, QVariant("form-data; name=\"\"; filename=\"\""));
zipContentPart.setHeader(QNetworkRequest::ContentTypeHeader, QVariant(mimeType));
zipContentPart.setBody(binaryData);
multiPart->append(zipContentPart);

QString Url = ServerAddress + "/" + getApiVersion() + Files + "/" + fileUrl;
if (overwrite == true)
    Url = Url + "?overwrite=true";
QUrl postUrl(Url);
QNetworkRequest postRequest;
postRequest.setUrl(postUrl);
postRequest.setRawHeader("user-token", getUserToken().toUtf8());

QNetworkReply *postReply = manager->post(postRequest, multiPart);
connect(postReply, &QNetworkReply::uploadProgress, this, &onUploadProgressUpdate);
eventLoop.exec(); // blocks stack until "finished()" has been called

if (postReply->error() == QNetworkReply::NoError)
{
}

…

2

Hello,

I have checked our release history, there is nothing has been changed in Files API for a long time.
Also I have checked this endpoint using REST API and it works fine for me. Don’t know what’s going wrong here. Can you verify that you making correct request? Any chance that some library of whatever you’re using for request has been updated and broke this functionality? You can also test this endpoint using Postman or another tool.

Regards,
Stanislaw

3

When I try to upload something with Postman I get the same error.
This is my command which Postman generates:
curl -X POST
https://api.backendless.com/63087FF7-7E1D-973D-FF3B-D5F0740FA100/5C363F28-6536-9660-FFAF-xxxxxxxxx/files/test/test.txt
-H ‘Content-Type: multipart/form-data’
-H ‘Postman-Token: c816d9f0-b4d3-4266-ae93-5f3ce2750da5’
-H ‘cache-control: no-cache’
-H ‘content-type: multipart/form-data; boundary=----WebKitFormBoundary7MA4YWxkTrZu0gW’
-H ‘user-token: E5626D8D-1A67-B5FA-FF53-xxxxxxxxx’
-F test.txt=ContentThatDoesNotMakeSense

I get this error:
{
“code”: 6011,
“message”: “Corrupted multipart request. File content is absent in request body”,
“errorData”: {}
}

This is what the HTTP request from Postman looks like

POST /63087FF7-7E1D-973D-FF3B-D5F0740FA100/5C363F28-6536-9660-FFAF-xxxxxxx/files/test/test.txt?overwrite=true HTTP/1.1
Host: api.backendless.com
Content-Type: multipart/form-data; boundary=----WebKitFormBoundary7MA4YWxkTrZu0gW
user-token: E5626D8D-1A67-B5FA-FF53-xxxxxx
cache-control: no-cache
Postman-Token: fa2145d1-410b-4740-98eb-232278436077

Content-Disposition: form-data; name=“test.txt”

ContentThatDoesNotMakeSense
------WebKitFormBoundary7MA4YWxkTrZu0gW–

4

Ok, I’ve reproduced this issue. It happens only when the file content is empty.
I’ve created an internal ticket to fix this issue. We will keep you informed here.
Thanks for reporting this!

Regards,
Stanislaw

5

Ah ok thanks.

But the file content in the request above is not empty. Why is that then?

Content-Disposition: form-data; name=“test.txt"

ContentThatDoesNotMakeSense
------WebKitFormBoundary7MA4YWxkTrZu0gW–
6

It’s not a content itself. It’s just a boundary.
Or do your file ‘test.txt’ contains any content if you open it?

7

You can reference to internal ticket by it’s id: BKNDLSS-20754

8

Sorry for the late reply. I fixed it on that day. Found out, that the filename attribute in the content header must not be empty. Until a week (or a few days more) this was definetly possible. Might this be a change in one of the libs you are using? Our application worked like this for more than a year.

Content-Disposition: form-data; name=“test.txt" **filename=""**
9

It’s related to recent changes on the server side. Not a library issue.
Glad you have fixed this. We will fix it on our side too.

Regards,
Stanislaw

10

Hi @jonas-eberhard,

We’ve updated cloud servers with a fix for the issue you described above. The problem is not reproduced anymore.

Regards,
Marina