Morten Ross

Hi,

Yes.

Also notice the rewrite of the rewritten, making the xcdn duplicated:

12/23/20 02:32:24.020 [93.184.119.203:53456 1 ovQ] [CDN] -fill before rewritten: https://www.ross.no/staging/xcdn.ross.nowp-content/2016/03/20160306-DSC_1446-1a1.jpg
12/23/20 02:32:24.020 [93.184.119.203:53456 1 ovQ] [CDN] -rewritten: xcdn.ross.noxcdn.ross.nowp-content/2016/03/20160306-DSC_1446-1a1.jpg

There is also a mix of utilizing https:// instead of https:// for the rewrite of the rewritten url:

12/23/20 02:32:24.521 [93.184.119.203:53456 1 ovQ] [CDN] rewrite https://xcdn.ross.noxcdn.ross.nowp-content/2016/03/20160307-DSC_0463-1a1-220×150.jpg

Hi,

Excerpt from rewrites:

12/23/20 02:32:24.020 [93.184.119.203:53456 1 ovQ] [CDN] -fill before rewritten: https://www.ross.no/staging/xcdn.ross.nowp-content/2016/03/20160306-DSC_1446-1a1.jpg
12/23/20 02:32:24.020 [93.184.119.203:53456 1 ovQ] [CDN] -rewritten: xcdn.ross.noxcdn.ross.nowp-content/2016/03/20160306-DSC_1446-1a1.jpg
12/23/20 02:32:24.500 [93.184.119.203:53456 1 ovQ] [CDN] rewrite https://www.ross.no/staging/wp-content/2016/03/20160306-DSC_1539-1a-700×466.jpg
12/23/20 02:32:24.501 [93.184.119.203:53456 1 ovQ] [CDN] -rewritten: xcdn.ross.nowp-content/2016/03/20160306-DSC_1539-1a-700×466.jpg
12/23/20 02:32:24.501 [93.184.119.203:53456 1 ovQ] [CDN] rewrite https://www.ross.no/staging/wp-content/2016/03/20160306-DSC_1539-1a-768×511.jpg
12/23/20 02:32:24.501 [93.184.119.203:53456 1 ovQ] [CDN] -rewritten: xcdn.ross.nowp-content/2016/03/20160306-DSC_1539-1a-768×511.jpg
12/23/20 02:32:24.501 [93.184.119.203:53456 1 ovQ] [CDN] rewrite https://www.ross.no/staging/wp-content/2016/03/20160306-DSC_1539-1a-1024×681.jpg
12/23/20 02:32:24.502 [93.184.119.203:53456 1 ovQ] [CDN] -rewritten: xcdn.ross.nowp-content/2016/03/20160306-DSC_1539-1a-1024×681.jpg
12/23/20 02:32:24.502 [93.184.119.203:53456 1 ovQ] [CDN] rewrite https://www.ross.no/staging/wp-content/2016/03/20160306-DSC_1539-1a-900×599.jpg
12/23/20 02:32:24.502 [93.184.119.203:53456 1 ovQ] [CDN] -rewritten: xcdn.ross.nowp-content/2016/03/20160306-DSC_1539-1a-900×599.jpg
12/23/20 02:32:24.502 [93.184.119.203:53456 1 ovQ] [CDN] rewrite https://www.ross.no/staging/wp-content/2016/03/20160306-DSC_1539-1a.jpg
12/23/20 02:32:24.503 [93.184.119.203:53456 1 ovQ] [CDN] -rewritten: xcdn.ross.nowp-content/2016/03/20160306-DSC_1539-1a.jpg

And here’s the duplication of the address:

12/23/20 02:32:24.521 [93.184.119.203:53456 1 ovQ] [CDN] rewrite https://xcdn.ross.noxcdn.ross.nowp-content/2016/03/20160307-DSC_0463-1a1-220×150.jpg
12/23/20 02:32:24.521 [93.184.119.203:53456 1 ovQ] [CDN] -rewrite failed: path not match: wp-content
12/23/20 02:32:24.521 [93.184.119.203:53456 1 ovQ] [CDN] rewrite https://xcdn.ross.noxcdn.ross.nowp-content/2016/03/20160306-DSC_9898-1a1-220×150.jpg
12/23/20 02:32:24.522 [93.184.119.203:53456 1 ovQ] [CDN] -rewrite failed: path not match: wp-content

M

• This reply was modified 3 years, 11 months ago by Morten Ross.
• This reply was modified 3 years, 11 months ago by Morten Ross.

Hi,

>you mean if you disable mobile cache , then this issue no longer happens ?

Yes, that correct.

M

Hi,

Before I’m willing to try that on live site, I need to resolve the garbage urls causing 404.

If I retry, and experience a new set of bad urls that don’t get removed, then I will have two sets of bad urls crawled by search engines and filling up the log.

I used cname on previous setup, but I moved server to get Litespeed, and cname setup (flattening) is not possible on my current isp/server, so the test (using QUIC.cloud DNS), will not be the same as the past one that has failed.

M

You requested the log, I attached it. Did you look at it?
4686 404 errors since 1 November. It’s not showing any signs of slowing down.

I would not have opened this ticket if anything of what your say in your latest response was working as designed/expected. I have used your services, and it has resulted in a barrage of 404s that did not exist prior to using this plugin/cloud service. The expected result is that when the cloud service is purged/closed, the incorrect urls would cease to exist. That has not happened. The current Lqip is at 0%, but there might have been something left in the previous profile, which was deleted. I created a new domainID and profile.

There is no local reference to cdn.ross.no, as I have purged weeks ago. Nor has there ever been any in the db. If there were references in db I would also not open a ticket here, as I would have done a search and replace and be rid of the problem.

Furthermore: You state that the correct cdn formatting is “https://cdn.exmaple.com/”

The urls requested/crawled are formatted with the cdn in the middle of the url:
/category/plants/cdn.ross.no/wp-content/2017/04/20170414-DSC_6271-4-82-1a-1.4-144×144.jpg

which means that even if the correct url format was used – e.g.:https://cdn.exmaple.com/

That would have ended up with this url:

/category/plants/https://cdn.exmaple.com//wp-content/2017/04/20170414-DSC_6271-4-82-1a-1.4-144×144.jpg

It should have looked like this:
https://cdn.exmaple.com//category/plants/wp-content/2017/04/20170414-DSC_6271-4-82-1a-1.4-144×144.jpg

So there are two problems here:

1: the injection of the cdn url in the middle of the correct non-cdn/original url – this will never be a working url
2: the lingering of the badly formatted url leading to the 404

As the UI accepts any text in the “CDN URL” field in CDN Settings, this could also have been Morten.Ross.org, which in turn would produce this URL:

/category/plantsMorten.Ross.orgwp-content/2017/04/20170414-DSC_6271-4-82-1a-1.4-144×144.jpg

As this input is accepted by the plugin, the question is where this is propagated and how it is dealt with when it further along the cdn-process fails. How does the code validate the saved and incorrect URL, and how is the error handled when it is eventually executed and generates a non-functional destination?

Bingbot and googlebot have found these incorrect urls at one time and are still utilizing them incessantly. These do not show up as 404s in the Webmaster tools, so I cannot control them there. Instead my log is filling up with 404s.

I understand how this should be working, but when it doesn’t, it’s necessary to trace and debug to find out what has actually happened.

The cause is the plugin.

M

Between me and you is cloud, QUIC.cloud being the one involved in accepting and maintaining the creation and usage of cdn.ross.no.

Hi,

The point of the 404s of the url with the bad cdn.ross.no is that it does not reside locally on my site, but is found in the cloud. The crawlers are directed to these urls but do not find these on my site, thus the 404. There is a reference to these bad urls left behind that are not cleared.

Wp_options only contain one entry for for “litespeed” -> option_name “cron”

Here is the 404 log in Excel – I’ve pivot’ed per IP adress for better tracking:
<iframe src=”https://onedrive.live.com/embed?cid=638B080F3FF7BE6D&resid=638B080F3FF7BE6D%211944&authkey=AM8CLqSE4biRKpc&em=2&#8243; width=”402″ height=”346″ frameborder=”0″ scrolling=”no”></iframe>

M

Hi,

I see it in WordPress log.

M

Hi,

> once you disable CDN feature , the URL rewritten is stopped and cleared

Yet I still see the CDN references for image files – weeks after CDN was disabled.

Where are they, and how do we remove all references to them?

M

• This reply was modified 3 years, 11 months ago by Morten Ross.

Hi,

I only disabled the mobile cache (Cache\Cache Control Settings\Cache Mobile=off | Enable Cache=on), which incidentally has been deactivated since, and there has been no new incidents, so there is an issue with the switching/detection mechanism.

M

Hi,

I first added to existing agents. That made the site unavailable.
Replaced default agents, and then the site was available.

Today (so no interaction from me), I find the site is unavailable. Deleted cache. No change. Deactivated cache – still unavailable. Replaced user agents with default. No change. Replaced default with wptouch’s user agents. Now site is available again.

Again I test with adding wptouch user agents with lscache’s agents, and now there is no issues with access on mobile.

It seems the underlying issue with switching to desktop is still there, as when the user agents list is extended, it’s not switching to desktop, but rather switching to a dead end – inaccessible site.

M

User agent, yes.

https://support.wptouch.com/article/1447-default-wptouch-pro-user-agents
iPhone & Mobile
iPod & Mobile
Android & Mobile
BB & Mobile Safari
BlackBerry & Mobile Safari
webOS
IEMobile/7.0
IEMobile/9.0
IEMobile/10.0
MSIE 10.0 & Touch
iPad
PlayBook
Xoom
P160U
SCH-I800
Nexus 7

• This reply was modified 3 years, 11 months ago by Morten Ross.

Hi,

The url was tested in input field of LScache UI “CDN URL”, so the question is where is this committed, and how can I positively remove it from existence?
This field is not explained, so that users frequently has problems with this will be eliminated if it’s explained, as well as input being validated.

The UI suggests https://cdn.www.ross.no/, but what is the correct url, and how will this be affected if you can input anything into the “CDN URL” field? If you don’t input anything there, is https://cdn.www.ross.no/ the active cdn url, or what is it?

I understand that the original urls are not affected, but there are links to faulty urls, and I need to know where these references are as they are not made up by crawlers.

Morten

Hi,

I’m using a desktop and mobile theme – so separate themes.

Morten

Hi,

Several hours after finishing publishing several posts, it happened again, but I have no clue as to any connection. Also it happened many hours after publishing this time, vs during publishing the prior time (yesterday). But I was adding new posts as it happened.

Report number: LDGLKAYG
Report date: 12/17/2020 21:24:15

Morten