Fetch from origin if non-SSL request

We do have a load balancer in front of Nginx, but everything worked with no issues before Cloudflare. Literally the only difference between our PHP script handling the redirect or it being circumvented before getting to our PHP script was changing our domain DNS entries to Cloudflare.

1 Like

Then I’d check the load balancer. The redirect in this case does not come from Cloudflare.

$ curl -I --resolve www.daniweb.com:80:BLAHBLAH http://www.daniweb.com/forums/thread123.html
HTTP/1.1 302 Found
Cache-Control: no-cache
Content-length: 0
Location: https://www.daniweb.com/forums/thread123.html
1 Like

The 307 is an internal redirect due to the HSTS header.

In which case, you may have users with your site on the HSTS list in their browser (from a previous visit), but clicking on old http URLs, but visiting you over HTTPS. It would be much easier to do a blanket HTTPS redirect in cloudflare, and redirecting (perhaps a second time) to the new canonical URL.

Also, your HSTS max age is too low to be preloaded, but you are issuing a preload command.

1 Like

Unrelated, but because I noticed it.

You are still running PHP 7.2.19. That version has been unsupported for almost a year and 7.2 will be entirely out of support at the end of this year. I’d recommend to upgrade to 7.4 soonish.

1 Like

Hi,

This is all a little bit over my head so I reached out to my sysadmin.

Basically he confirmed that our load balancer (which sits in front of the web server, and lives at .107) is doing 302 redirects. I don’t understand why this is, because I swear that pre-Cloudflare, my PHP script was handling SSL redirection. He doesn’t understand how my PHP script ever handled SSL redirection, because he swears he hasn’t recently changed any load balancer settings. The result of our debate is that he’s going to investigate why the load balancer is doing it and how to get it to stop moving forward.

However, that still doesn’t resolve the HSTS issue. When I go to http://www.daniweb.com, I am getting a 307 Internal Redirect due to HSTS. Is it not possible to have the security advantages of HSTS but also not do two redirects in a row?

I don’t know what you mean about my HSTS max-age being too low?

My Cloudflare settings say:

HTTP Strict Transport Security (HSTS)

Enforce web security policy for your website.

Status: On
Max-Age: 6 months (Recommended)
Include subdomains: On
Preload: On

Can you explain to me why six months isn’t ideal? Are you referring to my HTTP prefetch headers? Your explanation is a little over my head. I’m a web developer, but I don’t have much experience with anything that lives outside my little PHP/MySQL bubble.

You don’t really need to worry too much about HSTS, unless you planned to move back to HTTP. The preload issue is only because you specified half a year, whereas https://hstspreload.org requires a year.

The HSTS seems to be a Chrome peculiarity as that redirect does not show up in Firefox at all, but Firefox goes straight for HTTPS.

What I’d recommend is to have Cloudflare perform the HTTPS redirect and only have the redirect from the previous to the new URL structure on your side.

1 Like

The preload issue is only because you specified half a year, whereas https://hstspreload.org requires a year.

I have no experience with HSTS other than clicking a little checkbox in Cloudflare. Cloudflare says 6 months is recommended, so I went with their default setting. I see what you mean about hstspreload.org. Since my setting is set to 6 months, and I just enabled it 2 weeks ago, then it seems highly unlikely that my domain is included in Chrome’s HSTS preload list. That being said, if 1 year is recommended for the full benefit of HSTS, then perhaps Cloudflare should make 1 year their recommended setting instead of 6 months?

My sysadmin has corrected the issue with the load balancer so that it is no longer part of the equation. If you go to http://x.x.x.107/forums/thread123.html you are now properly redirected to https://www.daniweb.com/hardware-and-software/networking/threads/123/netware-is-solid in a single 301 redirect.

However, if I go to http://www.daniweb.com/forums/thread123.html, I’m still getting the 307 Internal Redirect thing which causes the double redirect.

1 Like

Enabling HSTS should be done with care as that glues you to HTTPS. As long as you stay with HTTPS it isn’t much of an issue. Should you ever want to move away, that is when it gets tricky.

That link doesn’t give me a 307 but a 301 which seems to come from your server. If you really get a 307 then this will be most likely a “local” redirect by your browser. You aren’t use Firefox, are you?

1 Like

Enabling HSTS should be done with care as that glues you to HTTPS. As long as you stay with HTTPS it isn’t much of an issue. Should you ever want to move away, that is when it gets tricky.

