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
