On Tue, Nov 29, 2016 at 2:26 PM, Jacob Hoffman-Andrews <[email protected]> wrote:
> On 11/28/2016 06:37 PM, Richard Barnes wrote: > > I actually thought you were the one that suggested we keep the > > "status" fields > > Nope, I have always been in favor of not inlining the status fields. We > talked about this directly, but also it was in my previous PR and thread > about merging requirements and authorizations: > > >> 3. "Inline" the authorization objects into the order/application > object, just as challenges are inlined into authorizations (while > still keeping them addressable, as challenges are) > > > I don't see the need for this, and actually think it's a negative. GETs > are cheap for the client, especially with HTTP/2. Inlining like this > means there are two ways for a client to check the status of an > authorization: by polling the authz, or by polling the application / > order. We've seen in Boulder that having two ways to do things leads to > bugs, so I'd rather say you must poll the authorization. > > > Also, for orders with lots of authz's in them, polling the order object > will be more expensive for the server than polling individual authzs, > because each poll of the order object has to reconstruct a larger number > of objects from the DB. When clients poll individual authzs, they only > check each authz until it is done, then stop. > I can live with that. I'll update the PR. --Richard
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
