POSTdata
From flud
Note: the most up-to-date documentation of the protocol is the source code itself, at http://flud.org/tryit.html
Contents |
[edit] (Store) POST /file/[filekey]
Store file data. This operation uses the standard HTTP form file upload facility, described in RFC1867.
[edit] authentication
This operation requires authentication. Prior to authentication, filedata should not be sent (as described below).
[edit] required parameters:
- size: integer value (not encoded). size of filedata, in bytes.
- Ku_e: integer value (not encoded). value of 'e' from public key.
- Ku_n: integer value (not encoded). value of 'n' from public key.
- port: integer value (not encoded). listen port.
- form param 'filename'.
If 'filename' is a tarball, this was an aggregate store operation and the receiver should store all of the files that are present in the tarball (receiver can choose how it does this, including just storing the tarball as is).
If 'filename' is not a tarball, it is a single store operation, and the form may also have a 'metakey' file upload, containing a piece of the filesystem metadata (or any other arbitrary data that the requestor chooses) which should be associated with the file data given.
This operation does require authentication prior to the peer accepting filedata, so prior to authentication, the full request should be sent minus the filedata (filename forms are still sent, but with data length 0).
[edit] possible responses
normal response:
- code: 200 OK
- data: 'Successful STORE'
response for malformed request:
- code: 400 BAD REQUEST
- data: error message
response for challenge-response failure:
- code: 401 UNAUTHORIZED
- data: error message