pondering
This commit is contained in:
parent
ed679f2a51
commit
a0f1fbb613
1 changed files with 14 additions and 0 deletions
|
@ -725,3 +725,17 @@ so just dumping the file into the body won't work.
|
||||||
Seems unneccessary to support since javascript should be able to access
|
Seems unneccessary to support since javascript should be able to access
|
||||||
the file that the user has selected to upload, and PUT its content to the
|
the file that the user has selected to upload, and PUT its content to the
|
||||||
presigned url.
|
presigned url.
|
||||||
|
|
||||||
|
In the P2P protocol, PUT can proceed and at the end the client can indicate
|
||||||
|
the content changed while it was being sent by sending INVALID. This is
|
||||||
|
necessary to support unlocked files. Extending the P2P protocol to support
|
||||||
|
indirect upload to an url needs to somehow also handle this case. One way
|
||||||
|
that would work is to never upload unlocked files to a presigned url.
|
||||||
|
Instead send the content of those via the P2P protocol the usual way. Only
|
||||||
|
send locked files to the url. But a file can also get unlocked and then
|
||||||
|
modified while it's being sent, so can git-annex, as a client, ever send
|
||||||
|
any files to a presigned url? Maybe this feature would only ever be useful
|
||||||
|
in cases like OpenNeuro's, where something other than git-annex is
|
||||||
|
communicating with the git-annex proxy. Alternatively, allow the wrong
|
||||||
|
content to be sent to the url, but then indicate that with INVALID. A later
|
||||||
|
reupload would overwrite the bad content.
|
||||||
|
|
Loading…
Add table
Add a link
Reference in a new issue