We have been using HTTPS-only for the past 7+ years, so I can’t think of a reason why we would ever want to go back. The concern here is that my website is 20 years old, and has accumulated quite a handful of links from other sites over the years.

In analyzing Googlebot’s crawl the other day, I’ve noticed that it’s doing an additional 5K redirects a day due to the double redirect issue going on here. Instead of Googlebot being redirected 5K times a day, they’re having to process 10K redirects a day. From an SEO perspective, this is bad for my crawl budget. Additionally, it takes Googlebot a lot longer to process URLs when multiple redirects are involved.

Now that the issue with the load balancer is corrected, I’m hoping that Googlebot won’t encounter the HSTS issue that I’m encountering which is still causing the double redirects … or will they, since Googlebot’s crawler is just a headless version of Chrome?

1 Like

The redirect you are referring to is not a redirect in the first place as that is something the browser runs internally. Firefox for example doesn’t show it.

Try it with a different browser or reset your Chrome and the first request shouldn’t show a 307.

1 Like

I see that Firefox is not showing a double redirect.
Safari is doing a 302 Found and then a 301.
Chrome is doing a 307 Internal Redirect and then a 301.

What’s up with Safari?!

Thank you for all your help.

Screen Shot 2020-06-11 at 1.53.10 PM

1 Like

Maybe Safari is doing a 302 internally as well.

Point is, for HTTP there is only one redirect :slight_smile:

$ curl -I http://www.daniweb.com/forums/thread123.html
HTTP/1.1 301 Moved Permanently
Date: Thu, 11 Jun 2020 20:52:56 GMT
Content-Type: text/html; charset=UTF-8
Connection: keep-alive
Location: https://www.daniweb.com/hardware-and-software/networking/threads/123/netware-is-solid
Vary: Accept-Encoding
CF-Cache-Status: EXPIRED
X-Content-Type-Options: nosniff
X-Powered-By: PHP/7.2.19
Server: cloudflare
alt-svc: h3-27=":443"; ma=86400
1 Like

Very strange that each browser does something completely different.

That being said, is your recommendation for HSTS to increase it to a year? There is no reason I could ever think of to go back to non-HTTPS. Are there additional benefits in increasing it to a year and then being included in hstspreload?

1 Like

The internal redirect is just your browsers way of telling you what is happening, and it’s not really a redirect.

1 Like

It probably does not really matter. You will need one year if you want to be “preloaded” but apart from that it really does not matter. Purely from a security point of view and if you do not plan to go back you might want to set the maximum period.

1 Like

I entered daniweb.com into the form at hstspreload.org (never heard of this site before you pointed it out to me) and I am getting the following error (aside from max-age too low):

http://daniweb.com (HTTP) should immediately redirect to https://daniweb.com (HTTPS) before adding the www subdomain. Right now, the first redirect is to https://www.daniweb.com/. The extra redirect is required to ensure that any browser which supports HSTS will record the HSTS entry for the top level domain, not just the subdomain.

Basically it’s telling me to implement a double redirect. I just went through all of this to get rid of a double redirect.

What do I do?! Can you point me to a resource that shows me the benefits of being accepted to the HSTS preload list? If I don’t meet the requirements, should I just turn off HSTS entirely in Cloudflare?

1 Like
1 Like

From a SEO perspective, you might want to follow Google’s own advice, start with a low max-age, monitor for issues, then increase gradually. Add site to preload list last (emphasis added by me):

  1. Roll out your HTTPS pages without HSTS first.
  2. Start sending HSTS headers with a short max-age. Monitor your traffic both from users and other clients, and also dependents’ performance, such as ads.
  3. Slowly increase the HSTS max-age.
  4. If HSTS doesn’t affect your users and search engines negatively, you can, if you wish, ask your site to be added to the HSTS preload list used by most major browsers.

from: https://support.google.com/webmasters/answer/6073543?hl=en

1 Like

Thanks! I have a plan in place now and everything is working as intended.

2 Likes

One final question.

On hstspreload.org, the last bullet point under Deployment Recommendations says:

Once you’re confident that there will be no more issues, increase the max-age to 2 years and submit your site to the preload list: […]

However, when I go to HSTS Settings within Cloudflare, the Max Age Header setting dropdown has a recommended default of 6 months, and only allows a maximum of 12 months.

I get that I can manually implement these headers instead of having Cloudflare do it for me, but if they’re going to offer HSTS functionality, shouldn’t Cloudflare have support for the hstspreload.org recommendations?

1 Like