Hi Bob, First of all, sorry for the late reply. Some personal stuff has kept me away from the computer for quite some time.
Bob Proulx <[email protected]> writes: >> $ curl -4 -v https://git.savannah.gnu.org/git/elpa/gnu.git > > It's also good to know exactly what command is running. Is this a > simplification analogue to running git clone? Otherwise I can't > imagine any reason for using curl like this. Yes, it was just a simplification. I wanted to test what was going on with the HTTPS interface of git.savannah.gnu.org and used curl for that. > We are forced to continue to tighten access. I think it likely that > we will need to fingerprint git clients and only allow git clients > moving forward. Good to know. I guess that rules out tests like the one I did with curl. > In order to improve service availability we have recently created a > mirror pool of servers on a distributed collective of independent > volunteer donated systems. > > Try it! We have multiple systems in the pool. Instead of the one > single primary upstream system we have multiple mirrors. This > scales-out and is somewhat better at handling the onslaught of the > endless AI scraping botnets. > > git clone --depth=1 https://https.git.savannah.gnu.org/git/elpa/gnu.git > > We have not implemented it yet but I think it likely we will implement > an HTTP Redirect for https://git.savannah.gnu.org/git/ to > automatically redirect to https://https.git.savannah.gnu.org/git/ at > some point in order to move load off the primary and onto the mirrors. > I have done that for the gitweb & cgit human browsing interfaces. I > wanted to burn-in the new process on the web browser before doing it > for the machine protocols. But I think it is time to do it for that > protocol service too. I remembed reading about the pool in this thread from savannah-hackers-public. https://lists.nongnu.org/archive/html/savannah-hackers-public/2025-04/msg00003.html However, with regard to "https://cgit.git.savannah.gnu.org/cgit/"; and "https://gitweb.git.savannah.gnu.org/gitweb/";, you said that these URLs are very likely to change and should not be used in documentation. > Additionally and very likely to change URL names there are cgit and > git set up now, implementing https. > > https://cgit.git.savannah.gnu.org//cgit/ > https://gitweb.git.savannah.gnu.org//gitweb/ > > Those names and paths might need to change but for the moment maybe > having them even temporarily will give some relief? I would avoid > using them in documentation which will persist because again they are > likely not stable naming yet. You have been warned. Now that all redirects seem to be implemented: $ curl -isS https://git.savannah.gnu.org/git/ | grep Location Location: https://https.git.savannah.gnu.org/git/ $ curl -isS https://git.savannah.gnu.org/cgit/ | grep Location Location: https://cgit.git.savannah.gnu.org/cgit/ $ curl -isS https://git.savannah.gnu.org/gitweb/ | grep Location Location: https://gitweb.git.savannah.gnu.org/gitweb/ What are the recommended URLs to use in documentation? "https://{https,cgit,gitweb}.git.savannah.gnu.org"; or "https://git.savannah.gnu.org";? > In summary I think the primary system was simply overloaded. Please > use the mirror pool system. > > Please report back and say how this works for you. While I was using curl to check the previous redirects, git.savannah.gnu.org stopped answering my requests. However, it worked again when tethering from my phone. Out of curiosity, do you temporarily blacklist hosts showing a suspicious behaviour? For instance, using curl instead of a browser or git to access these URLs? Maybe this is what happened last time? Thanks! Roi
