Sure. Plenty of ways to do that. If your primary concern is issuance, then you don't even need server push, you can just long-poll. In HTTP/1.1, that's gross because it ties up a connection and has some disgusting keep-alive properties. In h2 there is no opportunity cost to worry about, the connection remains usable for other things while you wait. (You can use prefer:wait to control timing if you want a standards-based solution: https://tools.ietf.org/html/rfc7240#section-4.3)
On Tue, Mar 6, 2018 at 9:27 AM, Richard Barnes <r...@ipv.sx> wrote: > Thomson: Could h2 push replace some of the polling here? > > On Mon, Mar 5, 2018 at 4:50 PM, Felipe Gasper <fel...@felipegasper.com> > wrote: >> >> >> > On Mar 5, 2018, at 1:13 PM, Matthew D. Hardeman <mharde...@ipifony.com> >> > wrote: >> > >> > Especially with CT logging being a pragmatic requirement, >> > time-to-delivery for certificates is likely to increase (slightly) rather >> > than decrease. >> >> Quick point: the alleviation of polling would go for authz status as well >> as to certificate delivery. >> >> A certificate order that has 10 domains needs to poll for the status of >> all 10 of those domains’ authorizations as well as the certificate issuance. >> “ACME/bidi” would remove all 11 of those needs to poll. >> >> Thanks for those who have given this suggestion their consideration. I >> don’t mean to “gum up the gears” for the main ACME work, but as I’ve been >> writing ACME clients the polling stuff has stuck out to me like a sore >> thumb. >> >> It’s worth noting, too, that concerns about overhead may be alleviated if >> we do get a usable WebSocket-over-HTTP/2 implementation. Or, maybe someone >> will expose an SCTP endpoint, or a raw TCP endpoint that implements a simple >> message-boundary layer. I think the question of pure-message, bidirectional >> transport is more relevant than a specific transport implementation. >> >> -F > > _______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
