Redirect https to http despite permanent redirects from http to https

[Marcus]

I have redirected all traffic to https://domain.com but want to convert back to http. But the permanent redirects are in place for years, they are stored in all my users browsers. This is my former configuration:

server
{
  server_name domain.com;
  listen 443 ssl spdy deferred;
  root /usr/share/nginx/html;
  [... the content is delivered here ...]
}
server
{
  server_name domain.com;
  listen 80;
  return 301 https://domain.com$request_uri;
}
server
{
  server_name www.domain.com;
  return 301 https://domain.com$request_uri;
}

This configuration is stored in my users browsers. So when i set a new configuration to redirect https to http, there is an infinitive loop redirect. Is creating a new subdomain (http://sub.domain.com) the only solution or can I go with http://domain.com which I very much prefer?

 

[rdn]

Try this:

server {
listen 443 ssl;
server_name www.domain.com domain.com;
return 301 http://domain.com$request_uri;
}
server {
listen 80;
server_name domain.com;
}

 

[Marcus]

Thanks, the redirect is correct.

The problem is my users browser cache. The permanent redirects are cached there "permanent", as it should be. Their browser cache is:
http => https

Even when my nginx server changes the redirects, it will not have any effect on the old stored pemanent redirects stored in my users browsers.

When I now create a https=>http redirect, the users browser with redirect back and forth between http and https.

 

[Chris D]

I'm not aware that browsers cache permanent redirects.

I think you may have something else wrong.

 

[rdn]

Yes I know browser obey/cache if you declare permanent on your redirects.

 

[Marcus]

The newer browsers (as for example IE 9) cache them permanent, if you set permanent redirects. This is stored in the browser and it seems there is no way a server can tell the browser to modify its cache. My former redirects are these:
http://domain.com => https://domain.com
http://www.domain.com => https://domain.com

It works for me when I flush my browsers cache, but I can not tell my users to do that. There is the unfortunate loop anyway.

If the users gets the "correct" http page, the browser will redirect it back to https as it was told from my server to do so "permanent".

As I have redirected all domain.com to https://domain.com the only way out it seems is to redirect it to subdomain.domain.com

http=> redirected to https permanently I can not change that [for old users with browser cache]

I could do this redirect:
https://domain.com => http://subdomain.domain.com
http://domain.com => http://subdomain.domain.com

... and only because I did not set a wildcard http=>https permanent redirect before. It's really tricky when the server logic is saved within the users browser and you can not change it afterwards.

 

[Luke F]

There's bound to be a workaround for this - what about a hidden iframe with src and location.reload(true) spammed a few times in quick succession?

 

[Marcus]

For the record, you can flush windows cache with "ipconfig /flushdns". After that remove the dns cache from the browser.

My configuration works fine on a virgin dns system. Unfortunately when I use a browser that visited my community before, it does not work, there is the endless http<->https loop. I hope the subdomain will work out.

 

[rdn]

Did you figure out this already?
I think a new domain/sub domain is the only solution for this.

As I also want to redirect back to http from https.

 

[Chris D]

Why are people doing this? Doesn't it just make sense to stay with HTTPS?

 

[rdn]

I just use and force to https before just for SPDY.
But base on experience, SPDY is only advantage on a website having a lot of static files or video to stream.

 

[Floren]

Why are people doing this? Doesn't it just make sense to stay with HTTPS?

+1000.

 

[eva2000]

Why are people doing this? Doesn't it just make sense to stay with HTTPS?

I can think of one valid reason. If user wants to take advantage of CDN to offload their static images but do not want to incur the much higher costs and setup fees that most CDN providers charge for custom SSL certificate backed CDN usage. For example Cloudflare is like US$600/yr per domain for custom SSL/https CDN setup. If you have 5 domains needing such = US$3,000/yr in setup fees for CDN + SSL

If this isn't the reason, then might as well stick with SSL/https redirects.

 

[Floren]

I can think of one valid reason.

If you are an entry level, why use a CDN from start, your site will certainly not need it. If you are busy, obviously the monetization of your forums should easily allow you to pay an extra $20/month, on top of the increased hosting costs.

 

[eva2000]

If you are an entry level, why use a CDN from start, your site will certainly not need it. If you are busy, obviously the monetization of your forums should easily allow you to pay an extra $20/month, on top of the increased hosting costs.

Maybe budget limitations and having visitor traffic in non-USA location i.e. if their forum visitors are in Asia but Asian web hosting is expensive so they choose a US based web host/server but want a CDN to give their Asian visitors a better experience latency wise. Being in Australia, I can understand that as any USA site I visit automatically gets 2-4 seconds added onto it for page loads due to my geographical location. Not everyone is based and targets US traffic/visitors

 

[rdn]

Yeah, @eva2000 answer it for me
Another reasons:
I tried to revert back to pure http to minimize SSL negotiation every time my forum is visited.
When I tried to use CloudFlare, I cannot use the free option cause they don't support ssl on Free plan.
ngx_pagespeed doesn't work really well on https website and it's flawless on http only.
And if I add another static domain with https of course, that will add another SSL negotiation
Being on http only, you don't have to worry about your certificate might not be read by some older browser or older phone.
As for revenue, nah it's very limited on ASIA specific visitors, think of 1/10 with US revenue.

 

[rdn]

I think, it's better to stay with https
http://googleonlinesecurity.blogspot.com/2014/08/https-as-ranking-signal_6.html

 

[Marcus]

From my experience 40% of ad agencies do not support https currently "out of the box". With hundreds of more clients, I was the only one who told them "please create certificates for your ads, etc.".

I lost at least four figures due to the https "upgrade". I downgraded last month to http.

I may consider https for logged in members in the future.

 

[Floren]

When I tried to use CloudFlare, I cannot use the free option cause they don't support ssl on Free plan.

Read the "Google Ranks SSL Sites Better" article on AXIVO.

 

[rdn]

Just read that news yesterday