I have an .htaccess file with several lines. It does not work as expected. Mod_rewrite is enabled. RewriteLogLevel is set to 9.
The first two rules are there to forbid uris with a length more then 80 characters:
RewriteCond %{REQUEST_URI} ^.{80}
RewriteRule .* - [F]
It does not seem to get evaluated as every test url passes through and it does not generate an error either.
I also tried:
RewriteRule .{80} - [F]
But that did not do the trick either. The process ends with a 404, not a 403.
This next rule is not working either. It used to work.
RewriteRule ^(\/)?([\w]+)$ /index.php [L]
The URI /Contact was always handled by this index.php.
Whatever URL I type I get a 404. I should get a 403 or a 200. Not a 404. What am I missing?
Apache has on all directories the permission to read, write and execute and on all files the permission to read and write.
The two urls for testing are:
127.0.0.4/asssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssddddddddddddddddddddd?p=s&s=psv
and
127.0.0.4/Contact
The alias for 127.0.0.4 used is considerate.lb.
Try this rule instead:
RewriteCond %{THE_REQUEST} ^[A-Z]{3,}\s/+\S{80}
RewriteRule ^ - [F]
Using THE_REQUEST instead of REQUEST_URI as that variable might get overwritten due to presence of other rules in your .htaccess
Finally I have found a solution. The problem was not in the coding of the .htaccess. I replaced the file with a previous version, added the new lines to test the request and it worked all fine.
It is not a satisfactory solution, because it can happen again and I do not have any clue what caused the error. If someone knows the error, I would love to hear what might have been the exact cause and how to solve that properly. I would like to change the tags of the question as the current tags might be misleading (although other people might experience the same problem how apache handles a .htaccess file), but I do not know which tags I should use.
Related
For files in several subdirectories of /data/, I would like to treat them (and the files inside them) as if they were in the root directory.
So,
1) a request to
/data/foobar/file.png
should redirect the browser to
/foobar/file.png
2) any requests to
/foobar/file.png
should respectively deliver the file /data/foobar/file.png, but without redirection.
For 1) I got the following rule working
:
RewriteCond %{REQUEST_URI} ^(.*)?data/((foobar|and|some|other|subdirs)/.*)$
RewriteRule .* %1%2 [R=301,L,qsappend]
(I took this approach usind a RewriteCond with %x references in order to be subdirectory-agnostic, as in my dev environment the page is located in a subdirectory as opposed to the live system where it's in the root of the domain.)
And for 2) the following rule does the trick:
RewriteRule ^((foobar|and|some|other|subdirs)/.*)$ data/$1 [L,qsappend]
However, these rules only work if I enable one at a time. If I enable both of them at the same time, the browser will abort the request with a "too many redirects" error. The redirect from /data/* to /* will work, but then end in the aborted request just the same as calling the URL without /data/*.
I'm having a hard time understanding why this is happening. It would be totally logical if both rules actually triggered a redirect. But as far as my understanding of htacccess goes (and the Network tab of the dev console seems to confirm that conception), the client shouldn't even know for case 2) that the file is not actually there. So why does this apparently still count towards the redirection limit?
Is there something fundamental I'm missing? And how can I achieve what I'm trying to achieve?
This is because you first redirect and then rewrite the same Uri . Your second rule is conflicting with with the first one.
You need to match against %{THE_REQUEST} instead of %{REQUEST_URI} to avoid the redirect loop
RewriteCond %{THE_REQUEST} \s(.*)?data/((foobar|and|some|other|subdirs)/.*)\s
RewriteRule .* %1%2 [R=301,L,qsappend]
RewriteRule ^((foobar|and|some|other|subdirs)/.*)$ data/$1 [L,qsappend]
I'm getting inconsistent results with what appears to me to be the exact same redirect. Can anyone see what I'm missing?
Here's my .htaccess file. You can see where I'm trying to redirect all of the contents of 3 directories to my file_not_found page.
The problem is that only one of the directories is redirecting properly. By "properly" I mean, that it shows in the browsers url bar that it's displaying www.hhoprofessor.com/file_not_found.
The bak directory works, but none of the rest do. For instance see the following examples:
When I type www.hhoprofessor.com/bak/random_file_name, it redirects to www.hhoprofessor.com/file_not_found. This is the correct behavior.
When I do the same with the other 2 directories, I get the following result: Typing www.hhoprofessor.com/inc/random_file_name doesn't change in the address bar, but does correctly show the content of the file_not_found page. Same result when I try the page subdirectory.
I need them to do a full forwarding like they do for the /bak subdir. I don't get why the same directive is not operating the same way.
I've tried this in Chrome and Opera and they both have the same behavior. Apache version is 2.4.33, and this is a hosted lamp server.
ErrorDocument 404 /file_not_found
Redirect 301 /.htaccess http://www.hhoprofessor.com/file_not_found
RewriteEngine On
RewriteBase /
# Redirect directories to file_not_found.php:
RewriteRule ^inc/(.*) file_not_found [R,L]
RewriteRule ^bak/(.*) file_not_found [R,L]
RewriteRule ^pages/(.*) file_not_found [R,L]
# require www prefix
RewriteCond %{HTTP_HOST} ^hhoprofessor\.com$ [NC]
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTPS}:s on:(s)
RewriteRule ^(.*)$ http%1://www\.hhoprofessor\.com/$1 [R=301,L]
# Homepage: / redirects to http
RewriteCond %{HTTPS} on
RewriteRule ^$ http://www\.hhoprofessor\.com/ [R=301,L]
One more datum that might apply: This is an addon domain and is in a subdir to the main domain. I've added the following line to the top of the main domain's .htaccess which is supposed to stop processing anything coming to the addon domain:
RewriteCond %{HTTP_HOST} ^(www\.)?hhoprofessor\.com$
RewriteRule ^.*$ '-' [L]
In looking through that file, I just don't see how it could be affecting this situation, even if the whole main domain .htaccess were being processed.
Can anyone see what I'm missing?
If you want to debug such behavior, the first reflex to adopt is to analyze network traffic and http headers. Thanks to that, you'd have seen that both inc and pages folders end up with a 403 (Forbidden) code. You need to change permissions on those folders (and files recursively, maybe).
bak folder test output:
inc (same for pages) folder test output:
BUT, from a SEO point of view, what you're trying to do is not good. You should only keep ErrorDocument 404 /file_not_found and remove your redirect rules. It automatically sends a 404 (Not Found) code without changing the url. Quick reminder: changing the url means redirect, in your case you send a 302 (Moved Temporarily) code instead of a 404, which is not the expected behavior.
Ok, this resolved thanks to Justin's answer. Although, I'm not sure exactly why. The file permissions and ownership across all 3 directories were identical. So, I still don't know why one worked correctly and the other 2 didn't. There was no permission or ownership problem causing a 403 status code. Dirs were 755 and files were 644.
But I tried making the permissions on all 3 of these dirs 700. After that, all redirects worked as expected. But, it's counter-intuitive. The incorrect behavior was giving the status code of 403 (forbidden). And then when I changed the permissions so that the directory was indeed forbidden, then it redirected with 302. Go figure. But it works.
By the way, I would up-vote Justin's answer more if I could. The tip to analyze the status code will help me with problems in the future. I didn't know about that one.
later edit:
I've removed all redirects and I'm only using the file permissions now. I set up the 404 and 403 documents and everything works fine. It is worthy of note that using the ErrorDocument directive causes these to be sent with a 302 code. But that should be find SEO-wise as none of these are linked anywhere. All normal pages have status code 200.
We're seeing some really weird URLs in our logs and I've been told to start redirecting them.
I know of a couple of better ways to go about fixing this, but the boss wants it done this way. I apologize in advance.
We're seeing stuff like the following in our logs:
http://www.example.com/foo/bar/bla&ob=&ppg=&rpp=100&ob=&rpp=&ppg=&rpp=30&ppg=&ppg=1&rpp=10&rpp=50&ob=&ob=&ob=&rpp=40&ob=&rpp=5&rpp=30&rpp=&rpp=20&order_by=&results_per_pge=75
I've been told to 'toss some mod_rewrite rules in the .htaccess file' to take this and strip out all the ob, rpp, and ppg variables.
Now, I've found ways to strip everything out. And that wouldn't be too bad if I could leave the /foo/bar/bla in there. But I can't seem to do that. Basically, any help would be appreciated.
Try:
# strip out any params that's ob=, rpp= or ppg=
RewriteRule ^/?(.*)&ob=([^&]*)&(.*)$ /$1&$3 [L]
RewriteRule ^/?(.*)&rpp=([^&]*)&(.*)$ /$1&$3 [L]
RewriteRule ^/?(.*)&ppg=([^&]*)&(.*)$ /$1&$3 [L]
# if everything's gone, finally redirect and fix query string
RewriteCond %{REQUEST_URI} !&(ob|rpp|ppg)
RewriteRule ^/?(.*?)&(.*) /$1?$2 [L,R=301]
The problem here is that your URL:
http://www.example.com/foo/bar/bla&ob=&ppg=&rpp=100&ob=&rpp=&ppg=&rpp=30&ppg=&ppg=1&rpp=10&rpp=50&ob=&ob=&ob=&rpp=40&ob=&rpp=5&rpp=30&rpp=&rpp=20&order_by=&results_per_pge=75
has A LOT of ob=, rpp=, and ppg= in the URI. More than 10. That means you'll get a 500 internal server error if you use these rules against that URL. By default, apache has the internal recursion limit set to 10, that means if it needs to loop more than 10 times (and it will for the above URL), it'll bail and return a 500. You need to set that higher:
LimitInternalRecursion 30
or some other sane number. Unfortunately, you can't use that directive in an htaccess file, you'll need to go into server or vhost config and set it.
I need help with a URL problem I've encountered with a rewriteRule.
What I need it to do is following: example.com/en/page/page/
At the moment the following works fine: example.com/en/page/
But once it goes like "example.com/en/page/page/" I receive a 404 - page not found error even if the page in fact is located in the serverfiles.
The clue here is that I use a variable in the /en/ part of the URL (multilanguage system) and it seems that I cannot figure out how to get it to work with that included.
At the moment I have the following rewriteRule in my .htaccess file.
RewriteRule ^([^/]*)/([^/]*)/?$ index.php?lang=$1&uri=$2 [L]
Do any of you have a clue on what might work?
Best regards,
PureDarkness
You don't include anything behind the second /. You could try:
RewriteRule ^([^/]*)/(.*)$ index.php?lang=$1&uri=$2 [L]
And you can add [QSA] if you also need to get the parameters.
This is the contents of my .htaccess file:
RewriteEngine on
RewriteRule ^upload$ upload.php
RewriteRule ^/(\d+)/?.*$ /view.php?id=$1 [L]
The first rule successfully works. When I navigate to http://localhost/upload it shows the upload.php page.
The second rule however, does not. When I browse to: http://localhost/1234/some-string I get a 404 error. It's meant to show this page: http://localhost/view.php?id=1234.
Hopefully you can see what I'm trying to do with the rule, I want the last string on the end of the URL to be completely ignored, and take the 1234 as a parameter for view.php.
Can anyone spot why this isn't working? I've tried everything I can think of, but to no success. Thanks!
it will be trying to find the directory /1234/ and failing. change the / to a - and it should work
EDIT: got that completely wrong ... it's actually that you have a / at the beginning of your pattern, whereas MOD_REWRITE receives the path without the first slash.