Why WordPress automatically removes http from the url of my website's sub domain?

Developers
1

I am using Cloudfare on my WordPress website.

I am witnessing a strange problem in WordPress which automatically removes ‘http’ from my sub domain link. I don’t know why this is happening.

Note that my domain is https while it’s subdomain is http .

My WordPress is installed in my main domain. When I add the below url of my sub domain to any post:

<a href="http://www.demo.yogihosting.com/jquery/jquery-removedata/">DEMO</a>

Then it automatically converts it to:

<a href="//www.demo.yogihosting.com/jquery/jquery-removedata/">DEMO</a>

See that the http is gone from the URL.

Also see this below gif image which lists this problem:

Note that it is not plugin problem as I already checked by disabling every plugin.

I think Cloudflare is doing it. Please help me in solving this problem.

Many thanks
Yogi

1 Like
2

It is relatively unlikely that Cloudflare is doing that. But you can easily verify that, by pausing Cloudflare, wait until DNS propagation is in place, and it check it in that way without Cloudflare. If the problem still occurs, it is an issue with your server. It it disappears, there is a chance it is Cloudflare.

1 Like
3

I think it’s Cloudflare. I created a copy of my website in a temporary domain (which is not connected to cloudflare nameservers) and then i tried doing the same thing.This time the ‘http’ is not removed.

See this gif image which shows the working in this case:

c

can you help me in finding out which thing in cloudflare is causing this problem - page rules or caching, or some thing other?

Please help?

4

A copy is not really reliable enough. You should pause the site as I mentioned and try it directly on your site then.

5

My website is currently running a lot of things which depends on cloudflare so I cannot pause it. Creating a copy of the website on another domain and testing it is the best solution in my case.

6

@sandro I confirm it is definitely cloudflare which is doing this. It is simply doing the ‘minification’ of html served to the client browser.

I checked what is going inside my database table. I check the record inside the ‘wp_posts’ table of wordpress and found that the link is saving correctly as ‘http’ only.

See the screenshot of the database data:
download

Can you help me in identifying which setting in cloudflare should I do to stop this.

Thank you once again for your help.

7

Well, right now the host does not seem to go through Cloudflare at all.

www.demo.yogihosting.com is a CNAME for demo.yogihosting.com, which is a non-proxied record and points straight to your server. So unless you changed that recently Cloudflare does not seem to be involved at all (except for the DNS service).

8

I am talking about the URL of demo.yogihosting.com which is getting changed in the HTML served by cloudflare.

I have already confirmed this from my hosting hosting company which also agrees with me.

9

I understand, but as I mentioned that host name is not going through Cloudflare, so Cloudflare cant filter anything out. Where would the Cloudflare connection be? Where is that HTML served from?

Can you post a link where this can be reproduced?

10

The url is https://www.yogihosting.com/jquery-ajax/. In this page you will find a ‘DEMO’ button on the bottom which will take you to https://www.demo.yogihosting.com/jquery/jquery-ajax/ instead of http://www.demo.yogihosting.com/jquery/jquery-ajax/

The website is using Cloudflare.

11

Would you feel comfortable sharing your server IP address here? If not, you can also run a test with the IP address at sitemeer.com and post back here the time when you ran the test, so I can dig it out.

12

from HTTP Header Checker - Check HTTP Response Headers With curl | KeyCDN Tools

for The Ultimate Revelation Of jQuery AJAX method with 7 Examples & Codes it’s going through cloudflare but seems varnish cache is the origin cloudflare is talking to first

