Is It Safe to Keep HTTP Enabled While Using HSTS for a Custom curl Response?

For a personal static site with no credentials, cookies, private data, or meaningful user actions, the practical risk is fairly small. However, anyone whose first request is made over HTTP, or whose client does not support or remember HSTS, can still receive the page unencrypted. On an untrusted network, that traffic could be observed or modified. Production sites should generally redirect HTTP to HTTPS instead of serving content over both protocols.

You can keep the short command without leaving HTTP enabled by setting curl’s default protocol to HTTPS. Another option is to return the custom message based on the User-Agent or use a separate hostname or virtual host. HSTS is defense in depth, not a replacement for an HTTP-to-HTTPS redirect, and it is only effective after a client has learned the policy unless the domain is included in an HSTS preload list.

HSTS does not redirect HTTP requests on the server. It tells browsers that have already received the policy over HTTPS to upgrade future requests before connecting. It also does not help clients such as curl unless curl is explicitly given an HTTPS URL or configured to default to HTTPS. The safer server setup is to redirect every HTTP request to HTTPS and configure curl locally instead. For example, a `~/.curlrc` entry such as `proto-default = "https"` lets you keep using `curl mydomain.tld` without exposing an HTTP endpoint.