ServiceNow Unable to Process the Request Body with a Content-Type 'application/x-www-form-urlencoded' while using Scripted REST Web Service

surendarm
Kilo Expert

Hello All,

Scenario:

We trying to connect with a third party application where they can consume our API and send us the request to be processed and update the incident record.

Issue:

The Content-Type of the request body is 'application/x-www-form-urlencoded' and ServiceNow is unable to process the request.

  • Based on the link, we can override the 'Content-Type' to application/x-www-form-urlencoded
  • But, we aren't able to receive the body using 'datastream'. We have used this same script by referring the link
  • When we print the body, it shows 'com.glide.communications.GlideScriptableInputStream' in the logs

Kindly let me know if anyone has worked on processing the request body with the Content-Type as 'application/x-www-form-urlencoded'.

Thanks in advance.

Regards,

Surendar M

17 REPLIES 17

Ben Vargas
Tera Guru

Hi Surendar,



I ran into the same thing today with the response sent by Slack message buttons which use the 'application/x-www-form-urlencoded' Content-Type. I first tried this method by dave.slusher in his blog post: Accepting Scripted REST Connections for Weird Content-Types but that didn't get me anything but a null value for the input variable; I found the first reader.readLine() was always returning null. Perhaps this message type doesn't work with dataStream?



In my Slack use case, the POST being made to the registered action URL used by their message buttons appears to place the JSON string into the request.queryParams object using the payload attribute/parameter. Therefore, following the JSON in the 'Responding to message actions' section here (Attaching interactive message buttons | Slack), I have been able to successfully get the JSON payload being sent in the 'application/x-www-form-urlencoded' request.



You didn't say if you're integrating with Slack or something else, but investigating what is in request.queryParams may be of use to you (or others trying to get a button response from Slack).



var payloadObj = JSON.parse(request.queryParams.payload);


gs.log('payloadObj.actions[0].name: ' + payloadObj.actions[0].name);


gs.log('payloadObj.actions[0].value: ' + payloadObj.actions[0].value);


gs.log('payloadObj.actions[0].type: ' + payloadObj.actions[0].type);


gs.log('payloadObj.callback_id: ' + payloadObj.callback_id);



Good Luck,



Ben


dave_slusher
ServiceNow Employee
ServiceNow Employee

I can duplicate what you are seeing. I am looking at the underlying code of GlideTextReader and it is simply a wrapper around the java BufferedReader so no fancy logic around readLine(). This implies to me that the request object is eating the url encoded input somehow



If I take the same request to a simple Scripted REST API and send it as x-www-form-urlencoded with some fields, I get empty. If I send the same data in a raw body with text/plain, I get the body back via the readLine() method. I will take this up with the dev team to get some clarity. Thanks for bringing up the issue.


Hi Dave,



Thank you for your time to check on this issue.



It would be really helpful if we can have a break through on this issue which will aid me to develop 'Bi-Directional' integration between ServiceNow and SMS Gateway provider.



I look forward to hear from you.



Regards,


Surendar M


Hi Dave,



Hope you're well.



As per your comments with reference to the issue of request body being unable to be processed when the content type 'application/x-www-form-urlencoded' in a scripted REST Web Service, could you please let me know if there is any update so that we can incorporate that into our solution to make the bi-directional integration happen.




Regards,


Surendar M