[tahoe-lafs-trac-stream] [Tahoe-LAFS] #3763: Potential issues with `PUT /v1/lease/:storage_index` in GBS protocol

[Tahoe-LAFS]

#3763: Potential issues with `PUT /v1/lease/:storage_index` in GBS protocol
--------------------------+-----------------------------------
     Reporter:  itamarst  |      Owner:  exarkun
         Type:  task      |     Status:  new
     Priority:  normal    |  Milestone:  HTTP Storage Protocol
    Component:  unknown   |    Version:  n/a
   Resolution:            |   Keywords:
Launchpad Bug:            |
--------------------------+-----------------------------------
Description changed by exarkun:

Old description:

> 1. It says "If there are no shares for the given ``storage_index`` then
> do nothing and return ``NO CONTENT``." 204 is a success code... this
> seems like maybe more like an error, and should therefore have 4xx code?
> 2. What should be returned if there are shares? Anything need to be in
> the response body? Just 200?
> 3. "If the ``renew-secret`` value matches an existing lease then that
> lease will be renewed instead." Why is this, given there exists a
> separate renew API endpoint? This seems like it could mask certain
> categories of client bugs.

New description:

 1. It says "If there are no shares for the given `storage_index` then do
 nothing and return `NO CONTENT`." 204 is a success code... this seems like
 maybe more like an error, and should therefore have 4xx code?
 2. What should be returned if there are shares? Anything need to be in the
 response body? Just 200?
 3. "If the `renew-secret` value matches an existing lease then that lease
 will be renewed instead." Why is this, given there exists a separate renew
 API endpoint? This seems like it could mask certain categories of client
 bugs.

--

--
Ticket URL: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/3763#comment:3>
Tahoe-LAFS <https://Tahoe-LAFS.org>
secure decentralized storage