HTTPS and circular redirects

I’m using a shared host that is already forcing HTTP requests to HTTPS. But the Grav-generated URI is still HTTP. If I set force_ssl in system.yaml, then it causes a redirect circle. Is there a way I can tell Grav to use HTTPS as the scheme canonically without it trying to force redirects on its own?

I set it through .htaccess as the only canonical redirect, as there is no faster way of redirecting and ensuring HTTPS. force_ssl should really only be used as an alternative to .htaccess, but you could set it through other overriding layers such as CloudFlare or server alternatives to .htaccess.

That’s the problem. My host already ensures that HTTP redirects to HTTPS. It works great. But Grav still generates HTTP urls programmatically (e.g., $this->grav['uri']).

Is your host enforcing this through regular .htaccess files? The generated URLs are not a problem if the server redirects properly, as all links become HTTPS immediately when accessed, and resources are retrieved over HTTPS as well.

It’s a problem because in the plugin I’m working on, I need to generate absolute links for pages on my site, but by default Grav\Common\Uri is producing http schemes. Sure I can do string manipulation, and sure the system is redirecting fine, but I don’t want to force clients to redirect unnecessarily, and I don’t want to have to do string manipulation in the half-dozen places I need these URLs. I just want to be able to tell Grav that I’m an HTTPS site once and have it correctly generate absolute URLs. I wanted to confirm this wasn’t already possible before I started looking at pull requests.

So the source code seems to draw from $_SERVER['HTTPS']. I guess I’ll see where that takes me. I’m sounding more and more like that annoying guy in the cubicle next door that keeps thinking out loud. I need to rate limit myself on the forum :slight_smile:

My REST client is requesting the site via HTTPS, so I’m not sure why $_SERVER isn’t seeing that.

Oh, I know why. It’s because my host is using ipsec and forwarding. It handles the SSL negotiation on the front end and then passes control to me using the HTTP_X_FORWARDED_PROTO header. Pull request incoming, I guess :slight_smile: