Most clients that support automating DNS challenges have a configurable sleep value to allow for DNS propagation to occur before the client asks the ACME server to validate the challenges it has published. Is there typically a similar sleep value configurable for HTTP challenges or do most clients assume HTTP published challenges are available immediately?
I’m finally getting around to adding a plugin system for HTTP challenges in my client, and I’m wondering if it makes sense to have a configurable sleep value similar to the DNS plugins. And if so, what should the default be?
It may be a very different value for each DNS service provider.
Perhaps a tool that could test a particular provider and gauge their specific average would be helpful to that end-user.
Maybe, within that tool, the end-user could opt-in to submit that data for “summarization”. From which a “chart” could be made to use “default settings” for any known DNS service providers.
Perhaps it should be a hook script option, so that if there’s a way to verify programmatically that the deployment has completed, the hook can just wait until that happens? If people want to hard-code a delay rather than a test, they could make the hook be sleep 5 or something.
Thanks for the replies everyone. It sounds like a delay is generally not necessary. And in the specific cases where it might be necessary, it would be plugin specific and can just be implemented by the plugin.