#1 sounds OK to me
On Wed, Sep 5, 2018 at 11:33 AM, Richard Barnes <[email protected]> wrote:
> I'm tempted to say that the "" / null ambiguity is an interop problem for
> JOSE, not for us. But nonetheless, it's a problem.
>
> I'm still uncomfortable with {}, though, because it risks colliding with
> other POST uses. What would you guys think about one of these explicit
> markers:
>
> 1. A field in the protected header ("urn:ietf:params:acme:get": true) with
> a requirement that the payload be "{}"
> 2. A field in the payload ({"get": true}) a requirement that if that field
> be there, then there are no other fields present
>
> Personally, I find (1) a little more explicit. It's a little more bloat
> because of the URN cruft, but (1) it doesn't make sense to register a
> generic, unprefixed parameter, and (2) checking for "{}" is easier than
> checking for "no other fields".
>
> --Richard
>
> On Tue, Sep 4, 2018 at 3:17 PM Logan Widick <[email protected]>
> wrote:
>
>> I like using {} for the POST-as-GET payload as well.
>>
>> Sincerely,
>>
>> Logan Widick
>>
>> On Tue, Sep 4, 2018, 12:26 Jacob Hoffman-Andrews <[email protected]> wrote:
>>
>>> New day, new thread for a specific issue I'd like to nail down quickly.
>>>
>>> > ISSUE 2: How should we signal that POST-as-GET request is different
>>> > from other POST requests?
>>> >
>>> > The current PR signals this by sending a JWS with an empty
>>> > (zero-octet) payload, instead of a JSON object. Jacob and Daniel
>>> > suggested that we should instead use the payload being an empty JSON
>>> > object as the signal. An earlier draft PR used a field in the
>>> > protected header.
>>>
>>> In short, this question is about whether POST-as-GETs should have:
>>>
>>> "payload": ""
>>>
>>> or
>>>
>>> "payload": "{}"
>>>
>>>
>>> When implementing the first one (empty payload), Daniel and I each
>>> separately implemented a different bug that would have also accepted:
>>>
>>> "payload": null
>>>
>>> This may be quirk of Go's handling of byte arrays, but it may turn out
>>> to be a common pattern in JSON libraries. The downside, if a server
>>> implementer landed a bug like that, would be that clients might get away
>>> with generating the invalid "null" form, leading to interoperability
>>> problems.
>>>
>>> There's also potential for client bugs that produce an empty payload
>>> simply due to an uninitialized field, rather than due to a POST-as-GET.
>>> This would produce confusing errors relating to GETs rather than a
>>> clearer "malformed input" error.
>>>
>>> Lastly, many clients already implement the "{}" form as a way to GET an
>>> account, so expanding the use of "{}" minimizes disruption.
>>>
>>> My preference is still for "{}" over "", but I am also willing to be
>>> convinced in the interests of landing this change speedily and keeping
>>> forward momentum.
>>>
>>> _______________________________________________
>>> Acme mailing list
>>> [email protected]
>>> https://www.ietf.org/mailman/listinfo/acme
>>>
>> _______________________________________________
>> Acme mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/acme
>>
>
> _______________________________________________
> Acme mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/acme
>
>
_______________________________________________
Acme mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/acme
