I was having the hardest time getting a POST request working today, finding that it worked with variables in the traditional JSON body type, but then whenever I changed to CUSTOM, I would get a 415 error back. Setting the “request content type” to application/JSON was not working, so I ran a quick test with netcat and discovered that box appears to be non-functional. If you select the CUSTOM request body type (I was trying to handwrite an http POST command), the Content-Type in the header ALWAYS gets sent as text/xml, which generates a 415 error with some (many?) http API endpoints who want json.
Content-Type not set with custom POST [local network]
ipaterson
#2
Is this request going to a server on your local network or to a normal remote URL? Web requests outside your local network definitely use the content type header that you specify, but I can’t test a local request right now.
If you are seeing the wrong content type please send an anonymized green snapshot of a piston showing that behavior. I test with requestcatcher.com which provides a URL for your piston to hit and shows the exact details of all incoming requests.
Is it possible that the JSON body is invalid and causing the server to interpret it as a different type of data?
ipaterson
#3
I missed “netcat” in the OP which tells me everything I need to know. This affects local requests, doesn’t seem that the content type is passed through (or ever was for JSON/form). Requires a smart app release to fix the bug, thank you for reporting.
xomnia
#4
Yes it’s local (as you figured out). Glad I was able to help, and thank you for looking into this so quickly!
ipaterson
#5
I have confirmed both of the following for local network requests
- Content-Type is ignored when request is CUSTOM
- Content-Type is always application/json (and request body is JSON formatted) regardless of whether you select JSON or FORM
This will be fixed in the next release. I have confirmed that the fix
- Sends your request body exactly as written with whichever content type header is selected (i.e. doesn’t attempt to convert form or json payloads)
- Sends FORM requests with the proper
key1=value1&key2=value2encoding - Allows any value for the Content-Type header (e.g. specify “text/foo” as an expression); for remote web requests SmartThings throws an error if the type is not explicitly supported.
- Does not interfere with existing local JSON requests or GET requests which were already working
Creating and sending a JSON Object for POST HTTP Request