ExternalVendorCode/tahoe-lafs
1
0
Fork 0
mirror of https://github.com/tahoe-lafs/tahoe-lafs.git synced 2024-12-22 14:22:25 +00:00
Code Issues Actions 1 Packages Projects Releases Wiki Activity

Document impact of semantic changes on HTTP protocol.

Browse Source
This commit is contained in:
Itamar Turner-Trauring 2021-09-24 13:48:07 -04:00
parent 0b1082fc04
commit 96acb14199
1 changed files with 16 additions and 12 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

28
docs/proposed/http-storage-node-protocol.rst
View File

@ -497,22 +497,26 @@ If any one of these requests fails then at most 128KiB of upload work needs to b
The server must recognize when all of the data has been received and mark the share as complete The server must recognize when all of the data has been received and mark the share as complete
(which it can do because it was informed of the size when the storage index was initialized). (which it can do because it was informed of the size when the storage index was initialized).
Clients should upload chunks in re-assembly order.
* When a chunk that does not complete the share is successfully uploaded the response is ``OK``. * When a chunk that does not complete the share is successfully uploaded the response is ``OK``.
* When the chunk that completes the share is successfully uploaded the response is ``CREATED``. * When the chunk that completes the share is successfully uploaded the response is ``CREATED``.
* If the *Content-Range* for a request covers part of the share that has already been uploaded the response is ``CONFLICT``. * If the *Content-Range* for a request covers part of the share that has already,
The response body indicates the range of share data that has yet to be uploaded. and the data does not match already written data,
That is:: the response is ``CONFLICT``.
At this point the only thing to do is abort the upload and start from scratch (see below).
{ "required": ``PUT /v1/immutable/:storage_index/:share_number/abort``
[ { "begin": <byte position, inclusive> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
, "end": <byte position, exclusive>
} This cancels an *in-progress* upload.
,
... The response code:
]
} * When the upload is still in progress and therefore the abort has succeeded,
the response is ``OK``.
Future uploads can start from scratch with no pre-existing upload state stored on the server.
* If the uploaded has already finished, the response is 405 (Method Not Allowed)
and no change is made.
``POST /v1/immutable/:storage_index/:share_number/corrupt`` ``POST /v1/immutable/:storage_index/:share_number/corrupt``