Heh! I regularly get attackers from AS9145 who will try and fail to change directory to /etc on my FTP server 8 times per second.
Sounds a bit complex. (-:
Debian apt-ftparchive source actually makes checksum lists for source packages.
No handy equivalent in pkg repo, though.
It's not going to be high on the priority list. I could possibly modify the .do scripts to do something non-standard.
In the meantime, the HTTP Last-Modified: response header is right and the If-Modified-Since: request header is respected by Bernstein publicfile. For what that's worth.
I have only just discovered the X-Clacks-Overhead HTTP header.
To put it into #djbwares httpd properly, so that it is administrator-configurable *and* properly escapes the necessary metacharacters, is a fair amount of work.
So I'll probably make a to-do item out of it. But there's much more vital work to be done with things like making more things work with IPv6.
The aforementioned machine 20cm from my left elbow has a content DNS server, too. Not wholly satisfactory as it's not a guaranteed stable address.
It's doing double duty though, with split horizon, as the root content DNS server for the LAN, serving copies of the ICANN data and the data for Estonia and the island of Niue.
You'll know that you've truly arrived in the self-hosting world when you have your own replica of Niue. (-:
My WWW server is currently about 20cm from my left elbow, and serves static content too.
I don't worry about potential attacks, because I've seen the logs. Attackers do the obvious things and go after the complex softwares.
10 minutes ago, for example, an attacker tried sending an HTTP GET request to my GOPHER server, for example.
Earlier, one made 8 attempts within a single second to change to an /etc directory in my FTP server. My FTP server has no /etc directory to serve.
Yesterday, one was trying CGI to inject a wget command to my HTTP server using shell syntax and another was trying to send parameters to an index.php script. There's no CGI, nor wget, nor PHP anywhere in the HTTP server or even the entire machine.
It has been like this for years. Don't use complex tools for simple static servers, and one's worries are things entirely other than the WWW servers.
I made the mistake of starting to learn about GEMINI from its Frequently Asked Questions document.
It's not aimed at people like me, who already understand the benefits and tradeoffs of static content servers. So it drives lots of points home, repeatedly, that I already know.
It's apparently aimed at the same sort of monoculture Chrome+Apache Think for HTTP that parallels the old BIND Think and Sendmail Think that #qmail and #djbdns were up against years ago.
Yes, I have been musing about setting up a GEMINI server, especially as GOPHER doesn't really do virtual hosting and is thus a bit poor when it comes to the #publicfile content model.
I've pre-prepared a gemini6d service bundle, but an actual geminid server to go alongside httpd is still a to-do item.
I first learned of GEMINI's existence only a few days ago.
Static content? No uploading or any other form of modification?
If you need to upload, look elsewhere, such as indeed at the FreeBSD ftpd(8).
But if the requirement is just to *send out* stuff via FTP without the receiver having to log-in, with a server that runs sandboxed and not as the superuser, publicfile still fits the bill after all of these years.
https://jdebp.uk/Softwares/djbwares/
Right. That's done.
The existence of an OLDPROTO environment variable opts in to the old #publicfile behaviour. This will be in the next #djbwares release. The hardest part was writing the explanation in the #httpd manual page.
JdeBP
JdeBP