Interesting!
Retry-Aftercan be a date- You can use it to say that the service will be down for a while (e.g. for maintenance) and when to try again
It follows that…
You have to be careful with
Source: Retry-After HTTP header in practice (nurkiewicz.com)Retry-Afterheader if you send the same timestamp to a lot of unique clients. Imagine it’s 15:30 and you sendRetry-After: Thu, 10 Feb 2015 15:40:00 GMTto everyone around – just because you somehow estimated that service will be up at 15:40. The longer you keep sending the same timestamp, the bigger DDoS “attack” you can expect from clients respectingRetry-After. Basically everyone will schedule retry precisely at 15:40 (obviously clocks are not perfectly aligned and network latency varies, but still), flooding your system with requests. If your system is properly designed, you might survive it. However chances are you will mitigate this “attack” by sending another fixedRetry-Afterheader, essentially re-scheduling attack later.
That being said avoid fixed, absolute timestamps sent to multiple unique clients. Even if you know precisely when your system will become available, spreadRetry-Aftervalues along some time period. Actually you should gradually let in more and more clients, so experiment with different probability distributions.