mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

servePut and clientPut implementation

Browse source 
Made the data-length header required even for v0. This simplifies the
implementation, and doesn't preclude extra verification being done for
v0.

The connectionWaitVar is an ugly hack. In servePut, nothing waits
on the waitvar, and I could not find a good way to make anything wait on
it.
This commit is contained in:
Joey Hess 2024-07-22 10:20:18 -04:00
parent eb4fb388bd
commit 4826a3745d
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
10 changed files with 222 additions and 185 deletions
Download patch file Download diff file Expand all files Collapse all files

14
doc/design/p2p_protocol.mdwn
View file

@ -182,7 +182,7 @@ whitespace.)
The server may respond with ALREADY-HAVE if it already
had the content of that key.
In protocol version 2, the server can optionally reply with
In protocol version 2 and above, the server can optionally reply with
ALREADY-HAVE-PLUS. The subsequent list of UUIDs are additional
UUIDs where the content is stored, in addition to the UUID where
the client was going to send it.
@ -197,9 +197,9 @@ the client to start. This allows resuming transfers.
The client then sends a DATA message with content of the file from
the offset to the end of file.
In protocol version 1, after the data, the client sends an additional
message, to indicate if the content of the file has changed while it
was being sent.
In protocol version 1 and above, after the data, the client sends an
additional message, to indicate if the content of the file has changed
while it was being sent.
INVALID
VALID
@ -207,8 +207,8 @@ was being sent.
If the server successfully receives the data and stores the content,
it replies with SUCCESS. Otherwise, FAILURE.
In protocol version 2, the server can optionally reply with SUCCESS-PLUS
and a list of UUIDs where the content was stored.
In protocol version 2 and above, the server can optionally reply with
SUCCESS-PLUS and a list of UUIDs where the content was stored.
## Getting content from the server
@ -223,7 +223,7 @@ See description of AssociatedFile above.
The server then sends a DATA message with the content of the file
from the offset to end of file.
In protocol version 1, after the data, the server sends an additional
In protocol version 1 and above, after the data, the server sends an additional
message, to indicate if the content of the file has changed while it
was being sent.

5
doc/design/p2p_protocol_over_http/draft1.mdwn
View file

@ -39,8 +39,6 @@ over HTTPS.
Each request in the protocol is versioned. The versions correspond
to P2P protocol versions.
The protocol version comes before the request. Eg: `/git-annex/v3/put`
If the server does not support a particular protocol version, the
request will fail with a 400 Bad Request, and the client should fall
back to an earlier protocol version.
@ -369,8 +367,7 @@ Same as v3, except the JSON will not include "plusuuids".
### POST /git-annex/$uuid/v0/put
Same as v1, except there is no X-git-annex-data-length header.
Additional checking client-side will be required to validate the data.
Same as v1, except additional checking is done to validate the data.
### POST /git-annex/$uuid/v3/putoffset

5
doc/todo/git-annex_proxies.mdwn
View file

@ -28,10 +28,7 @@ Planned schedule of work:
## work notes
* Implement: servePut, servePutOffset, serveLockContent
* I have a file `servant.hs` in the httpproto branch that works through some
of the bytestring streaming issues.
* Implement: servePutOffset, serveLockContent
* A Locker should expire the lock on its own after 10 minutes initially.