-
Notifications
You must be signed in to change notification settings - Fork 239
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fetch incorrectly handling response of content-length 0 #1080
Comments
I'll try to reproduce this later tonight. Thank you for including your test flow. |
I don't think I can reproduce this without the If it helps, I created this simplified flow that does not use the sensor or dashboard, to simplify my debugging. [
{
"id": "d08ce3b97bd479ba",
"type": "tab",
"label": "Ambient.io",
"disabled": false,
"info": "",
"env": []
},
{
"id": "934195a49ffabf80",
"type": "inject",
"z": "d08ce3b97bd479ba",
"name": "",
"props": [
{
"p": "payload"
}
],
"repeat": "30",
"crontab": "",
"once": true,
"onceDelay": 0.1,
"topic": "",
"payload": "{\"thermometer\":{\"temperature\":20},\"hygrometer\":{\"humidity\":30}}",
"payloadType": "json",
"x": 250,
"y": 260,
"wires": [
[
"999732051de18b98"
]
]
},
{
"id": "3d973510489ea316",
"type": "http request",
"z": "d08ce3b97bd479ba",
"name": "",
"method": "POST",
"ret": "obj",
"paytoqs": "ignore",
"url": "http://ambidata.io/api/v2/channels/*/data",
"tls": "",
"persist": false,
"proxy": "",
"insecureHTTPParser": false,
"authType": "",
"senderr": false,
"headers": [
{
"keyType": "other",
"keyValue": "Content-Type",
"valueType": "other",
"valueValue": "application/json"
}
],
"x": 770,
"y": 260,
"wires": [
[
"733252737ac78dd8"
]
]
},
{
"id": "999732051de18b98",
"type": "template",
"z": "d08ce3b97bd479ba",
"name": "",
"field": "payload",
"fieldType": "msg",
"format": "handlebars",
"syntax": "mustache",
"template": "{\"writeKey\":\"*****\",\"d1\":{{payload.thermometer.temperature}},\"d2\":{{payload.hygrometer.humidity}}}",
"output": "json",
"x": 500,
"y": 260,
"wires": [
[
"3d973510489ea316",
"c187c1861f7112da"
]
]
},
{
"id": "733252737ac78dd8",
"type": "debug",
"z": "d08ce3b97bd479ba",
"name": "debug 4",
"active": true,
"tosidebar": true,
"console": false,
"tostatus": false,
"complete": "false",
"statusVal": "",
"statusType": "auto",
"x": 940,
"y": 260,
"wires": []
},
{
"id": "c187c1861f7112da",
"type": "debug",
"z": "d08ce3b97bd479ba",
"name": "debug 5",
"active": true,
"tosidebar": true,
"console": false,
"tostatus": false,
"complete": "false",
"statusVal": "",
"statusType": "auto",
"x": 800,
"y": 200,
"wires": []
}
] |
Thank you for the sample flow.
Please check. |
With the updated flow, I'm able to reproduce the error you report. What I see is that the HTTP server responds as follows:
It looks like the 0 content-length response is not being handled correctly. The Very nice find. Thank you! |
The behavior seems to be that fetch throws an exception when the JSON.parse fails on an empty buffer. The Node-RED HTTP Response node catches the exception and outputs a message with the payload set to an empty string. Strangely, the Node-RED HTTP Response node does not trigger any Catch nodes so there's no way for a flow to detect the error. I made some changes to match the fetch and Node-RED behaviors. I will review them tomorrow and then commit. |
I suppose technically a 200 response has a body which here happens to be of length zero, i.e. |
@tve – Thanks for the thoughts. This particular null is internal to the fetch implementation, so it can do whatever it likes as long as the observable result matches the standard. In my tests, it appears that status 200 with Content-Length of 0 generates:
For status 204, fetch seems to specify a null as you suggest, though the details are a tangle:
And:
Taking those two together, I think that means that response.json/text/arrayBuffer() for a 204 should throw. But, I would really want to test that reading before committing to an implementation. |
The original issue reported should now be resolved. Note that it requires updating the Moddable SDK and Node-RED MCU. There is likely work to be done for conformance with "null body status." That should be done as a part of a more rigorous conformance testing effort around the |
Your HTTP request node is configured to parse the response as JSON: The response is not valid JSON, so there is an exception throw by the JavaScript You have some options to avoid the break in the debugger:
|
Thank you for your advice. In the properties of the "http request" node, "Tip: If the JSON parse fails the fetched string is returned as-is." Even with Node-RED on the PC, I confirmed that [warn] is displayed although the execution does not stop. |
Thank you for the reminder about the "tip". Actually, I had not implemented that. I just committed a fix for it (it doesn't matter for your flow). I'm going to close this issue out as resolved. If there are follow-on issues, please open a separate issue. |
Build environment: Windows + Node-RED MCU Plugin
Target device: ESP32(m5stick_cplus)
Description
http request may stop at "c:\pjt\moddable\examples\io\tcp\fetch\fetch.js (162) # Break: fromArrayBuffer: argument is no ArrayBuffer instance!"
Node-RED Flow
Images
Other information
The probability of success and failure is about 50%
I'm sorry if I'm using it wrong.
The text was updated successfully, but these errors were encountered: