So I finally changed one of my sites to HTTPS...

**rowan** · 02-25-2017, 07:47 AM

Well this is fun.

Program 1 - doesn't support HTTPS at all.
Program 2 - server running on port 443, but certificate is for a different domain.

I've not had much luck with contacting either program in the past but I've given it a go anyway.

**incredibleworkethic** · 02-25-2017, 07:48 AM

PHP redirects link to your site and redirect

**rowan** · 02-25-2017, 07:50 AM

Originally posted by incredibleworkethic

PHP redirects link to your site and redirect

Eh?.....

**incredibleworkethic** · 02-25-2017, 07:53 AM

Site.com/go/affiliate/

In the affiliate folder, create index.php that redirects a header to your sponsor.

**rowan** · 02-25-2017, 08:03 AM

Originally posted by incredibleworkethic

Site.com/go/affiliate/

In the affiliate folder, create index.php that redirects a header to your sponsor.

Won't work. It's necessary to IFRAME HTML or inline images from the program's site. That's what is breaking things.

**Paul&John** · 02-25-2017, 08:23 AM

Got the same issue with a VR video embed from one of the sponsors, they offer only HTTP.

**incredibleworkethic** · 02-25-2017, 08:42 AM

I'm so so sorry. I totally misread some of your question!

**Bladewire** · 02-25-2017, 08:48 AM

html - How to allow http content within an iframe on a https site - Stack Overflow

The best solution I created is to simply use google as the ssl proxy...

Code:

https://www.google.com/search?q=%http://yourhttpsite.com&btnI=Im+Feeling+Lucky

Tested and works in firefox.

Other Methods:

Use a Third party such as embed.ly (but it it really only good for well known http APIs).
Create your own redirect script on an https page you control (a simple javascript redirect on a relative linked page should do the trick. Something like: (you can use any langauge/method)

https://mysite.com That has a iframe linking to...

https://mysite.com/utilities/redirect.html Which has a simple js redirect script like...

document.location.href ="http://thenonsslsite.com";
Alternatively, you could add an RSS feed or write some reader/parser to read the http site and display it within your https site.
You could/should also recommend to the http site owner that they create an ssl connection. If for no other reason than it increases seo.
Unless you can get the http site owner to create an ssl certificate, the most secure and permanent solution would be to create an RSS feed grabing the content you need (presumably you are not actually 'doing' anything on the http site -that is to say not logging in to any system).

The real issue is that having http elements inside a https site represents a security issue. There are no completely kosher ways around this security risk so the above are just current work arounds.

Note, that you can disable this security measure in most browsers (yourself, not for others). Also note that these 'hacks' may become obsolete over time.

**brandonstills** · 02-25-2017, 11:09 AM

LOL. Thanks Google for forcing everyone to waste time with https even when we aren't transmitting anything that requires security.

**Kittens** · 02-25-2017, 11:24 AM

Originally posted by brandonstills

LOL. Thanks Google for forcing everyone to waste time with https even when we aren't transmitting anything that requires security.

That's the stupidest boneheaded fucking statement I've ever fucking read in my entire fucking life. Congratulations on being a dip shit.

**thommy** · 02-25-2017, 11:47 AM

Originally posted by rowan

Everything's going peachy as I set up my Let's Encrypt certificate, set up Apache on port 443, and start progressively changing references...

Then I discover that one of the affiliate programs I use only supports HTTP.

It's inlined content (IFRAME) so there's really no option but to accept that it's going result in a broken padlock on most browsers.

Anyone else had the same problem when switching to HTTPS?

this is EXACTLY what i mentioned in the other thread about https.
you will have a problem with all links and includes what are NOT on https.

so if you have NO FORM on your page where users have to send data (like email or personal information) i would not recommend to use https and i have NOT seen yet a site what suffers on that as long there are no forms in the page.

and i can tell you that i have analytics access to many sites what are receiving a few 100 thsd users per day from google.

**Ferus** · 02-25-2017, 12:20 PM

Originally posted by thommy

this is EXACTLY what i mentioned in the other thread about https.
you will have a problem with all links and includes what are NOT on https.

so if you have NO FORM on your page where users have to send data (like email or personal information) i would not recommend to use https and i have NOT seen yet a site what suffers on that as long there are no forms in the page.

and i can tell you that i have analytics access to many sites what are receiving a few 100 thsd users per day from google.

No matter what you claim, a Secure site (using https) would always rank better than an unsecure site.

So if you want the extra edge in the race to page1, then you need to use all elements possible.

If you cant figure out how to run the site from HTTPS only, you are in for some trouble in the future.

That said, I still run many sites with no encryption, if its just for contact info or refference.

**Kittens** · 02-25-2017, 12:22 PM

Originally posted by thommy

this is EXACTLY what i mentioned in the other thread about https.
you will have a problem with all links and includes what are NOT on https.

so if you have NO FORM on your page where users have to send data (like email or personal information) i would not recommend to use https and i have NOT seen yet a site what suffers on that as long there are no forms in the page.

and i can tell you that i have analytics access to many sites what are receiving a few 100 thsd users per day from google.

There's more important reasons to secure your site than having forms where users data is sent.

Educate yourself, and stop being a dipshit like shit for brains above.

**thommy** · 02-25-2017, 12:50 PM

Originally posted by Kittens

There's more important reasons to secure your site than having forms where users data is sent.

Educate yourself, and stop being a dipshit like shit for brains above.

so than tell me one or 2 of this reasons.

btw - i do not have to educate myself i do this for 20 years you twip and i have for sure more sites in the top position as you have ever seen.

so do what you want - i just tell you my experience but if you have a method to reach a position higher than no. 1 than you obviously know more then me.

**Bladewire** · 02-25-2017, 12:52 PM

Originally posted by thommy

so than tell me one or 2 of this reasons.

btw - i do not have to educate myself i do this for 20 years you twip and i have for sure more sites in the top position as you have ever seen.

so do what you want - i just tell you my experience but if you have a method to reach a position higher than no. 1 than you obviously know more then me.

Don't waste your time & energy Kittens is a new fake troll account.

**Kittens** · 02-25-2017, 01:05 PM

Originally posted by thommy

so than tell me one or 2 of this reasons.

btw - i do not have to educate myself i do this for 20 years you twip and i have for sure more sites in the top position as you have ever seen.

so do what you want - i just tell you my experience but if you have a method to reach a position higher than no. 1 than you obviously know more then me.

Oh okay, you've been doing this for 20 years, so clearly you know what's good.

First and foremost, HTTPS protects your users. Posting a news update on a user forum may cost a dissident his life in an oppressive regime; A strict workplace may terminate employment based on an employee?s browsing activity; And of course, the Snowden affairs have clearly shown governments simply can?t get enough of this data. Using HTTPS makes it dramatically harder for these players to know what users are doing, and helps you maintain your most important responsibility ? your users trust.

Unencrypted content can easily be tampered. In addition, unencrypted pages are often in the path to secure ones. For instance, consider a shopping site where a product page is unencrypted, but the actual purchase flow uses HTTPS. A man-in-the-middle can change the unprotected product page, making the ?Add to Cart? button go to their evil copy of the website, and the browser (and user) will see no difference. If you only want your users to see the content you actually posted, and want their actions to always reach you, use HTTPS.

Roughly 18 years after its inception, HTTP/1.1 is finally getting refreshed. It?s successor, HTTP/2, has been officially completed in May (2015). HTTP/2 further evolves Google?s SPDY, and includes many significant improvements over HTTP/1.1, ranging from request multiplexing to header compression to server-side push. For compatibility reasons, as well as a desire to make the web secure, browsers will only support HTTP/2 over HTTPS (the spec states encryption is optional). If you want to benefit from this evolution of the web ? you need to switch to HTTPS.

Criminals are not the only ones looking to make money of your site ? Internet and WiFi providers want in on it too. As many as 38% of WiFi proxies, ranging from giants like Comcast to smaller providers, inject their own ads on unencrypted pages. If ads are how you make money, know those ads may be hijacked, and your users will be none the wiser. If your website is not using ads? Your users may see some anyway, and blame you for it. Use HTTPS to prevent such tampering and protect your revenue & brand.

HTTPS aims to protect your privacy, including not sharing with others what you?re browsing. Imagine you browse https://secret.com/HelloKitty/ and click a link to the unencrypted http://other.com/. If the request to other.com included the URL in a Referer (sic) header, anyone listening (as well as other.com) would know of your love for the little not-a-cat. To avoid such a violation, browsers do not send a Referer header when navigating from HTTPS to HTTP (unless explicitly overridden using a Referrer Policy). As more websites switch to HTTPS, staying on HTTP would hurt your insight into where your visitors are coming from.

Just to name a few.

**thommy** · 02-25-2017, 01:22 PM

Originally posted by Kittens

Oh okay, you've been doing this for 20 years, so clearly you know what's good.

First and foremost, HTTPS protects your users. Posting a news update on a user forum may cost a dissident his life in an oppressive regime; A strict workplace may terminate employment based on an employee?s browsing activity; And of course, the Snowden affairs have clearly shown governments simply can?t get enough of this data. Using HTTPS makes it dramatically harder for these players to know what users are doing, and helps you maintain your most important responsibility ? your users trust.

Unencrypted content can easily be tampered. In addition, unencrypted pages are often in the path to secure ones. For instance, consider a shopping site where a product page is unencrypted, but the actual purchase flow uses HTTPS. A man-in-the-middle can change the unprotected product page, making the ?Add to Cart? button go to their evil copy of the website, and the browser (and user) will see no difference. If you only want your users to see the content you actually posted, and want their actions to always reach you, use HTTPS.

Roughly 18 years after its inception, HTTP/1.1 is finally getting refreshed. It?s successor, HTTP/2, has been officially completed in May (2015). HTTP/2 further evolves Google?s SPDY, and includes many significant improvements over HTTP/1.1, ranging from request multiplexing to header compression to server-side push. For compatibility reasons, as well as a desire to make the web secure, browsers will only support HTTP/2 over HTTPS (the spec states encryption is optional). If you want to benefit from this evolution of the web ? you need to switch to HTTPS.

Criminals are not the only ones looking to make money of your site ? Internet and WiFi providers want in on it too. As many as 38% of WiFi proxies, ranging from giants like Comcast to smaller providers, inject their own ads on unencrypted pages. If ads are how you make money, know those ads may be hijacked, and your users will be none the wiser. If your website is not using ads? Your users may see some anyway, and blame you for it. Use HTTPS to prevent such tampering and protect your revenue & brand.

HTTPS aims to protect your privacy, including not sharing with others what you?re browsing. Imagine you browse https://secret.com/HelloKitty/ and click a link to the unencrypted http://other.com/. If the request to other.com included the URL in a Referer (sic) header, anyone listening (as well as other.com) would know of your love for the little not-a-cat. To avoid such a violation, browsers do not send a Referer header when navigating from HTTPS to HTTP (unless explicitly overridden using a Referrer Policy). As more websites switch to HTTPS, staying on HTTP would hurt your insight into where your visitors are coming from.

Just to name a few.

did you really read what i wrote ????

so if you have NO FORM on your page where users have to send data (like email or personal information) i would not recommend to use https and i have NOT seen yet a site what suffers on that as long there are no forms in the page.

you really do not have to explain me the advantages of https but you hopefully do not want to explain me also that EVERY link or include in a website is already on https ?

how many trafficexchanges you have seen i.e. WITH https ?
how many adservers are NOT using https?
how many counters?
how many dynamic advertisements from sponsors?

it can be easy to change yourself to https but it is a mess if you want to change ALL what might be included. so IT DEPENDS on the website if that makes sense now or not.

practically it WILL BE an issue in a not so far future but til THAN a website on http what does not have any 2way communication where personal data can be spied will not have a problem NOW.

ipv6 was possible already 10 years ago and WHY isn´t it standard til today?
its the SAME issue !!! you can not change the circumstances around you and THAT is my point.

but anyway - you brought me on a HUGE idea with another issue i need to resolve and that little kinky conversation helped me to find it.

thanks to you for that ;-)

**Barry-xlovecam** · 02-25-2017, 01:37 PM

XloveCam.com affiliate tools are 100% HTTPS
Lots of other sponsors have had to do the same.

Use sponsors that can support your change to HTTPS.

**Kittens** · 02-25-2017, 01:39 PM

Originally posted by thommy

did you really read what i wrote ????

you really do not have to explain me the advantages of https but you hopefully do not want to explain me also that EVERY link or include in a website is already on https ?

how many trafficexchanges you have seen i.e. WITH https ?
how many adservers are NOT using https?
how many counters?
how many dynamic advertisements from sponsors?

it can be easy to change yourself to https but it is a mess if you want to change ALL what might be included. so IT DEPENDS on the website if that makes sense now or not.

practically it WILL BE an issue in a not so far future but til THAN a website on http what does not have any 2way communication where personal data can be spied will not have a problem NOW.

ipv6 was possible already 10 years ago and WHY isn´t it standard til today?
its the SAME issue !!! you can not change the circumstances around you and THAT is my point.

but anyway - you brought me on a HUGE idea with another issue i need to resolve and that little kinky conversation helped me to find it.

thanks to you for that ;-)

Clearly you didn't read anything I wrote.

**Colmike9** · 02-25-2017, 01:49 PM

Edit: idk

**rowan** · 02-25-2017, 03:51 PM

Hasn't been a totally clean switch either. I expected some odd behaviour here and there, but I've noticed quite a bit, even from browsers with common user agents that should support HTTPS 100%.

Here's some log entries. The last value is the port (HTTP=80, HTTPS=443).

There's browsers which switch without fuss, going from port 80 to 443 within a second:

Code:

x.x.x.x - - [26/Feb/2017:04:19:33 +1100] "GET / HTTP/1.1" 302 - https://www.google.com/ 55308 0 80
x.x.x.x - - [26/Feb/2017:04:19:34 +1100] "GET / HTTP/1.1" 200 1878 https://www.google.com/ 55308 0 443
(...fetch all future objects on port 443)

There's browsers which are delayed for some reason, perhaps because of a user confirmation dialog? This IP had 22 seconds between the redirect (HTTP) and the content fetch (HTTPS) :

Code:

x.x.x.x - - [26/Feb/2017:04:19:47 +1100] "GET / HTTP/1.1" 302 - - 55278 0 80
x.x.x.x - - [26/Feb/2017:04:20:09 +1100] "GET / HTTP/1.1" 200 1878 - 55308 0 443

Then there's these browsers, which don't redirect to HTTPS, and they continue connecting to port 80, even though the referer suggests they're HTTPS capable:

Code:

x.x.x.x - - [26/Feb/2017:04:22:13 +1100] "GET / HTTP/1.1" 302 - https://www.google.com/ 55278 0 80
x.x.x.x - - [26/Feb/2017:04:22:31 +1100] "GET / HTTP/1.1" 302 - https://www.google.com/ 55278 0 80
x.x.x.x - - [26/Feb/2017:05:22:43 +1100] "GET / HTTP/1.1" 302 - http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=[.....] 55278 0 80

Note he gave up for an hour, then tried again...

It's the latter case that concerns me, because it looks like they're no longer able to access the site at all. I ended up writing some extra scripting that only sends the 302 HTTP->HTTPS redirect once; if the browser continues to connect to port 80, it will fall back to permitting normal site access via HTTP.

So far around 19% of IPs have hit that fallback exception, which seems a very high number.

**Barry-xlovecam** · 02-25-2017, 04:16 PM

You got root on the server?

Code:

LoadModule ssl_module modules/mod_ssl.so

Listen 443
<VirtualHost *:443>
    ServerName www.example.com
    SSLEngine on
    SSLCertificateFile "/path/to/www.example.com.cert"
    SSLCertificateKeyFile "/path/to/www.example.com.key"
</VirtualHost>

this is the way it is done

https://httpd.apache.org/docs/2.4/ssl/ssl_howto.html
https://httpd.apache.org/docs/2.4/mod/mpm_common.html
Multiple Listen directives may be used to specify a number of addresses and ports to listen to. The server will respond to requests from any of the listed addresses and ports.

For example, to make the server accept connections on both port 80 and port 8000, use:

Code:

Listen 80
Listen 443

I added the Listen 443

that should* solve some of the problem -- I don't think that would redirect ALL requests to HTTPS/TLS 443
You don't want to use 301 redirection in a php script
or are you using an Apache .htaccess directive like Rewrite of Redirect Match

This is much simpler to do with Nginx

Configuring HTTPS servers

Code:

Code:

server {
  listen 80;
  listen 443 ssl;
  # force https-redirects
  if ($scheme = http) {
    return 301 https://$server_name$request_uri;
  }
}

2 ways to do it in Nginx

**rowan** · 02-25-2017, 04:34 PM

? As per my above post I already have Apache listening on both port 80 and port 443. Exact same config, except the latter has the SSL directives.

I've also shown that unconditional HTTP->HTTPS redirection doesn't seem to work for a lot of people, which is why I added in the conditional redirect.

What's wrong with doing a redirection in a PHP script?

**Barry-xlovecam** · 02-25-2017, 08:26 PM

PHP is way too slow

Code:

RewriteCond %{SERVER_PORT} ^80$
RewriteRule .* https://%{SERVER_NAME}%{REQUEST_URI} [R,L]

Try this in the DocumentRoot .htaccess file

htaccess HTTPS / SSL Tips, Tricks, and Hacks

very good site and usually dead nuts right.

**Zeiss** · 02-25-2017, 08:44 PM

HTTPS is crap.

**rowan** · 02-25-2017, 10:05 PM

Originally posted by Barry-xlovecam

PHP is way too slow

Have you actually used it at any time in the past 15 years?

The site is PHP based, so adding an extra few statements makes near zero difference to load time. HTTPS negotiation is the bottleneck here...

Originally posted by Barry-xlovecam

Code:

RewriteCond %{SERVER_PORT} ^80$
RewriteRule .* https://%{SERVER_NAME}%{REQUEST_URI} [R,L]

This is an unconditional redirect. As I've already mentioned above this does not seem to work for many browsers. I started with an unconditional redirect and noted that browsers were getting stuck on port 80, which is why I changed it to a "try once" HTTPS redirect, with fallback to plain HTTP if they continue to connect to port 80. Try doing that with htaccess

**Barry-xlovecam** · 02-26-2017, 04:24 AM

Server daemons are a lot faster than ALL interpreter languages -- good luck

What are the user-agents that are not accepting the redirects.
It is also possible that ad blockers may be a factor.
What percentage of browsers are a problem -- and do they matter?

If its 5% -- and obsolete --fuck em some people still tweak CSS3 for IE7

You post log entries that are incomplete and useless
How the fuck can I tell -- there are no user agents?

The only problem we have had with HTTPS/TLS is with the googlebot and ITS indexing -- Google is so full of shit.

Did you first try in .htaccess <= the fastest way or not?

**Konda** · 02-26-2017, 06:14 AM

Originally posted by thommy

did you really read what i wrote ????

you really do not have to explain me the advantages of https but you hopefully do not want to explain me also that EVERY link or include in a website is already on https ?

how many trafficexchanges you have seen i.e. WITH https ?
how many adservers are NOT using https?
how many counters?
how many dynamic advertisements from sponsors?

it can be easy to change yourself to https but it is a mess if you want to change ALL what might be included. so IT DEPENDS on the website if that makes sense now or not.

practically it WILL BE an issue in a not so far future but til THAN a website on http what does not have any 2way communication where personal data can be spied will not have a problem NOW.

ipv6 was possible already 10 years ago and WHY isn´t it standard til today?
its the SAME issue !!! you can not change the circumstances around you and THAT is my point.

but anyway - you brought me on a HUGE idea with another issue i need to resolve and that little kinky conversation helped me to find it.

thanks to you for that ;-)

Outgoing links don't have to be https, the only thing that will trigger a warning is when you include a non secure item (such as a js file or iframe/ad code or image). Any reputable ad network, counter, third party plugins, etc. offer https. If you use any sponsor, ad network, counter, js, etc. that doesn't in 2017 I would leave them asap, because they obviously don't take security seriously, so I wouldn't trust them with anything.

**Konda** · 02-26-2017, 06:18 AM

Originally posted by rowan

Everything's going peachy as I set up my Let's Encrypt certificate, set up Apache on port 443, and start progressively changing references...

Then I discover that one of the affiliate programs I use only supports HTTP.

It's inlined content (IFRAME) so there's really no option but to accept that it's going result in a broken padlock on most browsers.

Anyone else had the same problem when switching to HTTPS?

Just drop them. I would not trust my data with an affiliate program that doesn't even bother to set up https...

**Barry-xlovecam** · 02-26-2017, 06:19 AM

Originally posted by Konda

Outgoing links don't have to be https, the only thing that will trigger a warning is when you include a non secure item (such as a js file or iframe/ad code or image). Any reputable ad network, counter, third party plugins, etc. offer https. If you use any sponsor, ad network, counter, js, etc. that doesn't in 2017 I would leave them asap, because they obviously don't take MARKETING seriously, so I wouldn't trust them with anything.

I fixed that for you

**Barry-xlovecam** · 02-26-2017, 06:43 AM

https://gist.github.com/medhi/25368643e33d650630cb

Maybe this will help -- it is 1 year old.

bontchev commented on Mar 1, 2016

It does work on WinXP with Firefox (which uses a different certificate repository and has less buggy certificate parsing), so you might want to change your rule accordingly (i.e., redirect to HTTPS only if the OS is WinXP and the browser is not Firefox.

But this whole idea works only if one is visiting the site directly (via HTTP). If one clicks on an HTTPS link leading to the site, the redirection won't happen and the site will be inaccessible from these environments.

Basically, with free certificates like Let's Encrypt you get what you pay for. It's not their fault (it's a combination of problems in WinXP etc. and in the certificate they have been certified with), but there you have it.

**rowan** · 02-27-2017, 12:13 PM

Looks like the redirect issue is mostly moot now - Google has picked up the 301, and is now referring people directly to the HTTPS URL.

No chance now of an automated fallback to HTTP, if a browser referred by Google decides (for whatever reason) that it doesn't like my Let's Encrypt certificate.

Guess I now need to be looking for port 443 connections that don't fully load the page...

**rowan** · 03-31-2017, 08:42 AM

Originally posted by rowan

Everything's going peachy as I set up my Let's Encrypt certificate, set up Apache on port 443, and start progressively changing references...

Then I discover that one of the affiliate programs I use only supports HTTP.

It's inlined content (IFRAME) so there's really no option but to accept that it's going result in a broken padlock on most browsers.

Anyone else had the same problem when switching to HTTPS?

A month later, and it's apparent that inlining a program's HTTP content on my HTTPS site is a serious problem.

Daily referrals to the webcam affiliate program dropped from 90-100, down to around 10. The drop happened immediately after I switched to HTTPS.

This is a massive decrease in leads, and potentially, my long term income from that program.

I'm going to have to set up some kind of HTTP->HTTPS proxy so that I can serve the content myself, because the program is too damn lazy/apathetic to spend a couple of hundred bucks on a certificate and set up HTTPS.

So think twice about switching to HTTPS "because Google told you to"

**rowan** · 03-31-2017, 09:04 AM

Graph showing the clear drop in leads right after switching to HTTPS.

Daily traffic on my own site has changed very little since the switch, but leads to the HTTP-only program have.

**Barry-xlovecam** · 03-31-2017, 09:06 AM

XloveCam/XloveCash affiliate tools are 100% HTTPS for some months now ...

Unfortunately, you may experience a SERPs problem while your website is being reindexed in HTTPS.

**Major (Tom)** · 03-31-2017, 09:11 AM

Originally posted by Barry-xlovecam

XloveCam/XloveCash affiliate tools are 100% HTTPS for some months now ...

Unfortunately, you may experience a SERPs problem while your website is being reindexed in HTTPS.

Barry uses the new "snowflake" https protocol. It's superior.
Na Barry I'm just busting. I hear you run a great program man. And you always have great tech input.
Duke

**Major (Tom)** · 03-31-2017, 09:14 AM

We went https by our old tech and he fucked us out of seo results, downtime, you name it. Had to have woj fix everything.
Ds

**thommy** · 03-31-2017, 10:11 AM

Originally posted by Barry-xlovecam

XloveCam/XloveCash affiliate tools are 100% HTTPS for some months now ...

Unfortunately, you may experience a SERPs problem while your website is being reindexed in HTTPS.

i don´t think so because the fall down was already before.
can be a victim of the last google update or someone who have copied the page.

@ rowan:

if you pm me the url i will have a look on it.

**Qbert** · 03-31-2017, 11:35 PM

If there is anything in your site coding that relies on http header data you will have serious issues switching an http site to https. When you redirect incoming http traffic to the https site via .htaccess, the http header data is not retained.

**rowan** · 03-31-2017, 11:58 PM

Originally posted by Qbert

If there is anything in your site coding that relies on http header data you will have serious issues switching an http site to https. When you redirect incoming http traffic to the https site via .htaccess, the http header data is not retained.

Do you mean POST data? I log all HTTP headers, and I just looked at a couple of HTTP 301->HTTPS 200 sequences - all headers are preserved over the redirect, including the referer.

**Jigster715** · 04-01-2017, 04:57 AM

Google really sucketh dicketh.

**freecartoonporn** · 04-01-2017, 05:40 AM

i siwtched my site to https and traffic dropped 90% .
becuase google is stupid and treats http and https as 2 separate sites/entities. it takes time to get back to old position/rankings ...

lesson learned., https is not that important if you are not having members area or billing members.

majority top 10k alexa sites are still using http as preferred its not that they dont support https, but at least they are not doing 301 from http to https..

2 cents.

**Jigster715** · 04-01-2017, 05:47 AM

Originally posted by freecartoonporn

i siwtched my site to https and traffic dropped 90% .
becuase google is stupid and treats http and https as 2 separate sites/entities. it takes time to get back to old position/rankings ...

lesson learned., https is not that important if you are not having members area or billing members.

majority top 10k alexa sites are still using http as preferred its not that they dont support https, but at least they are not doing 301 from http to https..

2 cents.

Problem for us is some sites we submit to, like the Hun have announced if you have not switched it may be a problem soon. If I understand their message correctly.

**Cameltoepro** · 04-01-2017, 08:30 AM

Originally posted by Jigster715

Problem for us is some sites we submit to, like the Hun have announced if you have not switched it may be a problem soon. If I understand their message correctly.

I submit to the HUN a lot and never received any notice from them on the https issue..Just went and check there rules again and I do not see anywhere in there about switching to https. Unless I'm not looking in the right place.

**freecartoonporn** · 04-01-2017, 09:43 AM

Originally posted by Jigster715

Problem for us is some sites we submit to, like the Hun have announced if you have not switched it may be a problem soon. If I understand their message correctly.

imho just enabling https doesnt hurt, but force redirecting one protocol to another does . i am talking about serp here and not direct traffic.

**Kittens** · 04-01-2017, 11:02 AM

Originally posted by freecartoonporn

imho just enabling https doesnt hurt, but force redirecting one protocol to another does . i am talking about serp here and not direct traffic.

You realize HTTPS is now a form of SEO, right? Google favors HTTPS over non-HTTPS.

**maximoi** · 04-01-2017, 11:05 AM

Has anyone made the transition from http to https: on Wordpress without any ranking drop? If so what plugin if any?

Thanks

**incredibleworkethic** · 04-02-2017, 12:10 AM

Originally posted by maximoi

Has anyone made the transition from http to https: on Wordpress without any ranking drop? If so what plugin if any?

Thanks

The rankings for me go down, then come back up after re-indexing.

**rowan** · 04-09-2017, 08:26 AM

So I got the HTTPS proxy set up, which rewrites http:// references to go via the script (which is fetched via HTTPS) rather than the affiliate site (which is HTTP). The intent is to prevent the browser warning of insecure content, because my HTTPS page includes content from a HTTP URL.

Then I find that the affiliate program drops my refid from the HTML when my server fetches the content on behalf of the visitor, instead of the visitor's browser fetching it directly. My workaround does NOT work.

I've sent them 3 messages in the past 6 weeks and there's been no response.

Don't know whether to laugh, or cry.

So I finally changed one of my sites to HTTPS...

So I finally changed one of my sites to HTTPS...

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment