Despite Caddy working OK with the Let’s Encrypt certificate, the access logs show that certain contents are still delivered over HTTP.
I’ve set up a bibliographic database (WIKINDX) which is PHP based on a Debian linux 9 server. My Caddyfile is basically:
fastcgi / /run/php/php7.0-fpm.sock php
Caddy is up and running on port 443, basically the site works (apart from CSS). But certain requests, f.ex. on robots.txt and certain PHP database accesses, are still shown as HTTP/1.1.
Has anyone seen this problem and worked out a solution?
When Automatic HTTPS is enabled, insecure requests should be receiving 301 permanent redirects to HTTPS unless Caddy has specifically been configured not to do this.
Bear in mind that HTTP/1.1 does not imply insecure HTTP. The client may negotiate HTTP/1.1 with your server over HTTPS, and Caddy will support this. For a live example:
whitestrake at cadmus in ~
❯ curl -I https://whitestrake.net/ --http1.1
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Last-Modified: Mon, 27 Aug 2018 04:07:11 GMT
Date: Tue, 06 Aug 2019 07:54:19 GMT
Thanks for your answer. Do I understand correctly that the mixed content is not necessarily a bad thing? Mozilla was complaining about it, but after I inserted the security header lines from examples/security-header at master · caddyserver/examples · GitHub, the complaints have stopped.
It’s not necessarily mixed content - as long as we’re defining “mixed content” as HTTP and HTTPS.
What I’m saying is that you can have HTTP/1.1 and HTTP/2 both occur over HTTPS on port 443.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.