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

Switch to HTTP header scheme.

Browse Source
This commit is contained in:
Itamar Turner-Trauring 2021-10-28 10:49:08 -04:00
parent e0c8bab5d7
commit 125c937d46
1 changed files with 23 additions and 15 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

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

@ -450,16 +450,22 @@ A lease is also created for the shares.
Details of the buckets to create are encoded in the request body.
For example::
{"renew-secret": "efgh", "cancel-secret": "ijkl",
"upload-secret": "xyzf",
"share-numbers": [1, 7, ...], "allocated-size": 12345}
{"share-numbers": [1, 7, ...], "allocated-size": 12345}
The request must include ``WWW-Authenticate`` HTTP headers that set the various secrets—upload, lease renewal, lease cancellation—that will be later used to authorize various operations.
Typically this is a header sent by the server, but in Tahoe-LAFS keys are set by the client, so may as well reuse it.
For example::
WWW-Authenticate: x-tahoe-renew-secret <base64-renew-secret>
WWW-Authenticate: x-tahoe-cancel-secret <base64-cancel-secret>
WWW-Authenticate: x-tahoe-upload-secret <base64-upload-secret>
The response body includes encoded information about the created buckets.
For example::
{"already-have": [1, ...], "allocated": [7, ...]}
The uplaod secret is an opaque _byte_ string.
The upload secret is an opaque _byte_ string.
It will be generated by hashing a combination of:b
1. A tag.
@ -521,9 +527,9 @@ 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
(which it can do because it was informed of the size when the storage index was initialized).
The request body looks this, with data and upload secret being bytes::
The request must include a ``Authorization`` header that includes the upload secret::
{ "upload-secret": "xyzf", "data": "thedata" }
Authorization: x-tahoe-upload-secret <base64ed-upload-secret>
Responses:
@ -727,9 +733,11 @@ Immutable Data
1. Create a bucket for storage index ``AAAAAAAAAAAAAAAA`` to hold two immutable shares, discovering that share ``1`` was already uploaded::
POST /v1/immutable/AAAAAAAAAAAAAAAA
{"renew-secret": "efgh", "cancel-secret": "ijkl",
"upload-secret": "xyzf",
"share-numbers": [1, 7], "allocated-size": 48}
WWW-Authenticate: x-tahoe-renew-secret efgh
WWW-Authenticate: x-tahoe-cancel-secret jjkl
WWW-Authenticate: x-tahoe-upload-secret xyzf
{"share-numbers": [1, 7], "allocated-size": 48}
200 OK
{"already-have": [1], "allocated": [7]}
@ -738,22 +746,22 @@ Immutable Data
PATCH /v1/immutable/AAAAAAAAAAAAAAAA/7
Content-Range: bytes 0-15/48
{"upload-secret": b"xyzf", "data": "first 16 bytes!!"
Authorization: x-tahoe-upload-secret xyzf
<first 16 bytes of share data>
200 OK
PATCH /v1/immutable/AAAAAAAAAAAAAAAA/7
Content-Range: bytes 16-31/48
{"upload-secret": "xyzf", "data": "second 16 bytes!"
Authorization: x-tahoe-upload-secret xyzf
<second 16 bytes of share data>
200 OK
PATCH /v1/immutable/AAAAAAAAAAAAAAAA/7
Content-Range: bytes 32-47/48
{"upload-secret": "xyzf", "data": "final 16 bytes!!"
Authorization: x-tahoe-upload-secret xyzf
<final 16 bytes of share data>
201 CREATED