It's clear that the althttpd infrastructure doesn't support running both HTTP and HTTPS in a single instance, but my suspicion is that this would be trivial to simulate by...

• Starting up using one mode or the other.
• forking and exec()'ing a second instance with CLI flags configured for the other mode.

The only(?) addition would be the need for 2 flags for specifying the port numbers separately, maybe --port and --sport, and if both are specified (0 to use the default) then launch in dual mode, else follow the current behavior.

Is that something worth doing?

Something like:

$ althttpd -root /blah -user foo -port 0 -sport 0 --cert /my/cert

would, assuming it's started as root, listen on ports 80 and 443.

Alternately, a syntax of --ports 0:0 or --ports 0,0 might be more intuitive, or possibly recycle --port for that purpose, entering dual mode if it has a colon or comma.

I don't really have a good answer to provide to support this feature, but I support it, even if I can't support my support for it.

A recent article here

resulted in the author continuing the http version of his website with an https version with a self signed cert.

Would this not also make redirecting from 80->443 easier?

I don't really have a good answer to provide to support this feature

Here's one: "Apache can do it." ;)

A recent article here

Interestingly, ESR's website has long been HTTP-only and visiting the site in HTTPS results in an invalid cert error (that particular domain is not, as of this writing, listed in the cert the server is offering).

AFAIK, the only compelling argument for dogmatically insisting on HTTPS for even plain static sites is that it's otherwise possible for ISPs and proxies to manipulate the content and/or headers with no indication that they've done so.

Would this not also make redirecting from 80->443 easier?

i don't think so (but may be mistaken). A redirect always requires telling the client to go somewhere else and expecting them to actually do it. We don't have a way to redirect a user from HTTP to HTTPS without sending them an HTTP response saying "go visit this HTTPS URL instead." We can only show them the way, though. It's up to them to take it (or not).

We don't have a way to redirect a user from HTTP to HTTPS without sending them an HTTP response

Yes, sorry, that isn't what I meant though that is how my poorly worded comment reads. I don't really even know what I was getting at now that I think about it, other than it just seems more elegant to have a single instance of althttpd fielding both HTTP and HTTPS, whether that's to serve both or to return blanket redirects from one to the other.

But I haven't actually needed to do either of those things before. All of my previous web server experience is HTTP only. With that in mind, here are maybe some more stupid questions:

I assume the two most common scenarios would be:

• Serve both HTTP and HTTPS versions of the same site(s)
• Transition a previously HTTP only site to HTTPS by returning redirects for all HTTP requests

How does the new HTTPS --cert implementation affect using the virtual host directories? Doesn't each domain need a different cert? // edit, I guess not, looks like multiple domains in a single cert is supported with a Subject Alternative Names (SAN) cert.

If single invocation support for HTTP and HTTPS were implemented, could it support something like a --redirect argument to automatically listen on port 80 and respond with redirects? The homepage mentions using an "-auth" file in the context of HTTP->HTTPS redirects so maybe that is the answer, but as I said above, I haven't previously had a need to configure or test it so I'm not sure.