Flic Home

    Community

    • Login
    • Search
    • Popular
    • Users

    HTTP.makeRequest cannot POST binary buffers

    Flic Hub SDK
    binary buffer hub sdk http post
    2
    6
    865
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • martinm
      martinm last edited by

      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 ?

      1 Reply Last reply Reply Quote 0
      • Emil
        Emil FlicTeam @martinm last edited by

        @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.

        1 Reply Last reply Reply Quote 0
        • martinm
          martinm @martinm last edited by

          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.

          Emil 1 Reply Last reply Reply Quote 0
          • martinm
            martinm @Emil last edited by

            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 1 Reply Last reply Reply Quote 0
            • martinm
              martinm @Emil last edited by

              This post is deleted!
              1 Reply Last reply Reply Quote 0
              • Emil
                Emil FlicTeam last edited by

                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.

                martinm 2 Replies Last reply Reply Quote 0
                • First post
                  Last post