[tahoe-lafs-trac-stream] [Tahoe-LAFS] #3769: Potential issues with PUT /v1/immutable/:storage_index/:share_number

[Tahoe-LAFS]

#3769: Potential issues with PUT /v1/immutable/:storage_index/:share_number
----------------------+---------------------------------------
 Reporter:  itamarst  |          Owner:  exarkun
     Type:  task      |         Status:  new
 Priority:  normal    |      Milestone:  HTTP Storage Protocol
Component:  unknown   |        Version:  n/a
 Keywords:            |  Launchpad Bug:
----------------------+---------------------------------------
 Should document response codes, so that it's clear what to do in case of
 failed response. E.g. how does client tell difference between different
 kinds of errors ("that chunk already exists", "you skipped ahead" if
 that's disallowed...).

 Would be nice to have a response code that means "this chunk successfully
 uploaded, but the share is still incomplete" and one that means "this
 chunk successfully uploaded, the share is now fully uploaded", which would
 make parallel uploads easier.

 "Servers may reject out-of-order chunks for implementation simplicity."
 This prevents parallel uploads? Not ideal for latency.

 Also, if a PUT succeeds but the success response never makes it back to
 the client, the client may have issues if it resends the chunk? Unless
 that case is handled.

 "If an individual *PUT* fails then only a limited amount of effort is
 wasted on the necessary retry." What does this mean?

--
Ticket URL: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/3769>
Tahoe-LAFS <https://Tahoe-LAFS.org>
secure decentralized storage