Hello, sorry for my noob question,
i want use
https://rpinotify.it/invio-di-testo.html
but i can’t send post message :
(i edit http: for new user limit post)
my flow:
inject: with string text=“my message”
http request:
POST
URL: https://api.rpinotify.it/message/secret__key/
Debug:
2/7/2018, 14:27:27node: 71562e38.b607
msg : Object
object
_msgid: "6ba64316.5fed7c"
topic: ""
payload: "text = prova"
2/7/2018, 14:27:27node: 71562e38.b607
msg : Object
object
_msgid: "6ba64316.5fed7c"
topic: ""
payload: "{"info": {"datetime": "2018-07-02 12:27:27", "ip": "54.149.86.44, 108.162.246.239"}, "message": "'text' or 'img' POST parameter are required", "response": 400}"
statusCode: 400
headers: object
date: "Mon, 02 Jul 2018 12:27:27 GMT"
content-type: "text/html; charset=utf-8"
transfer-encoding: "chunked"
connection: "close"
set-cookie: array[1]
contenttype: "application/json"
x-content-type-options: "nosniff"
expect-ct: "max-age=604800, report-uri="https//report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct""
server: "cloudflare"
cf-ray: "43411b48ce952a8b-SEA"
x-node-red-request-node: "6a8695e6"
responseUrl: "https//api.rpinotify.it/message/secret__key/"
responseCookies: object
__cfduid: object
expires: "Tue, 02-Jul-19 12:27:27 GMT"
path: "/"
domain: ".rpinotify.it"
value: "dac023f71cfd378a6e57f9634072f5db01530534447"
So…have you looked at what is in the payload from the debug?
can you kindly explain yourself?
Look thru the results of the debug you have provided and find the part that says
payload:…
what does it say?
Payload is correct for me
payload: “text = prova”
Can you explain me ?
There are 2 messages in that debug you pasted. Look at the second payload
Just to be a bit more explicit - the second message in the debug output you’ve shared has a payload which is the response from the rpinotify api. It includes an error message telling you what is wrong with the request you’ve made.
Rather than set msg.payload to the String text = prova, try configuring the Inject node to send an Object (pick ‘JSON’ in the list of types) of { "text": "prova" }. By default, the HTTP Request node will send that as application/json content. The API might accept that. If it doesn’t, then you’ll need to set the content-type to form-urlencoded. To do that, use a Change node to set msg.headers["content-type"] to the String application/x-www-form-urlencoded
1 Like
yeah!
the problem is
"To do that, use a Change node to set msg.headers["content-type"] to the String application/x-www-form-urlencoded"
OH, and another problem is that if you use the change node to set msg.headers["Content-type"] with a Capital 'C', the incoming msg.payload is empty!
There goes another hour... and a good bit of my remaining hair! Shouldn't the behavior of the http nodes not be dependent on the correct case of any headers?
what is handling the request at the other end ?
That would be the http in node inside the same instance of node-red -- which in this case would have worked, I think, if it wasn't for the mangled request url (missing the host:port)
On the receiving side I have this:
and the sending flow's http request seems to reference it, using this config:
If I use a relative url in the http request node, I get a 404 error, with this responseUrl: http:///zippi/users which explains the 404 not found error -- this is a separate issue I mentioned on slack.
But, while trying to describe the problem here, I'm not seeing the same behavior -- of course. So it must be related to the fact that upstream from this http request is another http request node that is muddying the wires... or at least my request headers. What is the best practice for cleaning up a msg object between requests?
The request node is like a browser - if you type /foo into a browser it won't go to http://localhost:1880 either...
Depends how clean you need it - a change node to delete msg.res and msg.headers may be enough. Or a function node to return a completely clean object.
Not sure re Capital C - we do send it out with whatever capitalisation you set... - but the http in node seems to flatten it to lowercase anyway so shouldn't be an issue.
Do you have a simple demo flow that shows the problem ?
That is true, when typing into the browser... but not strictly true, when you are talking about html components. Any element with src="/foo" is considered to be relative to the current host:port -- and any url without a leading slash is relative to the current page's url.
This behavior is built-in to many web components:
<style href="/my/styles/xyz.css">
<img src="./image/local.jpg">
<form action="/upload/page.html">
<button onclick="myjs/logic.js">
etc.
But since the http request is being made from the server's runtime, I guess there is no url context that can be used to "build up" a relative request uri into an absolute url? The runtime knows its own host:port info, doesn't it? Although many host dns names could map to the same server, and reverse proxies could be even more confusing...
correct - as you point out - this isn't inside a web component - this is a request client.
You can of course pass in the url to the nodes so you can make it as dynamic as you like.
