On 02/19/2017 06:54 PM, Hugo Landau wrote:
> If a server processes different things in parallel, multiple errors
> could occur. Should the "error" field be an array?
Reading the Problem Document spec, it seems like the expected way to
handle multiple errors is with fields within the problem document,
rather than multiple problem documents.
The way Boulder has handled this has been to pick the error that matters
most. For instance, if there was a validation failure and a CAA failure,
report the validation failure, because when both fail it's usually
because of a DNS problem. However, it would also be entirely possible to
represent multiple errors in plain text.
> Moreover, is there any utility in mandating that this "error" field only
> be used after (all?) authorizations have been completed? That meshes
> with the implementation model this list is expecting, but it seems
> simpler from a client implmentation perspective simply for the client to
> balk whenever it retrieves an order object which has an error set on it.
> This maximizes the flexibility of implementation on the server side.
Yep, good point. Now it's just:
error (optional, object):
: The error that occurred while processing the order, if any.
This field is structured as a problem document {{!RFC7807}}.
_______________________________________________
Acme mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/acme
