(36)File name too long: AH00036: access to
Hello everyone !
I ask for your help because my host refuses to help me correct this problem that I encounter in my logs.
My domain is www.sivop.com and in my error logs I encounter this error which however should not be generated since all this content & lang = en_CI & lang = en_CI & lang = en_CI ....... does not exist since several months.
Also, the same problem arises on a file that does not exist either.
I thought create a file of the same name can correct the problem while making a redirect to the official page, but no, the problem persists yet this page has not been in more than a year.
I do not know what to do, I have untimely disconnection at peak times and ... well here I need your help please!
I ask for your help because my host refuses to help me correct this problem that I encounter in my logs.
My domain is www.sivop.com and in my error logs I encounter this error which however should not be generated since all this content & lang = en_CI & lang = en_CI & lang = en_CI ....... does not exist since several months.
[Thu Jul 04 11:56:35 2019] [error] [client 66.249.64.23] [host www.sivop.com] (36)File name too long: AH00036: access to /www.sivop.com&lang=fr_CI&lang=en_CI&devise=USD&devise=EUR&lang=en_CI&devise=EUR&devise=EUR&devise=EUR&lang=fr_CI&devise=EUR&devise=EUR&devise=XOF&devise=XOF&lang=fr_CI&lang=fr_CI&lang=fr_CI&lang=fr_CI&devise=EUR&lang=en_CI&devise=XOF&devise=USD&devise=USD&lang=fr_CI&lang=en_CI&lang=en_CI&devise=XOF failed (filesystem path '/homez.520/sivop/www/www.sivop.com&lang=fr_CI&lang=en_CI&devise=USD&devise=EUR&lang=en_CI&devise=EUR&devise=EUR&devise=EUR&lang=fr_CI&devise=EUR&devise=EUR&devise=XOF&devise=XOF&lang=fr_CI&lang=fr_CI&lang=fr_CI&lang=fr_CI&devise=EUR&lang=en_CI&devise=XOF&devise=USD&devise=USD&lang=fr_CI&lang=en_CI&lang=en_CI&devise=XOF')
[Thu Jul 04 11:56:41 2019] [error] [client 66.249.70.4] [host sivop.com] (36)File name too long: AH00036: access to /careers.php&lang=fr_CI&lang=en_CI&lang=fr_CI&lang=fr_CI&lang=fr_CI&lang=fr_CI&lang=en_CI&lang=fr_CI&lang=fr_CI&lang=en_CI&lang=en_CI&lang=en_CI&lang=en_CI&lang=fr_CI&devise=XOF&lang=fr_CI&lang=fr_CI&devise=XOF&lang=en_CI&lang=fr_CI&devise=EUR&lang=fr_CI&devise=XOF&devise=EUR&devise=EUR&devise=XOF&lang=en_CI&lang=en_CI&devise=EUR&devise=XOF&lang=en_CI&devise=EUR&devise=XOF&lang=fr_CI&devise=XOF&devise=EUR&devise=USD&devise=USD&devise=USD&lang=en_CI&devise=EUR&devise=EUR&devise=XOF&lang=en_CI failed (filesystem path '/homez.520/sivop/www/careers.php&lang=fr_CI&lang=en_CI&lang=fr_CI&lang=fr_CI&lang=fr_CI&lang=fr_CI&lang=en_CI&lang=fr_CI&lang=fr_CI&lang=en_CI&lang=en_CI&lang=en_CI&lang=en_CI&lang=fr_CI&devise=XOF&lang=fr_CI&lang=fr_CI&devise=XOF&lang=en_CI&lang=fr_CI&devise=EUR&lang=fr_CI&devise=XOF&devise=EUR&devise=EUR&devise=XOF&lang=en_CI&lang=en_CI&devise=EUR&devise=XOF&lang=en_CI&devise=EUR&devise=XOF&lang=fr_CI&devise=XOF&devise=EUR&devise=USD&devise=USD&devise=USD&lang=en_CI&devise=EUR&devise=EUR&devise=XOF&lang=en_CI')Also, the same problem arises on a file that does not exist either.
I thought create a file of the same name can correct the problem while making a redirect to the official page, but no, the problem persists yet this page has not been in more than a year.
[Thu Jul 04 11:56:24 2019] [error] [client 66.249.70.4] [host sivop.com] (36)File name too long: AH00036: access to /careers.php&lang=fr_CI&lang=en_CI&lang=fr_CI&lang=fr_CI&lang=fr_CI&lang=en_CI&lang=fr_CI&lang=fr_CI&lang=fr_CI&lang=en_CI&lang=en_CI&lang=en_CI&lang=fr_CI&lang=en_CI&lang=en_CI&lang=en_CI&lang=en_CI&lang=fr_CI&lang=en_CI&lang=en_CI&lang=en_CI&lang=fr_CI&lang=en_CI&lang=en_CI&lang=fr_CI&lang=fr_CI&lang=en_CI&devise=USD&lang=fr_CI&devise=XOF&lang=en_CI&lang=en_CI&devise=USD&lang=fr_CI&lang=en_CI&lang=en_CI&lang=en_CI&devise=XOF&devise=XOF failed (filesystem path '/homez.520/sivop/www/careers.php&lang=fr_CI&lang=en_CI&lang=fr_CI&lang=fr_CI&lang=fr_CI&lang=en_CI&lang=fr_CI&lang=fr_CI&lang=fr_CI&lang=en_CI&lang=en_CI&lang=en_CI&lang=fr_CI&lang=en_CI&lang=en_CI&lang=en_CI&lang=en_CI&lang=fr_CI&lang=en_CI&lang=en_CI&lang=en_CI&lang=fr_CI&lang=en_CI&lang=en_CI&lang=fr_CI&lang=fr_CI&lang=en_CI&devise=USD&lang=fr_CI&devise=XOF&lang=en_CI&lang=en_CI&devise=USD&lang=fr_CI&lang=en_CI&lang=en_CI&lang=en_CI&devise=XOF&devise=XOF')I do not know what to do, I have untimely disconnection at peak times and ... well here I need your help please!
Note: This has nothing to do with Google, as your tags suggest.
This problem relates to Apache, based on the error code AH00036 listed in your initial question.
Added the Apache Web Server tag, to this question.
This problem relates to Apache, based on the error code AH00036 listed in your initial question.
Added the Apache Web Server tag, to this question.
ASKER
Thank you for your answer, however as I said earlier, ?lang=fr_CI&... no longer exists and careers.php no longer exists either.
the domain is sivop.com but there is no more ?lang=fr_CI&... or &lang=fr_CI&.... and the page careers.php no longer exists.
I do not understand why the problem persists to appear in the error logs ... you follow me?
the domain is sivop.com but there is no more ?lang=fr_CI&... or &lang=fr_CI&.... and the page careers.php no longer exists.
I do not understand why the problem persists to appear in the error logs ... you follow me?
You're missing the problem.
1) I said earlier, ?lang=fr_CI&... no longer exists and careers.php no longer exists either.
If your site is generating this URL, you must fix this.
2) Might be someone is attacking your site also. I've seen attacks similar to this over the past few months.
If someone is attacking your sites with this type of attack, you'll generate a setup of Rewrite rules to either strip off bogus query parameters sent or return a 404 error to attackers.
Either approach will work.
3) page careers.php no longer exists.
Makes no difference.
Anyone can craft any URL with any file name along with bogus query parameters.
This has nothing to do with you.
Refer to #2 about how to fix crafted attacks.
4) I do not understand why the problem persists to appear in the error logs
Because a bad URL is either cached somewhere like Google... or...
Some attacker is sending crafted attack URLs to your site.
Either way, see #2 about how to fix this.
1) I said earlier, ?lang=fr_CI&... no longer exists and careers.php no longer exists either.
If your site is generating this URL, you must fix this.
2) Might be someone is attacking your site also. I've seen attacks similar to this over the past few months.
If someone is attacking your sites with this type of attack, you'll generate a setup of Rewrite rules to either strip off bogus query parameters sent or return a 404 error to attackers.
Either approach will work.
3) page careers.php no longer exists.
Makes no difference.
Anyone can craft any URL with any file name along with bogus query parameters.
This has nothing to do with you.
Refer to #2 about how to fix crafted attacks.
4) I do not understand why the problem persists to appear in the error logs
Because a bad URL is either cached somewhere like Google... or...
Some attacker is sending crafted attack URLs to your site.
Either way, see #2 about how to fix this.
ASKER
When you say security rule, are you referring to .htaccess containing this code?
Because I have it in my .htaccess for a long time this code there!
Because I have it in my .htaccess for a long time this code there!
ErrorDocument 400 /404.php
ErrorDocument 401 /404.php
ErrorDocument 402 /404.php
ErrorDocument 403 /404.php
ErrorDocument 404 /404.php
ErrorDocument 405 /404.php
ErrorDocument 500 /404.php
ErrorDocument 501 /404.php
ErrorDocument 502 /404.php
ErrorDocument 503 /404.php
ErrorDocument 504 /504.php
ErrorDocument 505 /404.php
The above will solve your problem if your site has little to no traffic.
If you have high traffic, the above will likely cause your site to crash quickly + badly.
If you have high traffic, you'll write RewriteRule sets which match broken URLs, then take some action.
In my case, what I do for high traffic clients is block this traffic, so once first malformed URL arrives, then the IP generating the request is blocked for 1 hour.
You can only use this harsh approach if you're sure this traffic is attack traffic.
If you actually cause malformed links to be listed by... say... Google... then best to capture these malformed URLs + return your home page for them all (via a 302 redirect).
If you have high traffic, the above will likely cause your site to crash quickly + badly.
If you have high traffic, you'll write RewriteRule sets which match broken URLs, then take some action.
In my case, what I do for high traffic clients is block this traffic, so once first malformed URL arrives, then the IP generating the request is blocked for 1 hour.
You can only use this harsh approach if you're sure this traffic is attack traffic.
If you actually cause malformed links to be listed by... say... Google... then best to capture these malformed URLs + return your home page for them all (via a 302 redirect).
ASKER
I feel that I am not far from the light with these explanations but the tunel is tight and I will not be able to do it alone.
Do you have a documentation or a link to correct this kind of vp rules?
Do you have a documentation or a link to correct this kind of vp rules?
The approach I take is simple, just requires a large amount of experimenting time.
1) Analyze log data.
2) Find problems.
3) Determine best fix.
4) Experiment with mod_rewrite, sometimes coupled with Fail2Ban, till a workable fix is found.
You'll just have to dig into all the steps above, to find a solution.
Was just trying to find an example of one of these fixes + can't find one right now.
If I find an example, I'll add it as a comment.
1) Analyze log data.
2) Find problems.
3) Determine best fix.
4) Experiment with mod_rewrite, sometimes coupled with Fail2Ban, till a workable fix is found.
You'll just have to dig into all the steps above, to find a solution.
Was just trying to find an example of one of these fixes + can't find one right now.
If I find an example, I'll add it as a comment.
ASKER
Sorry for the delay, I followed your advice 1.
1) Log analysis has shown that the generated code is never the same. The $ lang ... are random.
However, a google search of the link: sivop.com/careers.php
which does not exist any more "more" on the site is found in the results with the & lang = .....
2) Did I find the problem? I do not know.
In any case I maintain the fact that careers.php no longer exists on the site and the generation of & lang = and? Lang = are no longer part of my system.
3/4) 301 or 302, I tried to follow your advice by adding a 302 redirect but limited to the direct link and not to the link with the & lang =
Which of these redirects is the most appropriate and will it solve the problem?
1) Log analysis has shown that the generated code is never the same. The $ lang ... are random.
However, a google search of the link: sivop.com/careers.php
which does not exist any more "more" on the site is found in the results with the & lang = .....
2) Did I find the problem? I do not know.
In any case I maintain the fact that careers.php no longer exists on the site and the generation of & lang = and? Lang = are no longer part of my system.
3/4) 301 or 302, I tried to follow your advice by adding a 302 redirect but limited to the direct link and not to the link with the & lang =
RewriteEngine on
RewriteRule "^carrieres\index.php$" "carrieres.php" [R]
RewriteRule "^careers.php$" "carrieres.php" [R]
Redirect /carrieres/index.php https://www.sivop.com/carrieres.php
Redirect /carrieres/careers.php https://www.sivop.com/carrieres.php
Redirect /careers.php https://www.sivop.com/carrieres.phpWhich of these redirects is the most appropriate and will it solve the problem?
Attach a copy of recent 10 days of log files.
Best to get an idea of exactly what's going on, for best fix.
Best to get an idea of exactly what's going on, for best fix.
Be sure to highly compress the log files, as they'll likely be large.
ASKER
I just downloaded the last 10 days, all compressed in .gz, and then I grouped everything into one archive.
Thank you really for the help.
by the way, the redirection I made on my .htaccess redirected the link from google to a page 403 ...
Do I have to delete everything or do I have to keep these lines?
sivop.com.log.rar
Thank you really for the help.
by the way, the redirection I made on my .htaccess redirected the link from google to a page 403 ...
Do I have to delete everything or do I have to keep these lines?
sivop.com.log.rar
Just did a grep + sort -u + wc -l across your log files.
There are 25x IPs hitting these links. The few I checked are all GoogleBot. This is true across your entire log set, running across 10x days.
This suggests these links exists somewhere GoogleBot can find them, like in some sitemap.xml file or some page of content.
So fix is...
1) Ignore all these errors.
2) Fix however GoogleBot is finding these errors, which is likely a sitemap file or some content page where these broken URLs are listed.
Once you fix #2, GoogleBot will eventually stop indexing the broken URLs.
3) Since you appear to be using OVH hosting, this means you likely have root ssh access into your machine.
If you get stumped, be very easy to hire someone to find + fix the problem. Having root ssh access will likely be fastest way to find + fix this particular problem.
There are 25x IPs hitting these links. The few I checked are all GoogleBot. This is true across your entire log set, running across 10x days.
This suggests these links exists somewhere GoogleBot can find them, like in some sitemap.xml file or some page of content.
So fix is...
1) Ignore all these errors.
2) Fix however GoogleBot is finding these errors, which is likely a sitemap file or some content page where these broken URLs are listed.
Once you fix #2, GoogleBot will eventually stop indexing the broken URLs.
3) Since you appear to be using OVH hosting, this means you likely have root ssh access into your machine.
If you get stumped, be very easy to hire someone to find + fix the problem. Having root ssh access will likely be fastest way to find + fix this particular problem.
ASKER
I thank you very much for your help and the time you had to solve my problem.
You guided me to the right path.
I run to check my sitemap generator, now I'm pretty sure the problem is already there.
I close this subject because all that you said will be enough for me to solve the problem.
Thank you again for your help.
You guided me to the right path.
I run to check my sitemap generator, now I'm pretty sure the problem is already there.
I close this subject because all that you said will be enough for me to solve the problem.
Thank you again for your help.
You're welcome!
Glad you tracked this down to your sitemap file!
Glad you tracked this down to your sitemap file!
This question needs an answer!
Become an EE member today
7 DAY FREE TRIALMembers can start a 7-Day Free trial then enjoy unlimited access to the platform.
View membership options
or
Learn why we charge membership fees
We get it - no one likes a content blocker. Take one extra minute and find out why we block content.
Notice...
Open in new window
This is broken. Because &lang=fr_CI is appended as first query parameter... since this is 100% broken syntax, the entire query string is treated as a file name, which is correct.
To fix this problem fix query string production to be correct, as in...
Open in new window
So change the first occurrence of "&" (incorrect) to "?" correct + problem will resolve.
You also have query args set many times, which is a very bad idea. This means any time one of the query arg values changes, you will have no clue what will occur on the server side, because different Webservers treat multiple values differently.
Best only set each query arg name once.