HTTP file uploads specs

[muhamadazmy]

To get quickly with file uploads we will create a specific procedure for this as follows

• rmb need to start with file upload enabled, it's an opt in feature so RMBs can choose not to receive file uploads
• all RMBs can process upload command (to upload a file, not to receive it)
• A special command msgbus.system.file.upload is handled in local rmb (the uploader) the body of this command must contain the following payload body (the payload part of the message)
  • path to the local file
  • cmd the remote service queue to accept the file
• Note an upload command must have a single destination. can't fan out.
• RMB will then start doing an http multipart upload to the remote /rmb-upload/
  • The request must contain an extra headers:
  • rmb-upload-cmd (this is the cmd part of the request above) this will be notified once upload is complete
  • rmb-source-id (the source twin id)
  • rmb-timestamp (the timestamp of the request)
  • rmb-signature (the signature of the combined headers + id from the url)
• In case /rmb-upload is disabled, this will return a Method Not Allowed 405 error.
• If upload is allowed:
  • rmb validate headers and signatures. then proceed to writing the file to a temp location (configure on start)
• Once upload is complete remote rmb will issue a command to local service on the cmd queue specified by rmb-upload-cmd
• On local rmb, once uploading is complete, a local message is created on the return queue on the original msgbus.system.file.upload message with the "status" of the upload (this can be success or error)
• There is no grantee that after the upload is successful that the remote service will actually process the uploaded file.

[muhamadazmy]

Some implementation hints:

• In the http workers, when it processing a Forward message (message to forward to remote rmb) if the message command is '.system.file.upload' a different action need to be taken
• The payload of the message then is decoed as the described above {path: <path>, cmd: <remote cmd to call remotely>}
• File is checked to make sure it exists.
• The request need to then built with the headers as described above and the signature is added
• Reqeust body is attached to the open file. (note u don't load the entire file in body, u instead stream the request content from the file. this is already supported with hyper.
• any errors received is pushed back to the caller as an error message.
• On the remote rmb, we add a new http api endpoint /rmb-upload
• accepts the upload and stream the request body to a local file in the temp location configured by the command line.
  • validation of the request need to be done before any errors need to be returned.
• once file is written in temp location a "message" is constructed and send to the 'command' to the local service.

[despiegk]

sounds good to me

[abom]

I started to implement this flow, for the multipart uploads, I tried multiple crates (including multipart, multier...) that didn't work because it's outdated or doesn't play nice with hyper or provide only client side implementation, at the end I used mpart-async and it's working from the server side (api), will continue using it from the client side too (http workers).

[abom]

The implementation should be ready, in a successful upload

• A message is sent locally with "success" in msg.dat
• A run message is sent to rmb-upload-cmd with the file path in msg.dat

To run rmb with uploads enabled (to accept uploads), pass -u to enable uploads and --upload-dir <where to store uploads>, otherwise it will return 405 for any upload requests.

A small note, when constructing the payload for the upload message, don't add the prefix of e.g. msgbus to the command that will process the file, it's automatically handled in the remote side (as configured).