As far as I know it is about the response’s content type, is that correct?
When I do the request in Postman, I get the response Content-Type: “application/json; charset=UTF-8”
A request, which returns with content type “application/json;charset=UTF-8” does work.
Is the blank inbetween the content type and the charset a problem?
Both requests worked in the old platform, so by directly calling $request.get or $request.post.
isn’t there anyone with access to the code, who could check my assumption on response’s content type?
I need to enlarge the functionality of my app and wanted to do the move to FDK9 first.
Now I am stuck with this problem, which did not exist in FDK8.
I understand that you are facing an issue with the migration of your custom app to the new platform. Regarding your query, yes, the 415 error is due to the unsupported content type by the server.
In the header section of the response, the Content-Type attribute is used to indicate the content type of the response. In your case, the difference seems to be in the presence or absence of whitespace between the content type and the charset parameter. The presence of whitespace is causing the server to respond with an unsupported content type error.
To resolve this issue, you can modify the format of the response content type to include the charset without any whitespace, like this:
"Content-Type": "application/json;charset=UTF-8"
I hope this helps! Let me know if you have any further questions or concerns.
Both the request and response content types are validated. You can set the request body’s content type in the headers. So, I suppose it’s the content type of the response.
These are the supported content types:
‘application/json’
‘application/xml’
‘text/html’
‘text/xml’
‘application/jsonp’
‘text/plain’
‘application/javascript’
‘application/vnd.api+json’
The content type mentioned before the comma (;) is only compared here, and the space after is not important.
Could you check the FDK debug logs while facing the issue to see the response content type you get? When you face this error, you will see what content type it gets and compare it with this list.
Also, as another step, could you publish this app anyway as a custom app and test once if it works in the cloud environment?
I did not know the debug mode. With it I found out that I had a upper-/lower-case typo in the path parameter.
The request was done without it and the server answered with content-type “application/problem+json”.
