-
-
Notifications
You must be signed in to change notification settings - Fork 24
polling for challenge ready and certs with timeout and retry-after #104
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
I agree we should make this stuff easier but I don't think this exact change is the way to go about it. First off, I'm not a fan of the duplication in this PR, so I think we should deduplicate most of the code (which should be fairly straightforward). Second, maybe we should have a bit of a discussion about what the optimal way to represent the timeout parameters in the API is. I agree that including the total timeout might make sense. I was thinking it might be useful to have a type, this could represent the current API: struct Backoff {
initial_delay: Duration,
tries: usize,
} And also provide some constants, like: const DEFAULT_READY: Backoff = Backoff { initial_delay: Duration::from_millis(250), tries: 5 }; As for how we define backoffs, I think there are multiple entry points:
Maybe we could look at how some popular crates do it, but I don't think the cost/benefit of depending on an extra crate for this in instant-acme makes sense. Also, the API should be such that downstreams can still implement their own, so the method we implement is just an ease-of-use feature and doesn't lock the caller into it -- that's how/why we can be a little opinionated. |
I would also suggest we should consider implementing support for |
Definitely! Do ACME servers commonly support that? |
Pebble and Bouder (Let's Encrypt) do for sure. I'm honestly not sure what the rest of the server-side ecosystem looks like. |
That's enough for me. 👍 |
I'll do some research if other ACME servers support the retry-after header and come back with this info. At least in https://datatracker.ietf.org/doc/html/rfc8555#section-8.2 it is described as a must reading the challenge
|
That seems about enough research to me -- I wouldn't worry about checking other servers. |
Here is a summary of some testing and research: ACME server side testing
Retry-after header
ACME4J Client
My conclusion is that the Acme4j algorithm is fine, but should be extended by the httpdate format (and returning an existing ACME error code). An initial sleep of the exponential polling algorithm could be added outside the polling call. Using the retry-after is an improvement in terms of rate-limiting compared to the current polling. |
Ah interesting. I thought there was support for this but it looks like Pebble sets it for ARI, but not in other contexts. |
just a side comment: The Retry-After value |
I updated both methods in the pull request to respect retry-after and http-date dependency. For shure not the final solution, but it gives an impression what it looks like with retry-after support. This wait_ready is similar to acme4j. |
I want to continue the API discussion. There are three methods on the public
I see two options to continue with the API:
How to proceed from here? I prefer option 1 as the next iteration in this PR. |
We already broke compatibility on main, so I'm happy to look at your implementation of option 1. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks pretty reasonable to me. I agree with Djc that the breaking change you propose makes sense.
There was a Pebble failure in CI (a rejected nonce) but I think it's unrelated and went away after a kick (I think there's a place we don't handle bad nonce retries correctly?).
The breaking api change is implemented as option 1 and a pebble test is added. |
I found one issue (fixed in #105) |
This pull requests adds two polling methods to the Order API for challenge ready and the final certificate with timeouts.
The polling characteristic is different from Order::poll() and provides a total timeout and maximum polling interval in addition to the initial exponential polling delay. This aims at usability, the total timeout is easier to understand and the maximum polling interval yields a result more responsive when calling the API (especially for long timeouts).