#3769 closed task (fixed)

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

Reported by: itamarst Owned by: exarkun
Priority: normal Milestone: HTTP Storage Protocol
Component: unknown Version: n/a
Keywords: Cc:
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?

Change History (2)

comment:2 Changed at 2021-09-02T20:21:23Z by GitHub <noreply@…>

  • Resolution set to fixed
  • Status changed from new to closed

In 1819e080/trunk:

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

Some GBS immutable upload spec improvements

Fixes: ticket:3769

Note: See TracTickets for help on using tickets.