Max Pritikin (pritikin) <[email protected]> wrote: > That is an interesting idea. Obtaining a “renewed” voucher would be as > simple as a query to the known URL (unless the nonce needed to be > updated in which case use the POST method). Hmm.
> Feels a little bit like a premature optimization; but I see the point.
I'd like to suggest that we permit a 200 *or* 201 response, but document
that 201 SHOULD be treated like a 200 for this version of the BRSKI-MASA
protocol. Maybe it's implied somewhere that all 2xx responses are success,
yet 204 (No content) is not a useful response.
This lets' us update to 201 in a future version if we find it useful.
I need to re-read to determine what failure responses are expected.
Are we allowed to return 503 if one should try later?
What about 420 or 429:
Returned by the Twitter Search and Trends API when the client is being
rate limited. The text is a quote from 'Demolition Man' and the '420'
code is likely a reference to this number's association with
marijuana. Other services may wish to implement the 429 Too Many
Requests response code instead.
>> On Jun 5, 2017, at 8:02 PM, Michael Richardson <[email protected]>
wrote:
>>
>>
>> Max Pritikin (pritikin) <[email protected]> wrote:
>>> From https://tools.ietf.org/html/rfc2616#section-9.5
>>
>>> The action performed by the POST method might not result in a
>>> resource that can be identified by a URI. In this case, either 200
>>> (OK) or 204 (No Content) is the appropriate response status,
>>> depending on whether or not the response includes an entity that
>>> describes the result.
>>
>>> In this case I think the 200 OK code is most appropriate since the
>>> server generates a signed voucher as a result of the POST and returns
>>> it. The voucher is not identified by a URI.
>>
>> Agreed... let me ask the question again:
>> SHOULD the voucher be identified by a URI?
>>
>> --
>> Michael Richardson <[email protected]>, Sandelman Software Works
>> -= IPv6 IoT consulting =-
>>
>>
>>
--
Michael Richardson <[email protected]>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
