I run dehydrated (bash ACME client) on quite a few machines. Since the announcement of the new 429 responses for when servers are under high load, I've seen a couple of cases where dehydrated has got a 429 response and spent a bit of time modifying it to handle them nicely, instead of just waiting until dehydrated runs again next day. However, I want to see that it works before submitting it upstream, and of course it hasn't happened again yet! Is there a way to ask the staging environment to give a 429 (or 503) error with retry-after header so I can test this?
Yeah, I would think the best idea would be using something like Pebble rather than the actual staging environment. I think Pebble randomly gives wrong nonces in order to help applications ensure that their nonce retry logic is correct; I don't know if along those same lines you can set it up to randomly give you 429 or 503 errors.
I was just using it as an example where Pebble tries to not give clients the right answer sometimes to force them to retry, it seems that a similar feature that gives clients 429 or 503 errors with a Retry-After header sometimes to force clients to handle them would be along those same lines, and should probably be implemented if it isn't already.
In the meantime, assuming there's no existing out-of-the-box functionality from Pebble for it, it probably wouldn't be crazy difficult to set up a web server (Apache or Nginx or whatever) as a reverse proxy in front of an ACME server (Pebble or even "real" staging) that sometimes is returning the errors. I mean, that's closer to how Let's Encrypt is actually implementing this new feature anyway, if I'm understanding correctly. Would be nice if someone put together a tutorial on how to do it. Or maybe one of those other common API testing tools (Postman, Fiddler, or whatever the cool kids are using these days) has something similar to this built in already?
I've not looked at pebble in years and years
But I just sent a ton of rate limited 503s in staging to confirm new alerts. I could do that again, but it doesn't scale.
A dirty way of testing this is to run pebble behind nginx, and then install an nginx directive to respond 503s if a filepath exists on the system. Then you just delete/touch the filepath as needed.
Does Pebble have this feature?