Propagation delays for http challenges?

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.

I think so. I can’t think of any way to deploy an HTTP challenge that isn’t completely synchronous.

Maybe if it requires a CDN purge?

2 Likes

Maybe some kinds of networked replication? Unison? sshfs?

2 Likes

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.

2 Likes

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.

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.