I have a domain configured in Cloudflare, with ‘always use HTTPS’ switched on. The origin is s3. I’ve configured s3 to redirect certain paths so that the virtual paths work correctly in the web app that it is hosting. The S3 bucket is HTTP only. This config works, and I’m observing this:
cloudflare returns a 301 response to http://example.com/?my/redirection/path
cloudflare returns a 301 response to https with the rest the same
I’m wondering why there are two 301 responses instead of just one. As the 301 is generated by Cloudflare and the original request is HTTPS, and ‘always use HTTPS’ is on, why does the redirection switch to HTTP in the first 301 response?
On the origin side, the incoming request is HTTP and the redirection response is HTTP. I’m wondering if Cloudflare is picking up the protocol there and using that in the 301 response that it’s generating, whilst rewriting the domain.
So functionally this works as it is, but it’s just a little strange that there’s an extra 301 and exposure of the request over HTTP.
If that added ? is really there, then something is adding it in a 301 redirect. If it’s not a Cloudflare Page Rule, then it’s something on your server. And then Cloudflare redirects the final HTTP to HTTPS.
Yep, the added ‘?’ is there, it’s because of the s3 redirection rules I created. S3 generates the 301, and I’m speculating that cloudflare rewrites the hostname in the 301 redirect it received from s3, but leaves the rest of the Location as it is, resulting in the protocol switching to HTTP in the 301 that the client sees.
The hostname was the same throughout your example, so there was no change there.
Yes, the example is of the redirections created by Cloudflare and not the bucket. I didn’t include the 301 redirects generated by the bucket to try and simplify the example, but maybe that didn’t help. I’ll expand:
- Client requests https://example.com/my/redirection/path
- cloudflare requests http://mys3bucket.amazonaws.com/my/redirection/path
- cloudflare receives a 301 redirect to http://mys3bucket.amazonaws.com/?my/redirection/path <— this is from the s3 redirection rules. As s3 is HTTP only, the Location is intentionally HTTP so the URL isn’t broken
- cloudflare returns a 301 redirect to http://example.com/?my/redirection/path <-- protocol has switched to HTTP from client’s POV even though Cloudflare setting is ‘always use HTTPS’ and the request protocol (step 2) was HTTPS
- client requests http://example.com/?my/redirection/path
- cloudflare returns a 301 response to https://example.com/?my/redirection/path <— protocol has switched back to HTTPS
- client requests https://example.com/?my/redirection/path
You can see this in action here
Here’s a network log in Firefox:
The network log shows step 1 (HTTPS), step 5 (HTTP) and step 7 (HTTPS) on the final URL
I’m not sure how you expect Cloudflare to fix this. Your origin is taking HTTPS, then specifically redirecting it to HTTP.
Why are you hosting your site from an S3 bucket? If robdev is hosted on a server, but only the journeytimemaps are in the S3 bucket, you can use a Worker to pull content from a bucket.
The origin is taking HTTP, then the 301 it emits it also HTTP - there’s no redirection from HTTPS to HTTP. However, in the client-facing responses, Cloudflare is creating a redirection from HTTPS to HTTP. Cloudflare knows that the initial request is HTTPS, and that the ‘always use HTTPS’ is switched on, so I’m of the view that the 301 it creates with HTTP pointing to the client-facing domain is as an error. A fix would be the logic ‘if current request is HTTPS and if always use HTTPS is true’ then ‘keep the domain as HTTPS in the response’s Location’. Or more simply, if ‘always use HTTPS’ is on, then always emit HTTPS in the Location in a 301.
Re. using a worker rather than s3, that’s a possibility, but I’d consider that a workaround.
Yet one more reason Flexible SSL mode is not a good solution.
This topic was automatically closed after 30 days. New replies are no longer allowed.