callWithPOST change content type

Daanyoo

@Christoph-Hart That was the solution! Thank you so much!!!

Daanyoo

@Christoph-Hart Another problem im still facing is the JSON encoding issue that was also mentioned in the linked thread.

Im struggling to send a POST with regular application/json Data, as HISE seems to package the data into x-www-form-urlencoded when using Server.callWithPOST. Everytime I'm trying to send out a POST request to receive a license token I'm getting a 415 error.

Do you have any idea how to change the format of the request in a way that the regular JSON dictionary will be transferred?

Checked the request and its format with Postman:

Using the x-www-form-urlencoded (same as HISE probably uses)

Using the JSON dictionary to receive a license token:

Christoph Hart

@Daanyoo how are you passing the JSON data into the callWithPOST() function? If it's a JSON object, then it will be converted to post parameters, so if you want to actually send a text string containing JSON formatted data, you'll need to convert it into a string using trace(obj).

Daanyoo

@Christoph-Hart this is how im passing the JSON data:

inline function requestDirectLicenseActivation(deviceName, deviceSignature, accessToken)
    {
        local requestData = {
            "deviceName": deviceName,
            "deviceSignature": deviceSignature
        };
        
        currentAccessToken = accessToken;
        
        makeHttpRequest("POST", "/client/licenses/" + PRODUCT_ID + "/request", trace(requestData), handleDirectLicenseResponse);
    }

Even when converting the JSON object using trace, I'm getting the 415 error due to an unsupported media type, as the endpoint will not receive the content as application/json, as its converted to x-www-form-urlencoded data.

Christoph Hart

@Daanyoo Can't reproduce it here. The content type has to be set before calling callWithPOST(), but then it goes through without problems and calling trace() makes it pass the raw JSON string instead of parsing it as POST arguments.

application/x-www-form-urlencoded only appears if I set a empty HTTP header as this is what it defaults to. Why is there an authentication token in your header response?

d.healey

@Christoph-Hart I think this is the same issue @hisefilo and I had in the other thread.

Christoph Hart

@d-healey yes but this is solved - you have to pass in the JSON as string to append it as POST data - I‘ve removed the type check that only accepted JSON objects for this method.

d.healey

@Christoph-Hart Ah yeah, just tested and it's working here

https://posttestserver.dev/p/y1n6045ukg04hp7k/latest

