Thank you SOOO much for all the help! I learned quite a lot!
If you don’t mind; can you perhaps explain how you determined that calibre-web was expecting the header?
Is this a header that would have been present had I hosted this service natively on a VPS, secured with TLS?
One of the links I referenced above (Setup Reverse Proxy · janeczku/calibre-web Wiki · GitHub) had some information about it. Specifically, an nginx config (with the syntax RequestHeader set X-SCHEME https and a short explanation: “The X-Scheme directive is used to preserve the protocol (http/https), it could be hard coded to http or https to force this type of protocol.”)
Whether or not the service is on a VPS doesn’t really matter; the cloud is just someone else’s computer. On a VPS you’d need to configure a web server, most likely, and if the web server on the VPS was Caddy, well… Nothing would be different, in practice.
Alternately if you’re asking if you’d exposed calibre-web directly to the internet, e.g. by giving it a purchased HTTPS certificate - no, you probably wouldn’t have had this problem. It’s part of a class of logical problems that can occur when you introduce a proxy layer. There’s a few oddities that can occur when the client expects one thing and the app expects another, but there’s a web server in between invalidating those expectations. Mostly nowadays though it’s just plug and play, and the benefits of having a server like Caddy handle your HTTPS is just too good to pass up.
Thank you so much for all the help!
You are an excellent teacher.
My day job is being a SaaS product technical support engineer; I troubleshoot everything from endpoint agent installations to back-end service issues all day long. This experience has taught me about as much as anything else!
Just a Quick Summary for the record:
Setup:
Caddy as a Reverse proxy for multiple docker services
Caddy running as a container service on the same server-host
Issues:
Home networking issue; google wifi in dmz+ mode with a PACE U-verse modem
ATT set firewall rule opening 443 to the WAP for testing. Unsure whether this could be closed/reconfigured
Hosted web application relying on X-Scheme header to persist/force scheme. Automatically downgrading to http, breaking flow.
Fixes:
Configuring Caddy to reverse proxy on a nonstandard port
forwarded nonstandard port to server; then opened that port to the docker container.
specified this port In Caddyfile
Added header_up X-scheme https to force the application to maintain https (prevent from downgrading).
Relevant configuration/compose files:
Loosely following this guide: