Updated: https://github.com/ietf-wg-acme/acme/pull/208
On Tue, Nov 29, 2016 at 3:37 PM, Richard Barnes <[email protected]> wrote: > > > 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
