Potential issues with PUT /v1/immutable/:storage_index/:share_number

[itamarst]

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?

[exarkun]

​https://github.com/tahoe-lafs/tahoe-lafs/pull/1116

[GitHub <noreply@…>]

In 1819e080/trunk:

Merge pull request #1116 from LeastAuthority?/3769.gbs-immutable-upload-spec-improvements

Some GBS immutable upload spec improvements

Fixes: ticket:3769