HTTP/2 200
date: Mon, 16 Sep 2019 00:54:00 GMT
content-type: text/html; charset=UTF-8
set-cookie: __cfduid=dcc3a7aa43b4310434a318e03d51c42f11568595236; expires=Tue, 15-Sep-20 00:53:56 GMT; path=/; domain=.yogihosting.com; HttpOnly; Secure
display: pub_site_sol
expires: Sun, 15 Sep 2019 00:54:00 GMT
host-header: 192fc2e7e50945beb8231a492d6a8024
link: <https://www.yogihosting.com/wp-json/>; rel="https://api.w.org/", <https://www.yogihosting.com/?p=2362>; rel=shortlink
pagespeed: off
response: 200
vary: Accept-Encoding,User-Agent,X-APP-JSON
x-cache-enabled: True
x-ezoic-cdn: Miss
x-httpd: 1
x-middleton-display: pub_site_sol
x-middleton-response: 200
x-proxy-cache: HIT
x-sol: pub_site
set-cookie: wpSGCacheBypass=0; expires=Sun, 15-Sep-2019 21:54:50 GMT; Max-Age=0; path=/
set-cookie: ezoadgid_122531=-1; Path=/; Domain=yogihosting.com; Expires=Mon, 16 Sep 2019 01:23:57 UTC
set-cookie: ezoref_122531=; Path=/; Domain=yogihosting.com; Expires=Mon, 16 Sep 2019 02:53:57 UTC
set-cookie: ezoab_122531=mod67-c; Path=/; Domain=yogihosting.com; Expires=Mon, 16 Sep 2019 02:53:57 UTC
set-cookie: active_template::122531=pub_site.1568595237; Path=/; Domain=yogihosting.com; Expires=Wed, 18 Sep 2019 00:53:57 UTC
set-cookie: ezopvc_122531=1; Path=/; Domain=yogihosting.com; Expires=Mon, 16 Sep 2019 01:24:00 UTC
set-cookie: ezepvv=8437; Path=/; Domain=yogihosting.com; Expires=Tue, 17 Sep 2019 00:54:00 UTC
set-cookie: lp_122531=https://www.yogihosting.com/jquery-ajax/; Path=/; Domain=yogihosting.com; Expires=Mon, 16 Sep 2019 02:54:00 UTC
set-cookie: ezovid_122531=158414677; Path=/; Domain=yogihosting.com; Expires=Mon, 16 Sep 2019 01:24:00 UTC
set-cookie: ezovuuidtime_122531=1568595240; Path=/; Domain=yogihosting.com; Expires=Wed, 18 Sep 2019 00:54:00 UTC
set-cookie: ezovuuid_122531=a4f30d09-04da-469d-7975-0ac59b3579d5; Path=/; Domain=yogihosting.com; Expires=Mon, 16 Sep 2019 01:24:00 UTC
set-cookie: ezCMPCCS=true; Path=/; Domain=yogihosting.com; Expires=Wed, 16 Sep 2020 00:54:00 GMT
x-varnish: 72509218
age: 0
via: 1.1 varnish (Varnish/6.0)
x-vcache: Miss
x-shard: 10022459
cache-control: max-age=0, must-revalidate, no-cache, no-store
expect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
server: cloudflare
cf-ray: 516eddc62d08c28b-FRA
content-encoding: gzip

for https://www.demo.yogihosting.com/jquery/jquery-ajax/ it has invalid SSL cert with different domain

for http://www.demo.yogihosting.com/jquery/jquery-ajax/ not running behind cloudflare as it’s server is windows Plesk based

HTTP/1.1 200 OK
Content-Length: 2933
Content-Type: text/html
Content-Encoding: gzip
Last-Modified: Wed, 17 Jul 2019 09:56:23 GMT
Accept-Ranges: bytes
ETag: "96fefde3853cd51:0"
Vary: Accept-Encoding
Server: Microsoft-IIS/8.5
X-Powered-By: ASP.NET
X-Powered-By-Plesk: PleskWin
Date: Mon, 16 Sep 2019 00:56:06 GMT

do you have always use redirect http to https for requests enabled ?

image
image907×165 6.35 KB

and automatic http to https rewrites enabled ?

image
image887×118 7.02 KB

13

Yes

Yes

14

Couldn’t share Server IP due to security reasons.

But my hosting company support team accessed the domain through the IP address and found that ‘http’ from the URL is not removed. This confirms that when cloudflare comes then it removes http from the URL.

15

In that case I am afraid I can only refer you to support. https://support.cloudflare.com/requests/new

As I said three days ago, it is quite unlikely this is a Cloudflare issue, as Cloudflare is not doing any sort of that kind of filtering, but only the origin IP could have confirmed that or else proven your assumption.

1 Like
16

If support and look to it and provide me a proper solution then it will be good.

Waiting for support answer.

Thank you Sandro!

17

Sorry to chip in late to the party but this looks like a WordPress behaviour to me. I believe this as the change happens when you save your post. Wordpress runs content though filters and it’s possible that there is a filter on the content which is modifying the link.

What’s happening is that your URI is being converted from a HTTP link to a Protocol-Relative link. That in itself should not be an issue if your site is being served over HTTPS through Cloudflare as the relative link will also be requested over HTTPS. If you have entire site covered with an SSL certificate and Cloudflare is set to upgrade all HTTP requests to HTTPS, then you should have no issues.

If you do want to try and fix it though, I’d look at all the filters that run on ‘the_content’ and see what could be modifying the link. This might be a good place to start: https://stackoverflow.com/a/5225021

18

WordPress does not do this. I have already checked in a fresh WordPress installation.

19

Yes, but many things hook into WordPress’ filters. Themes, plugins, custom code. Due to the nature of WordPress it could be any number of things that are filtering the code. Have you tried looking at what could be filtering the content server-side?

1 Like
20

Yes looked deeply into it and WordPress has no role in it. Even my hosting company support person did relevant tests and come to the conclusion that it is not done by WordPress, it is done by CloudFlare.