Recently I've been seeing a large increase in the following error being getting logged in my Elmah.IO logs for a couple of Umbraco sites:
Failed to determine if request was client side
The problem with it is that there is no additional information with it so I'm unable to investigate where this is happening. All I know is that it is being thrown by the following:
System.ArgumentException: Illegal characters in path.
at System.IO.Path.CheckInvalidPathChars(String path, Boolean checkAdditional)
at System.IO.Path.GetExtension(String path)
at Umbraco.Core.UriExtensions.IsClientSideRequest(Uri url)
It seems to only really be happening on Umbraco 7.10 and newer.
Has anyone else noticed this behaviour at all? Or have any ideas on how I can find out where this is occurring in order to try and address it.
Yep I have quite a few third party plugins. This wasn't being triggered previously though, it's only started happening since upgrading to 7.10 and no new plugins were added at this point.
I got the same problem. Anyone who has solved this?
Update:
Umbraco had a message saying the following: "Last deploy didn't go as planned. Often this problem is solved by making a change and do a new deployment."
I tried to make a line change in a .cs view file and commit it again. When doing so, git detected some new pending changes made by Umbraco that got merged into my "master" branch. When pushing through to Live with these changes, I didn't get the error anymore.
All environments are up to date for us with no issue what so ever to report, so it doesn't seem to be deployment related. The issue only occurs on the live environment as well.
Originally I was told special characters in the URL could trigger that as digging deeper into the error we can see the issue linked to the Umbraco.Core.UriExtensions.IsClientSideRequest extension.
I was subsequently told to use VS to load up the extension and see what is being loaded, which could] potentially lead to the source.
Even with all those information I still have not been able to determine why this is occurring all the time. A bit out of my depth here to be honest.
I've been getting similar errors on low volume for a long time. There is never enough detail in the message to determine the issue and as it was low impact I set it aside. However, it's now brought the site down today and client hopping mad.
It probably is, but unfortunately we don't have a) the urls or b) the request information so can't look at blocking the crawler / urls so it just spams the logs unfortunately.
Think is, it only started happening in later versions of Umbraco so it's frustrating :-) It's not a bug, there is just insufficient information logged imo.
Do you have access to check your IIS logs[this is to find who is requesting]? You could try searching those for the same date range that you are getting those requests.
Based on the fact that it is illegal characters in the path, it brings to mind a setting in the web.config which behaves very differently when using apsnet20 vs the setting that is more up to date.
I can confirm the same issue, happens too often, also in load balanced environment on a 7.12.3 installation... GitHub issue got closed :(, but from what I can see here, lots of people are struggling with this error
We're seeing this error on multiple solutions also
Message:
Failed to determine if request was client side
Exception:
System.ArgumentException: Illegal characters in path.
at System.IO.Path.CheckInvalidPathChars(String path, Boolean checkAdditional)
at System.IO.Path.GetExtension(String path)
at Umbraco.Core.UriExtensions.IsClientSideRequest(Uri url)
It's spread out to both older and newer versions (2x 7.9.6, 1x 7.12.4 and 1x 7.13.2).
One thing we found was this started happening when got a massive spike in traffic, no idea why the spike happened but since traffic went back to normal we only get it intermittantly.
Ok this looks like the right direction. I identified 3 places where such calls were being made, essentially sending to nothing or had some strange parameter. Most of it stems from old custom code.
Now after removing them, the errors have mostly disappeared.
A few of them are still showing, so there must be something still there. But most are gone...
Failed to determine if request was client side
Hi all,
Recently I've been seeing a large increase in the following error being getting logged in my Elmah.IO logs for a couple of Umbraco sites:
The problem with it is that there is no additional information with it so I'm unable to investigate where this is happening. All I know is that it is being thrown by the following:
It seems to only really be happening on Umbraco 7.10 and newer.
Has anyone else noticed this behaviour at all? Or have any ideas on how I can find out where this is occurring in order to try and address it.
Thanks
Nik
Ni Nik,
I am getting the same issue, with a load of errors popping up everyday on the live environment.
I am using 7.12.4.
Exact same message... Still trying to identify the source of the problem.
Do you have any 3rd party plugin on your site by any chance?
Hi Gregory,
Yep I have quite a few third party plugins. This wasn't being triggered previously though, it's only started happening since upgrading to 7.10 and no new plugins were added at this point.
Thanks
Nik
I do have the same errors quite a lot on sites running 7.12.2.
Any help would be appreciated!
Cheers, Arjan
Same problem here, anyone here who managed to solve it? I don't have any third party plugins as of now but have recently removed some.
I got the same problem. Anyone who has solved this?
Update: Umbraco had a message saying the following: "Last deploy didn't go as planned. Often this problem is solved by making a change and do a new deployment."
I tried to make a line change in a .cs view file and commit it again. When doing so, git detected some new pending changes made by Umbraco that got merged into my "master" branch. When pushing through to Live with these changes, I didn't get the error anymore.
Update after getting this issue through support.
Using Umbraco Cloud here by the way.
All environments are up to date for us with no issue what so ever to report, so it doesn't seem to be deployment related. The issue only occurs on the live environment as well.
Originally I was told special characters in the URL could trigger that as digging deeper into the error we can see the issue linked to the Umbraco.Core.UriExtensions.IsClientSideRequest extension.
I was subsequently told to use VS to load up the extension and see what is being loaded, which could] potentially lead to the source.
Even with all those information I still have not been able to determine why this is occurring all the time. A bit out of my depth here to be honest.
Did anybody find a solution?
Not using Cloud. On Umbraco 7.12.4. The Error-logs are going nuts...
Thanks in advance for any help! Arjan
I've been getting similar errors on low volume for a long time. There is never enough detail in the message to determine the issue and as it was low impact I set it aside. However, it's now brought the site down today and client hopping mad.
Any further thoughts from HQ?
We get these regularly and only on Live. I suspect it is some crawler triggering it with invalid URLs.
It probably is, but unfortunately we don't have a) the urls or b) the request information so can't look at blocking the crawler / urls so it just spams the logs unfortunately.
Think is, it only started happening in later versions of Umbraco so it's frustrating :-) It's not a bug, there is just insufficient information logged imo.
Do you have access to check your IIS logs[this is to find who is requesting]? You could try searching those for the same date range that you are getting those requests.
Based on the fact that it is illegal characters in the path, it brings to mind a setting in the web.config which behaves very differently when using apsnet20 vs the setting that is more up to date.
Reference 1
Hi Bryna, no we don't have access to the logs. This is happening on the Cloud, I could ask for them I guess?
We just did a deploy on a site this morning not on cloud and its started going nuts with this same error.
I can confirm the same issue, happens too often, also in load balanced environment on a 7.12.3 installation... GitHub issue got closed :(, but from what I can see here, lots of people are struggling with this error
We're seeing this error on multiple solutions also
It's spread out to both older and newer versions (2x 7.9.6, 1x 7.12.4 and 1x 7.13.2).
One thing we found was this started happening when got a massive spike in traffic, no idea why the spike happened but since traffic went back to normal we only get it intermittantly.
Ok, so we got Umbraco to activate IIS logging on Cloud, and we've identified the source of the problem, at least in one of our cases.
It's a bot, called MJ12Bot, belonging to a SEO optimization service called Majestic https://majestic.com
We can see in the IIS log, that it requests weird URLs that, for some reason, include HTML, resulting in error 400 (Bad Request).
We'll discuss with the client if it's a service they use, if not then block it in robots.txt.
I'll bet when we look into the other cases, we'll find the same or similar problem.
Micheal,
Thanks for the update, we will look at turning on iis logs in azure see if anything shows up.
Regards
Ismail
thanks for the update, not a service we use, makes sense to ask to turn on iis logging (or ask for the logs if it were already on)
--Dirk
Here is a link showing common user-agents to block: https://www.inmotionhosting.com/support/website/restricting-bots/how-to-stop-search-engines-from-crawling-your-website
You may this helpful.
Looks like error occurs because of client dependency, when I set the application to debug=true, no more error in logs
It could be a third party plugin is,I have seen this before tracked it down to missing ;
thanks, in my case it's CSS file, I trying to find the issue
Update:
in my case it was empty url in background-image:
after removing it - no more errors
Interesting! Thank you for this. I will look into it, it is quite possible this is the cause.
Ok this looks like the right direction. I identified 3 places where such calls were being made, essentially sending to nothing or had some strange parameter. Most of it stems from old custom code.
Now after removing them, the errors have mostly disappeared.
A few of them are still showing, so there must be something still there. But most are gone...
Thank you Yakov!
is working on a reply...