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
