I checked the source code on submission page when it was still down; there was an HTML <form> tag, but all <input> tags had been removed.
Submission via devtools went through and the CRAN incoming server responded with the usual email asking the maintainer to confirm by going to the "three-checkboxes" webpage. I didn't proceed from there. Henrik On Tue, Jan 13, 2026, 09:02 [email protected] <[email protected]> wrote: > 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 > [[alternative HTML version deleted]] ______________________________________________ [email protected] mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
