Hi Kilian,

Thank you for replying.

I can confirm the filename has the name of the file

The below is from the swagger that I used to test the API:

Please let me know if you need more information.

Regards,

Abhishek

I see now you have the "Content-Disposition" header set to "form-data" in the PostUpload method. Are you sure this is correct? I wouldn't expect a Content-Disposition at all (also isn't present in the curl example). What happens if you remove it?

I added the "Accept" and "Content-Disposition" headers after  I tested it initially. I was getting the same bad request error before adding those 2 headers. Those 2 headers didn't do anything. I am also not sure what to pass for the Name of the Part since nothing is mentioned in the swagger.

You may try to save the output of MultipartFormDataCreate (the MessageBinary output) to a file, and inspect the content to see what message is being sent. If possible, you could post it (or the relevant parts) here.

I tried saving the MessageBinary output into a file(I'm not sure what extension to use so I didnt add it). It downloaded an empty text file where the size was 0KB. Do you have any idea why this happened? Please let me know if I was supposed to add a specific extension.

Just to make sure the binary isn't actually zero (I wouldn't expect it to be), could you add a check on the binary size (using BinaryDataSize from the BinaryData extension) and check in debug what the size is? (Note extension shouldn't make any difference when saving the file.)

So InputBinarySize is the size of the File variable and MultipartBinarySize is the size of the MessageBinary output.

Apologies, I just realized there was error which caused it to not pass the binary data back for download. After fixing the error I was able to download the file which I will attach in this message.(I added the txt extension after download since i couldn't attach a file without extension here)

I don't see anything strange there, this looks as expected:

--------197724bb-0e93-4844-a7a9-172d0430358c
Content-Disposition: form-data; name="TestPart"; filename="profileimg.png"
Content-Type: image/png

So I'd tentively conclude that this part is ok. However, in the curl example you posted earlier there's an X-CSRFToken sent along as header - is that a requirement you skipped? Because it's neither in your code nor in the dump from Service Center, so I assume it's not sent.

I have tried another API and I'm not passing that token. It is working just fine. Also I think that token is only passed during AJAX requests.

Mmm, ok. Then I'm frankly out of ideas. Everything seems like it should work. The only thing I can still think of is that the service doesn't accept the fact you say you send it a PNG, but it's not actually a PNG. The binary you attached shows the header of the file is:

RIFF~4  WEBPVP8

Which is not a PNG header, but a WebP header. A PNG file should start with:

ëPNG♪◙→◙

So you're basically uploading something that's not a PNG and saying it is a PNG. So try uploading a real PNG, and see how that goes.

Just to update, the issue was related to a UTF8 being applied to the request in the onBeforeRequest.

I just don't understand why these issues only occur in production. In all other environments, this wasn't an issue.

It's impossible to tell without a lot more information why it only occurred in production. My guess would be that it was by pure chance, the conversion transforming the binary data into something that wasn't accepted in production, while not doing so in test.