I am not .htaccess expert, however over time I've built one from various posts that works.
This section
RewriteEngine on
RewriteCond %{REQUEST_FILENAME} !-s
RewriteRule ^(.*)$ index.php?path=$1 [QSA,L]
Causes all pages go through index.php. That works fine. However, it is forcing at least one of my ajax pages to go through index.php which is not desirable. Does anyone know how I can limit this .htaccess code to only effect during the initial site visit and not ajax loads ?
Thanks.
Why not just make the AJAX request to a regular file (with size)? This way, the %{REQUEST_FILENAME} !-s condition will fail and the rewrite rule will not be used.
Otherwise, you could try this to skip the rewrite if the request has the common (but not standard) X-Requested-With HTTP header
RewriteEngine on
RewriteCond %{REQUEST_FILENAME} !-s
RewriteCond %{HTTP:X-Requested-With} !=XMLHttpRequest
RewriteRule ^(.*)$ index.php?path=$1 [QSA,L]
I'll break it down for you below...
Most JS libraries or browsers (can't remember exactly), when sending an AJAX request, will inject an HTTP header X-Requested-With with value XMLHttpRequest. You can use HTTP headers in a RewriteCond like %{HTTP:X-Requested-With} =XMLHttpRequest to detect an AJAX request. Using != means the request is not via AJAX.
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 want to redirect any request to the root of my site to an anchor on the index. So
https://example.com/foo
Gets sent to
https://example.com/#foo
I've written this .htaccess file (it also redirects http requests to https, that part works, but is included for completeness)
RewriteEngine On
RewriteRule ^/(.*) /#$1 [NE,R=302]
RewriteCond %{HTTPS} !=on
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
Based on the discussion in this thread: mod_rewrite with anchor link this should work, but it's not matching for some reason. I tried out the rule given in that thread using this tool: http://htaccess.madewithlove.be/ and it doesn't seem to work there either.
I've tried clearing my cache and accessing in incognito mode, to no avail. Any help?
I've built an AngularJS app and it contains views that could be considered different pages but the app is a single page app as in the page doesn't reload.
I've read up on using escaped fragment URLs to redirect search engines to snapshots of pages. My issue is when I try to share a page from my app on Facebook that it returns a 404, as can be seen using Facebook's open graph debug tool.
My app has a Larvel back-end feeding to an AngularJS front-end and my htaccess looks like this to redirect spiders and Facebook to the snapshots. As far as I knew this was working but I guess it's not.
<IfModule mod_rewrite.c>
<IfModule mod_negotiation.c>
Options -MultiViews
</IfModule>
RewriteEngine On
RewriteCond %{HTTP_HOST} ^www\.(.*)$ [NC]
RewriteRule ^(.*)$ http://%1/$1 [R=301,L]
RewriteCond %{QUERY_STRING} ^_escaped_fragment_=/?(.*)$
RewriteRule ^(.*)$ /%1? [NC,PT]
# Redirect Trailing Slashes...
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)/$ /$1 [L,R=301]
# Handle Front Controller...
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^ index.php [L]
</IfModule>
My URLS are formatted to the user like: domain.com/#!/bike/id/bike+name
and the snapshot URLs are the same just without the hash bang i.e domain.com/bike/id/bike+name
I'm really stunmped on this one. Any suggestions or pointers would be greatly appreciated.
Facebook crawlers don't execute any Javascript so they won't see/have no idea about your Angular routes. What I've done in my project is I've mirrored the routes that need the open-graph tags in the back-end.
If my server gets a request for a page with og-tags it will make the necessary API calls to get the data, and attach them to the index template. If my initial request is the a page with no og-tags, I just render the regular SPA index. (I'm using HTML5 mode for urls so could be a bit different for you)
Also note that I said initial request to the server. This means that your og-tags won't change as you navigate within your SPA, they'll just be the tags of the first page you requested. This is actually a non-issue because Facebook makes individuals request to your server.
Let me know if this is unclear, I'll try to explain better.
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.