I'm the person who maintains the API that is in question. I've been trying to figure this out and have discovered that this is actually a continuation of this:
That thread starts out looking like something else, but morphs into the real issue. I think the analysis and resolution is flawed, but have the nagging feeling I'm missing something obvious.
Just want to bring in @unixneo, @knolleary, and a couple of others but I hit the new user limit (at Andrei, at Waynedejager if they are still interested.
This thread on the IoTaWatt forum shows how (at)samos has tried using some other APIs on IoTaWatt and they worked fine. He also used a much simpler (no non-URL characters) query API and it failed. The only perceived difference is that the failing requests elicit CHUNKED) responses.
To sum up the previous thread from March on this forum, the Chunk headers and delimiter were interpreted as a malformed response. A "solution" was proposed that essentially used a php script to remove a chunked header and trailer and send the response as if it wasn't chunked. That seemed to work on the 086x length response in question, but the query API can and does regularly send up to 100Kb and is capable of sending megabytes. When it starts, the ultimate length is unknown and so the HTTP/1.1 chunked encoding (sorry, at my newbie link limit so google chunked transfer encoding wiki)
What I can't understand is why node red doesn't seem to recognize chunked responses, and seems to have no hits when I google it. It's been around quite awhile.
I have recreated the node-red issue reported here and tested these various URLs myself. I've changed the chunked response in several ways with no luck. In all cases the responses still work with browsers and the HTTPrequest in various javascript apps.
What I'd like to find out is if there is support for chunked that I'm just missing. It looks as if I could drop down to the tcp in/out level and decode and aggregate the chunks into a string, but that seems foolish when it's such a ubiquitous function.
