[Multipart/form-data] Getting a wrong media file typer error on sending PDF
Forge component by Kilian Hekhuis
Application Type
Traditional Web

Hi,

I have a REST service trying to send some text fields and a pdf to a third party for signing (Stiply).

I keep getting a response error stating the media file type is incorrect.
BTW: the text to binary does not seem to work for the text parts as the result is  there is no content in the MultipartFormData (I kept the functions in place though they are not used).

The BinaryDataToText shows empty text as output as well...

Thanks in advance...

StiplyISv25.oml

Thanks Kilian,

Adding the "application/octet-stream" does not make a difference. In fact I read one of your comments in a similar post which you advice against this suggestion made by someone else (??).

I did find the solution: adding '.pdf' to the name of the file as I discovered this was not part of the file name.

So, now it works without defining the content-type manually.

Thanks for your help!

mvp_badge
MVP

Great you found the solution. When you say "without defining the content-type manually", what do you mean? I assume you still use the output of the MultipartFormDataCreate as input to the ContentType parameter of the REST method?


Yes, I do, but I am not defining it in the actions before, leaving the contenttype field empty.

Set the request content-type to "application/octet-stream" and check whether same content-type is allowed in webserver (supported) mime-types.

mvp_badge
MVP

This is bad advise, the content-type of a multipart/form-data message should be multipart/form-data (plus the boundary used).

Suggestion is to set Content-Type in header. If the file is being sent to another program (Stiply), other program needs to identify filetype to open it with appropriate program. Hence i suggested "application/octet-stream". 

However, You are right normally "multipart/form-data" should work.


mvp_badge
MVP

Yes, but you didn't read it correctly. Johnny added a picture of the API description, which explicitly says multipart/form-data.

EDIT: Oh, you might be right, if you're referring to the ContentType of the PartAdd.

mvp_badge
MVP

Hi Johnny,

There's a few things to say here:

  1. "the text to binary does not seem to work for the text parts" - it's a System Action, and it works. I've never seen it fail. But it's binary data, so it doesn't display in the debugger;
  2. You have used a manual "Boundary--" boundary. I'd advise against this, just leave the Boundary parameter of MultipartFormDataCreate empty, and use the returned BoundaryUsed;
  3. You call ContentTypeGet as an Action, but you don't use the result. You also don't need this Action/Function, as MultipartFormDataCreate already returns the ContenType to use (as you've already done, I see);
  4. Although HTTP-headers should be case-insentive, I'd set the "Name in Request" parameter of SignRequest to "Content-Type", as that's the correct spelling (though again, "content-type" should work);
  5. You shared a Module that contains a Bearer token. You should really not do that. Although bearer tokens are only valid for a short time, a malicious person could use it to steal or destroy information.

Unfortunatly, none of these things will help you with your problem. So for trouble shooting, please increase the logging level of the REST service (in Service Center) and check whether the header parameters are set correctly, especially the Content-Type (the body can't be viewed since it's binary).

Thanx for your reply.

1. This is in the current context of the issue: when using textToBinary instead of 'Content' I keep getting the message that there is no content. So USING the TextToBinary does not seem to work.

2. I removed the "Boundary--"

3. There is more 'old' code in there (like I stated about the TextTobinary actions).

4. Like you said: it should work and I have never seen otherwise, but I changed it to proper casing.

5. The Bearer token is not valid so there is no issue there.

The stack trace with all logging levels up does not give me much more detail:

POST https://localhost.outsystemsenterprise.com/Stiply_IS/serviceapi/CreateSignRequest HTTP/1.1
Content-Length: 95
Content-Type: application/json
Content-Language: en-US
Authorization: Bearer xxx
Host: localhost.outsystemsenterprise.com
User-Agent: OutSystemsPlatform
OS-Host: localhost.outsystemsenterprise.com
OS-Path: /Stiply_IS
OS-Pta: /serviceapi
OS-Page: /CreateSignRequest
{"requestKey”:”xxx”,”inputParameters":{"DocumentarchiefId":9}}


HTTP/1.1 200 OK
Server: Microsoft-IIS/10.0
Content-Type: application/json; charset=utf-8
Authorization: Bearer xxx
{"outputParameters":{"Success":false}}


mvp_badge
MVP

Well, they give all the detail needed, as you can see that the request has a Content-Type of application/json, which should be multipart/form-data.

However, there's something strange going on with your Module, it might be caused by a bug in SS since I can't reproduce it:

When "Is Mandatory" is "Yes", "Send Default Value" should not be "No". In fact, when toggling it from No to Yes, "Send Default Value" automatically becomes "Yes". Of course I'm not sure whether this causes any problems, but personally I'd recreate the entire Method manually an make sure all Parameters are correct.

EDIT: I'll try to recreate access to the Stiply service, see if I have the same problems or not.

EDIT 2: The above shouldn't be an issue, it's a small bug in SS but not affecting anything, I think.

mvp_badge
MVP

Ok, I created a quick test (see attachment) that works insofar the header is concerned. In the logging this is visible:

POST https://api.stiply.nl/v1.1/sign_requests HTTP/1.1	
User-Agent: OutSystemsPlatform	
Content-Type: multipart/form-data; boundary="------55d6aed4-aed2-4fae-b4bf-bab697380ca9"	
Authorization: [redacted]	
Host: api.stiply.nl	
Content-Length: 6447

so it has a correct Content-Type.

TestStiply.oml

Thanks Kilian,

Adding the "application/octet-stream" does not make a difference. In fact I read one of your comments in a similar post which you advice against this suggestion made by someone else (??).

I did find the solution: adding '.pdf' to the name of the file as I discovered this was not part of the file name.

So, now it works without defining the content-type manually.

Thanks for your help!

mvp_badge
MVP

Great you found the solution. When you say "without defining the content-type manually", what do you mean? I assume you still use the output of the MultipartFormDataCreate as input to the ContentType parameter of the REST method?


Yes, I do, but I am not defining it in the actions before, leaving the contenttype field empty.

Community GuidelinesBe kind and respectful, give credit to the original source of content, and search for duplicates before posting.