HiseSnippet 1210.3ocsVs0TaaDEdEfxDbZ5zLSerOriexzAhk.gSBc5zfMPvPv3h4Rxz1gYszZzhj1UY2UF6lI+m6+f1yJIrMDnMCSidvi2ys8aOmuyY2tRgOUoDRjUkiGmRQVeicuwbcXqPBiiZuEx56r6JT5ioJcOpbHUhZNNknTz.jk07uwXk0hKfx+9qeoIIlv8oSEgPmJX9z2xRX5oR6958Yww6PBnGyRlwZuW21WvaIhEY.hl21AkR7iHWP6PLlMmMZWhJDY8i19MVcs9NMB7ItubcO+0CHAj0dEwKviNvyaUGGW5.mWQGfrdz1ALsP1SSzTExZglhfw8BEWwK1fSYJV+XpYgKpGryEh2QDGXNhFonVgr3ftWmpTHHJcml3luHw881GvBXSjOaBzn.O0iYSfVycS3M+Mfm6rvyYF3cGPxZFHsPAjdlcOeIKUOUiAOOwtMWSkCHPcZVnTXKZN24saI.K35mmPhn6HgES7nVCGmkwvOK8SUpTofQ7bEU2jnnmbzaqUMTqSUaTudJPZfSjVUXR.cXUvkoNrKX2tTfAHqUsb6Vwf5MvjzzXlOQyD75WpD7emuYlNTHY+YtrMvMoDIUhUQqjJEWtRT68ECCCeyIsCVa2yXQW0g7xMujKjCNZ3ImMjNrOUddx3zNcUD0oYoMyVejely3FiF51Yz9CZuin4YeHht19eHq4wq0LtezN6c5g9tIwt+Zr2oQTUn6lmLZydC6DJ6tWDoSqAM6zMt8I9dqR1izSIx5rWiKWe02E6EPbNeTq2Gv5HOa+gMNXyp4YpJ.uVowCIRbJF+y3OVACeUSDAz3pafqdQpdEOQ0kKECUKf0q.M+VtDy2Gm7ubajhXpwyLHCW52Dc9EITi5qjLMESv.cLJCS5KxzXBq5D6+T9+9iJeJGk0qi6dXuiw9j33qKVl+eFSGZTTqZ8z5ic4Mb7VOK5BGuvzWDkWqqtLNcY7fLtuoHUSA74L0xXIUkBmb5R.7qrHTnU.redpjw00zRCgZhEPd5VFTDDP9mxygWGbrf2QnoGxqsTkOVYwJvQ31pFL3N0YHZPdKFHc2kZyvH4+li03YI.aZYnNFmQmXHzvcytX66uKd1gLkkoYLTvayY5CSo76azCprYwzwWhJvTcd+92V1u2LSqEbDCZqWztul2ixCP4Pd1Y0nSZuEQStNPPLg8IkJ0LyQvZK5PXvcwfjEs2hphzhTXqZIRf5kAAV1eAa6nYuKX7rKzzQPLdr817gLhzbvtcfeZYfeKoOMNOtOwVOx.yDXP08E41utHxOxNTDS9xh6Ssi6GeTIS7di76Ki7OXusTJjXJGGSv.gk4yzYAaf8b7fK29r4vvM.hfrXh9lWKXt7rTAvxtwrXy7VthoGOaA6+s6J9Rg3yr6xz9g2MFm6NvHvk9ZfwxaXep81CFP80SA3B167tuNWmhNBFTx3Wb.QKY.evtSVRO3UI9TX24bZroK2ZNS+XwZGyZSFvv5yW72vWoRWyZqRktWqDkP7khy8K5hM2g+3bI.l34u2YQ6CLqwt2t4EgRfmTbtu+MC0m43pOTGW6g5n2C0w0enN13g53KdnN9x+aGMu3Cd0hHonsAgNn614Casr1lS.FXNaE8OfASM7C

Edit: Actually this snippet sends it as an object, not a string, and it seems to still work.

Christoph Hart

@d-healey if you don‘t convert it to a string then the JSON is converted to post arguments, no?

d.healey

@Christoph-Hart In the link I posted above, it shows the result like this, regardless of if I convert to a string first:

content-type application/json

Body

{ "model": "gpt-4o", "messages": [ { "role": "user", "content": "write a haiku about ai" } ] }

Edit: Ah but if I don't convert to string it seems to lose the authentication header, strange..

Christoph Hart

@d-healey ah yes true this is because the JSON has an Array element - HISE checks this and then converts it to a String internally (because it cannot pass an array as post parameter).

Daanyoo

@Christoph-Hart I found the mistake - I had accidently reset the Server.HttpHeader() of the request when passing it into the makeHttpRequest function. Therefore only the the Auth Bearer Token was passed and the Content-Type was automatically set by HISE. Now I correctly appended the Bearer Token within the request and everything works perfectly fine :)

Thank you guys so much for your help, I really appreciate it!!

Christoph Hart

@Daanyoo Alright, good to see it resolved.

Ah but if I don't convert to string it seems to lose the authentication header, strange..

I just looked at the code and it makes sense:

if(isComplexObject)
{
	extraHeader = "Content-Type: application/json";
	url = url.withPOSTData(JSON::toString(parameters, true));
}

this is the branch if you pass in a JSON with an Array and as you can see it replaces the extraHeader content with the JSON type definition. However this trashes whatever you've set before so your Authentication token goes out the window.

There are multiple ways to solve this, but I'm not sure which route to take:

append (or prepend) the Content Type definition to the existing header (unless there is already a Content type set, then ignore it)
just don't fiddle with the content type at all here and let the user figure that out.

Both are potentially breaking changes (while the first one is less intrusive) so let's proceed with caution here.

d.healey

@Christoph-Hart I think the first one is the safest option

callWithPOST change content type

25

2.0k

12.8k

111.0k