I believe it would be better to use the *503 status code. *It indicates that the server is busy, overloaded, or down for maintenance
The HTTP Retry-After response header indicates how long the user agent should wait before making a follow-up request. There are three main cases this header is used: In a 503 Service Unavailable response, this indicates how long the service is expected to be unavailable. *Jordi Rosell * El dt., 13 de gen. 2026, 14:32, Hadley Wickham <[email protected]> va escriure: > > > > > > > > > On 12 Jan 2026, at 14:37, Roy Mendelssohn - NOAA Federal via > > R-package-devel <[email protected]> wrote: > > > > > > For what it is worth in my case as far as I can tell the behaviors of > > both devtools::submit_cran and the cran machine were quote reasonable, > > even if it caused me a little pain. The block Uwe describes sounds like > > fail2ban or the like, and given the junk we see hitting our services it > > is a reasonable thing to run. I had the day wrong when I thought cran > was > > back up. devtools on submission said ti couldn’t connect, It is not > > unreasonable as a submitter, thinking the machine was back up, to wait a > > bit, and try again, and maybe do so a few times throughout the day. > > That is indeed what I did. Then to be sure it wasn’t a devtools problem > I > > went to the web page and that is when it seemed to block me. > > > > > > So my point is everything to my mind behaved reasonably. The only > thing > > I could suggest, and I have no idea of how much work this would entail, > > and I am not looking to make work for people, is perhaps a banner on the > > webpage when the service is down, > > > > > > That’s the thing - there *was* a red banner that said no submissions are > > accepted so everyone using the official CRAN way was fine, it’s the > > back-door access by devtools that caused the problems. The issue is that > > once devtools got you blocked, it was too late so you couldn’t go back > and > > see that you were not supposed to use it since your IP was already on the > > blacklist even for the official front-end. Clearly, devtools needs to be > > fixed to make sure it’s not submitting things blindly when it’s not > > supposed - probably with some help from the CRAN admin team to make sure > > there is a well-defiled path for this. > > > Would it be possible for the form to be blocked as well as the submission > page? Typically web servers return a 404 or a 403 when a page isn't > available. > > I can of course scrape the submission page, but now that the message is > gone, I don't know what to look for. > > Hadley > > -- > http://hadley.nz > > [[alternative HTML version deleted]] > > ______________________________________________ > [email protected] mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel > [[alternative HTML version deleted]] ______________________________________________ [email protected] mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
