Maybe everyone is over-thinking this. Is it safe to assume cvsweb is: 1. always used interactively (in a web browser)? 2. used exclusively by OpenBSD users/developers?
Therefore you could use a captcha that is trivial for an OpenBSD user or developer to solve, but difficult for bots to comprehend. For example: present a random dictionary word or string, and ask the user to pipe it to /usr/games/morse and paste the output to get access. If the bots are not specifically after cvsweb content so much as they are after grabbing every discernible URL possible - just put it behind HTTP basic authentication, rotate the password every 24 hours and post the password somewhere on the main OpenBSD web site like the CVS page. Fighting the bots is an endless battle I'm afraid. Before you go waste time and effort engineering an ephemeral solution, it may be easier to simply shut the door altogether and give all those welcome to enter the key. This worked 30 years ago and it's probably just as effective today. Regards Lloyd Constantine A. Murenin wrote: > On Sun, 25 Jan 2026 at 08:26, Nick Holland wrote: > > > On 1/24/26 11:12, Constantine A. Murenin wrote: > > > > It's also horrible for usability. > > > > I wish I could argue with that, but I can't...other than to say, It > > beats being shut down. > > > > I HAVE changed the redirection to localhost. I am looking at ideas for > > a "better" solution, which I'm sure will be hated by many, because it > > isn't as straight forward as it was. I don't even know what the better > > solution is, I just know it won't be liked, and I won't like doing it. > > > The redirects are what's harmful to the usability and the UX, and it's the > actual, real, OpenBSD users and developers, and not the machines, who are > inconvenienced greatly by these redirects, that obscure the resource they're > trying to obtain. > > The least you can do is simply give out a regular error, like HTTP 406 Not > Acceptable as someone else suggested. This way, the user will have the file > name, version, and action, in the address bar, and they can use an > alternative service. With a redirect to "localhost/", with the requested path > destroyed, they have nothing, and the BACK button doesn't work, since pages > with HTTP redirects, aren't added to the history. (If you have to do a > redirect somehow, at least include the full path.) > > Ideally, you can also provide a back link from a custom error page, clicking > on which, a bona fide user would be brought back to the correct page. > > BTW, the reason these bots have such an outsized effect on these legacy > services, is because of the inefficiency of the service. With a 48GB RAM > machine, you could probably simply pre-cache all of these default > permutations that these bots are requesting, and serve all of them from the > cache, without having to deny the service to anyone. (Can probably do that > from a less beefy box, too.) > > C.
