I would have thought I'd find a TON of stuff out there about how to do this, but everything I try puts me into a redirection loop that causes the browser to eventually give up. I need to temporarily redirect all traffic to a site to the homepage of that site. Essentially:
RedirectMatch 302 /.* http://mysite.com
Let's chalk it up to the national holiday or working on a Sunday morning, but I can't find right solution to capture all traffic to any location within the site and redirect it to the homepage. I know I'm missing something obvious, but it's lingering in my blind spot...
Thanks.
Final solution:
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule !^/index\.php.+$ / [QSA,L,R=302]
How about something like
RewriteEngine on
RewriteRule ^/(.+)$ http://mysite.com [L,R=302]
This is a fancier form for similar rule. Also, + stands for "one or more" while your * stands for "zero or more".
Related
Moved from https://serverfault.com/questions/1013461/cant-use-parentheses-in-rewritecond-query-string because it's on topic here.
I need to capture a UID from an old url and redirect it to a new format.
example.com/?uid=123 should redirect to example.com/user/123
What should work:
RewriteCond %{QUERY_STRING} ^uid=(\d+)$
RewriteRule ^$ /user/%1? [L]
This does not redirect at all.
However, this does:
RewriteCond %{QUERY_STRING} ^uid=\d+$
RewriteRule ^$ /user/%1? [L]
It goes to example.com/user. The UID is left out, but it DOES redirect.
Notice: All I did was remove the parentheses in the second example.
Why is this?? How can I match the query AND capture the value of UID?
Updates
This is a laravel app. I've discovered that the redirects I did see may have been coming from the app, not Apache.
Self-answer coming soon...
Temporarily adding R=302 gives the desired result:
RewriteCond %{QUERY_STRING} ^uid=(\d+)$
RewriteRule ^$ /user/%1? [L,R=302]
This, of course, sends a 302 redirect to /users/123. I'd like to see if this can be done with an internal rewrite though...
Here are some rules in laravel's default .htaccess:
# Handle Front Controller...
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^ index.php [L]
This catches paths that do not point to real files, and it points them to the laravel app. When this is removed, Apache responds with a 404 for /users/1234.
https://httpd.apache.org/docs/2.4/rewrite/flags.html#flag_l
Such a rewrite goes back to Apache's URL parser. Then the .htaccess is processed again (since it's still applicable to this new URL). At this point, I'd expect the above rules to pick up the non-existent path and point it to the laravel app...
Found it. Writing an answer now.
The Answer
MrWhite was right. You have to add R=302 or R=301 to perform a redirect. An plain ol' rewrite won't work.
RewriteCond %{QUERY_STRING} ^uid=(\d+)$
RewriteRule ^$ /user/%1? [L,R=302]
The Reason
So, the way Laravel works is:
you request /some/file
.htaccess tells apache, "hey apache, if you have a request for a file that doesn't exist just pretend it's for index.php"
apache says, "hey php, I have a request to run index.php and the url is /some/file"
php runs the script which --whoah-- is a huge laravel application
whatever, "hey laravel, the server said /some/file is the url"
laravel does all it's fancy stuff, and it tries to match the url to one of your routes
Now, I added a rule to rewrite a certain URL to a virtual URL that Laravel should handle. I was matching against query parameters, but that was irrelevant. (see below for details)
When Apache's Rewrite Module hits a RewriteRule without an [R] flag, it rewrites the URL and sends it back to the URL Handler. Apache's URL Handler then processes the new URL against all the rules, including those in any applicable .htaccess files.
So all the proper rules did get applied.
Here's the key revelation:
The originally requested URL never changed. So while Apache was able to pass the request to PHP with the correct file, it was also sending along the old URL.
Therefore, we have to tell Apache to send a 301 or 302 Redirect response, instead of just rewriting the request. The user will send another request with the URL that Laravel needs to resolve the route.
But what about the different behavior with/without the parentheses?
The answer lies within Laravel's default .htaccess. Let's take a look my old rules without the parentheses:
RewriteCond %{QUERY_STRING} ^uid=\d+$
RewriteRule ^$ /user/%1? [L]
Without the parenthesis to grab the uid value, %1 is empty. So we end up rewriting the URL to just /user/.
Now, we have to look at another set of Laravel rules:
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)/$ /$1 [L,R=301]
This normalizes urls so that virtual paths/routes don't contain trailing slashes. Doing this makes route parsing easier.
This returns a 301 Redirect to `/users'. This is very different from the 200 we were getting with the parentheses, but it does not mean the parentheses were behaving differently. As MrWhite said in the comments, surely something else was doing it.
I hope you enjoyed the ride. And I hope even more that this will save some poor, confused soul from hours of torment. :)
I have a machine I'm leasing that was assigned an IP address that must have previously been assigned to some kind of link spamming company. Said company has hundreds of domains that still resolve to the IP address of my server, and Google and the like are constantly attempting to index the site with their bots (hundreds of thousands of pages). I've been unsuccessful in getting said link spammer to change their DNS records to resolve elsewhere. Fine.
I decided I could use mod_rewrite to deal with this in a fairly direct manner: I want any request that doesn't include one of my domain names to return 410, unless the request is for /robots.txt. For the robots file I want to return a simple file that disallows everything with a 200. By my thinking I can quickly extinguish the bots and return to normal.
My mod_rewrite configuration looks like this:
RewriteEngine On
RewriteCond %{HTTP_HOST} !^.*foo\.com$
RewriteRule ^/robots\.txt$ /robots-off.txt [L]
RewriteCond %{HTTP_HOST} !^.*foo\.com$
RewriteRule !^/robots\.txt$ - [G]
Where all of the domains I might host on this IP fall somewhere under/at the foo.com domain. So I would expect the first rule to tell Apache to output the contents of /robots-off.txt with a 200 whenever a request is made for /robots.txt for any domain other than my own.
Sadly what's happening is that every request results in a 410, so the bots never get the chance to learn why that they should stop indexing the entire site. Here is the response when I query the wrong host:
The requested resource<br />/robots-off.txt<br />
is no longer available on this server and there is no forwarding address.
Please remove all references to this resource.
This has been going on for over a week with no end in sight. The first rule is running, but the [L] seems to be ignored and the second rule is then run. I don't understand why.
OK, I misunderstood how [L] works. See here: mod_rewrite seems to ignore [L] flag
The working code looks like this:
RewriteCond %{HTTP_HOST} !^.*foo\.com$
RewriteRule ^robots\.txt$ /robots-off.txt [L]
RewriteCond %{HTTP_HOST} !^.*foo\.com$
RewriteRule !^robots-off\.txt$ - [L,G]
Hope this helps somebody.
It's a bit late, but this would return a redirect to the browser, the browser would then re-request robots-off.txt this would be a new request and so again be rewritten. However if you do a pas-through then apache will return the final file inline and so no new request is made and the last is honoured in the way you expect.
RewriteCond %{HTTP_HOST} !^.*foo\.com$
RewriteRule ^robots\.txt$ /robots-off.txt [PT,L]
RewriteCond %{HTTP_HOST} !^.*foo\.com$
RewriteRule !^robots-off\.txt$ - [L,G]
I have a site built in codeigniter. We use short urls from our database & rewrite rules to redirect them to their full path.
For example,
RewriteRule ^secure-form$ form/contract/secure-form [L]
This works fine by itself. But I would like to use SSL on certain pages. I have edited the code so that if you go to one of these pages, all instances of http:// within the page are replaced with https:// but I need to rewrite the url to use it as well.
The pages all use the same template and all the content comes from the database so I can't just specify ssl on a particular directory.
The url's for the secure pages all start with 'secure' so I wrote the following rules and placed them above the other rewrites.
RewriteCond %{HTTPS} off
RewriteCond %{REQUEST_URI} ^/secure/?.*$
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]
RewriteCond %{HTTPS} on
RewriteCond %{REQUEST_URI} !^/secure/?.*$
RewriteRule ^(.*)$ http://%{HTTP_HOST}/$1 [R=301,L]
RewriteRule ^secure-form$ form/contract/secure-form [L]
RewriteRule ^secure-different-form$ form/contract/secure-different-form [L]
all other rewrite rules for specific pages follow
then the default rewrite further down...
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ index.php/$1 [L]
The problem is that when I add the rules to change the protocol, it ends up displaying 'form/contract/secure-form' in the url instead of 'secure-form'.
This renders the actual form on the page broken since it uses that url to build itself.
If I take out the rules that change the protocol, it displays secure-form in the url as it should, but the page is not secure.
What am I doing wrong?
----UPDATE----
Ooh, after over 20 hrs of searching, I think I finally have an answer. So, first time through, https is off & gets turned on. Then, because of the 301, it's run again & the page gets sent to form/contract/secure... But this time, https is on. Since the uri no longer STARTS with secure, it turns https off.
Hopefully, this will help someone else.
Just as the title states. Say an individual accesses a file from my database, http://domain.com/database/file.zip. Once that file download has been initiated, I wish the browser to be redirected to the database directory again. Here's what I have so far:
RewriteEngine On
Options +FollowSymLinks
RewriteRule ^Database(.zip)$ http://domain.com/db/index.html [R=301,L]
But, I get a 500 error.
And if I am being too picky, it would be nice to ignore this function on links such as: &file=something.zip.
Either way, getting the first portion to work would be fantastic.
Edit!
Here is what worked for me in the end. Cheers!
RewriteEngine on
RewriteCond %{REQUEST_FILENAME} .*zip$|.*rar$|.*tar$|.*txt$ [NC]
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !domain\.com [NC]
RewriteRule ^(.*)$ /dl.php?url=%{REQUEST_FILENAME} [L]
Not really possible with mod_rewrite the way you have described: once the server has started delivering content (sent a 200 status code) there is no way to initiate a second response without a corresponding second request.
If you want to do this you'll have to do it on the client side: for example launch the download targetting a separate, hidden iframe and if the download starts then you can change the page location using window.location.
I have a website build on jQuery scrollTo plugin. Each page is accessible via anchor's, ie.
www.domain.com/#page-one
and deeper
www.domain.com/#page-one--some-content.
I'd like to create rule with mod_rewrite so address like
www.domain.com/page-one
or
www.domain.com/page-one/some-content
point to the above one. Its quite easy with [R=301] flag but I need my "clean" address /page-one/some-content to stay in address bar not changing to #page-one--some-content.
Why I need to change them? Because for some reasons I need to use alternative site for MSIE and Opera, kind of regular one with reloading every page. I need the same links for both sites which is obvious, I think.
I spent lots of time digging & reading about anchors in URL's and stuff, but I haven't reach my goal. If any one can help me, I'll appreciate!
Thanks, Kuba.
Options +FollowSymlinks
RewriteEngine on
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} !^/index.php
RewriteRule (.*) /index.php#$1 [NE]
This works excellent for me.