HTTP.makeRequest cannot POST binary buffers

[martinm]

I need to send a (small) form-encoded binary buffer (aka file upload) to a networked device from the hub (Firmware: 3.0.12). I tried different ways but couldn't manage to get it working.

I checked with Wireshark, it looks like the HUB is blindly converting the 'options.content' value to UTF 8 before posting it, regardless of the content-type.

• sending a string made of the buffer bytes
  => UTF8 corruption
• sending data as a Uint8Array
  => the hub posts the string "[object Uint8Array ]"
• setting various HTTP headers such as
  Content-Type: multipart/form-data; boundary=...
  Content-Type: application/octet-stream
  Content-Transfer-Encoding: binary
  => the hub doesn't care.

It there a way to go around this limitation / bug ?

[Emil]

@martinm When an incoming FIN packet is received from the remote endpoint, the socket is automatically properly closed unless the allowHalfOpen option is set. If that option is set, the socket is properly closed at the time when both an incoming FIN has been received and the local user has called the end method on the socket (in any order). Nothing is done at garbage collection time, so if you use the allowHalfOpen property, remember to close the socket by calling the end method. If the allowHalfOpen is not set, you can still use the end method to send your own FIN packet.

[martinm]

I dug a bit more with Wireshark. It looks like the socket is actually properly closed by the hub if socket.end() is not explicitly called.

I suspect it is closed automatically when the Socket object is garbage collected.

[martinm]

martinm less than a minute ago
@Emil ok, thanks I managed to make it work with the raw TCP API.

Note that although mentioned in the "drain" callback details net.Socket.write() is not documented.

Also, it looks like there is no way to properly close the socket ie once the data has been sent and acknowledged by the receiver. net.Socket.end() is not documented either and I suspect that "drain" doesn't wait for the ACK. May I count on the hub to properly clean up his stuff (no socket leak) once the socket has been closed by the other end ?

BTW, coding network I/O with old school javascript (no async / await) is a pain.

[martinm]

This post is deleted!

[Emil]

Right now the http api is quite simplistic.

As written in the api documentation, both the request body and response body have the data type "String". For now if you don't find a workaround you have to use the raw TCP API.

It's likely this will be supported in a later version.