What is tried to accomplish without success is ignoring by .htaccess any path of a domain and just transfer it to the index page, for example
the url example.com/asb , the asb will be ignored and the page that will appear will be the main index page , (while the URL still be asb if possible)
how can I do it?
Simplest and recommended way to achieve this is by using FallbackResource
FallbackResource /index.php
As per official doc:
In earlier versions of httpd, this effect typically required mod_rewrite, and the use of the -f and -d tests for file and directory existence. This now requires only one line of configuration.
Existing files, such as images, css files, and so on, will be served normally.
This probably is the easiest approach:
RewriteEngine on
RewriteCond %{REQUEST_URI} !^/index\.php$
RewriteRule ^ /index.php [END]
In case you receive an internal server error (http status 500) using the rule above then chances are that you operate a very old version of the apache http server. You will see a definite hint to an unsupported [END] flag in your http servers error log file in that case. You can either try to upgrade or use the older [L] flag, it probably will work the same in this situation, though that depends a bit on your setup.
This implementation will work likewise in the http servers host configuration or inside a dynamic configuration file (".htaccess" file). Obviously the rewriting module needs to be loaded inside the http server and enabled in the http host. In case you use a dynamic configuration file you need to take care that it's interpretation is enabled at all in the host configuration and that it is located in the host's DOCUMENT_ROOT folder.
And a general remark: you should always prefer to place such rules in the http servers host configuration instead of using dynamic configuration files (".htaccess"). Those dynamic configuration files add complexity, are often a cause of unexpected behavior, hard to debug and they really slow down the http server. They are only provided as a last option for situations where you do not have access to the real http servers host configuration (read: really cheap service providers) or for applications insisting on writing their own rules (which is an obvious security nightmare).
If the above does not show any effect, then most likely one of these issues needs to get solved:
rewriting module is not loaded into the apache http server
rewriting module is not enabled
rewriting is not permitted to the location you want it to get applied
you have implemented your rewriting rule at the wrong place
your http server is unable to read the rewriting rule
you have a syntax error in your rule set
All of these need to be tackled separately. You should start by monitoring your http server's error log file. What does it say?
Related
I updated my website, and I'm attempting to make sure a bunch of old URLs redirect to the correct page. Some of my links are working fine, while others aren't.
Example:
Redirect 301 /compare-suites/ /en/our-products/compare-suites
Redirect 301 /compare-suites/?lang=fr /fr/nos-produits/comparaison-des-suites/
The first redirect works perfectly, but the second one redirects to /en/our-products/compare-suites?lang=fr, ignoring my second rule.
The alias module which offers the Redirect directive is unable to handle the query string inside a URL. That is clearly stated in the documentation. Along with the hint to use the rewriting module instead.
I strongly recommend that you start reading the documentation of the utilities you use:
Alias module: https://httpd.apache.org/docs/current/mod/mod_alias.html
Rewrite Module: http://httpd.apache.org/docs/current/mod/mod_rewrite.html
As typical for OpenSource they are of excellent quality and come with great examples.
This would be the approach you are probably looking for:
RewriteEngine on
RewriteCond %{QUERY_STRING} (^|&)lang=fr(&|$)
RewriteRule ^/?compare-suites/?$ /fr/nos-produits/comparaison-des-suites/ [QSD,R=301,END]
RewriteRule ^/?compare-suites/?$ /en/our-products/compare-suites [R=301,END]
Note that the more specialized exception has to be implemented before the more general fallback, so further up in the configuration file.
It is a good idea to start out with a 302 temporary redirection and only change that to a 301 permanent redirection later, once you are certain everything is correctly set up. That prevents caching issues while trying things out...
In case you receive an internal server error (http status 500) using the rule above then chances are that you operate a very old version of the apache http server. You will see a definite hint to an unsupported [END] flag in your http servers error log file in that case. You can either try to upgrade or use the older [L] flag, it probably will work the same in this situation, though that depends a bit on your setup.
This implementation will work likewise in the http servers host configuration or inside a distributed configuration file (".htaccess" file). Obviously the rewriting module needs to be loaded inside the http server and enabled in the http host. In case you use a distributed configuration file you need to take care that it's interpretation is enabled at all in the host configuration and that it is located in the host's DOCUMENT_ROOT folder.
And a general remark: you should always prefer to place such rules in the http servers host configuration instead of using distributed configuration files (".htaccess"). Those distributed configuration files add complexity, are often a cause of unexpected behavior, hard to debug and they really slow down the http server. They are only provided as a last option for situations where you do not have access to the real http servers host configuration (read: really cheap service providers) or for applications insisting on writing their own rules (which is an obvious security nightmare).
The URL in my site is https://www.artmail.xyz/single.php?id=37
I want to make it https://www.artmail.xyz/single/37.html
I added the following line in my .htaccess:
RewriteRule ^([^/]*).html$ /single.php?id=$1 [L]
But nothing is happening. No error also.
Is it possible Mod rewrite is 'off' with my server? How can I check. Please help.
Thanks
Certainly it is possible that the rewriting module is not active:
it is an optional module that needs to be loaded into the server
you need to enable it for the specific location (check the documentation for the AllowOverride directive)
you need to use the well known RewriteEngine on initially
But more important is that your matching pattern actually matches what you want it to match:
RewriteEngine on
RewriteRule ^/?single/(\d+)\.html$ /single.php?id=$1 [END]
In case you receive an internal server error (http status 500) using the rule above then chances are that you operate a very old version of the apache http server. You will see a definite hint to an unsupported [END] flag in your http servers error log file in that case. You can either try to upgrade or use the older [L] flag, it probably will work the same in this situation, though that depends a bit on your setup.
This implementation will work likewise in the http servers host configuration or inside a dynamic configuration file (".htaccess" file). Obviously the rewriting module needs to be loaded inside the http server and enabled in the http host. In case you use a dynamic configuration file you need to take care that it's interpretation is enabled at all in the host configuration and that it is located in the host's DOCUMENT_ROOT folder.
And a general remark: you should always prefer to place such rules in the http servers host configuration instead of using dynamic configuration files (".htaccess"). Those dynamic configuration files add complexity, are often a cause of unexpected behavior, hard to debug and they really slow down the http server. They are only provided as a last option for situations where you do not have access to the real http servers host configuration (read: really cheap service providers) or for applications insisting on writing their own rules (which is an obvious security nightmare).
I am trying to create an image generator with a path that looks like a normal image path. If the image is generated on the URL http://example.com/img/gen/?v1=a&v2=b&v3=c&v4=d I want it to be accessed from this URL: http://example.com/img/gen/a/b/c/d.jpg
I am trying with this .htaccess rule:
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule ^/img/gen/([^/]*)/([^/]*)/([^/]*)/([^/]*)\.jpg$ /img/gen/?sn=$1&v=$2&ref=$3&t=$4 [L]
</IfModule>
I have trying placing the file on https://example.com/ and https://example.com/img/gen/ but nothing works.
You made a classical mistake which prevents your rule from getting applied. And though there still mighty be other issues you definitely have to understand that inside a dynamic configuration file (".htaccess") the request URL is examined as a relative path. So your pattern trying to match an absolute paths can never match.
Instead implement your rule in a more flexible way:
RewriteEngine On
RewriteRule ^/?img/gen/([^/]+)/([^/]+)/([^/]+)/([^/]+)\.jpg$ /img/gen/?sn=$1&v=$2&ref=$3&t=$4 [END]
Note the leading 11/? which makes the leading slash optional. That way your implementation will work likewise in the http servers host configuration or inside a dynamic configuration file (".htaccess" file). Obviously the rewriting module needs to be loaded inside the http server and enabled in the http host. In case you use a dynamic configuration file you need to take care that it's interpretation is enabled at all in the host configuration and that it is located in the host's DOCUMENT_ROOT folder.
In case you receive an internal server error (http status 500) using the rule above then chances are that you operate a very old version of the apache http server. You will see a definite hint to an unsupported [END] flag in your http servers error log file in that case. You can either try to upgrade or use the older [L] flag, it probably will work the same in this situation, though that depends a bit on your setup.
And a general remark: you should always prefer to place such rules in the http servers host configuration instead of using dynamic configuration files (".htaccess"). Those dynamic configuration files add complexity, are often a cause of unexpected behavior, hard to debug and they really slow down the http server. They are only provided as a last option for situations where you do not have access to the real http servers host configuration (read: really cheap service providers) or for applications insisting on writing their own rules (which is an obvious security nightmare).
Website: example.com
Link with GET parameter is sent to user through email: example.com/click?var=1a2b3c (<= random hash)
When the user clicks the link "example.com/click?var=1a2b3c", he should be redirected to "example.com/admin/click.php?var=1a2b3c" where a function processes the GET parameter. The redirected URL should not be displayed and stay "example.com/click?var=1a2b3c".
Who can help me out with the code for the .htaccess file?
Sound like you do not want a redirection at all, but an internal rewrite:
RewriteEngine on
RewriteCond %{QUERY_STRING} ^var=[a-z0-9_]+$
RewriteRule ^/?click$ /admin/click.php?%{QUERY_STRING} [END]
In case you receive an internal server error (http status 500) using the rule above then chances are that you operate a very old version of the apache http server. You will see a definite hint to an unsupported [END] flag in your http servers error log file in that case. You can either try to upgrade or use the older [L] flag, it probably will work the same in this situation, though that depends a bit on your setup.
This rule will work likewise in the http servers host configuration or inside a dynamic configuration file (".htaccess" file). Obviously the rewriting module needs to be loaded inside the http server and enabled in the http host. In case you use a dynamic configuration file you need to take care that it's interpretation is enabled at all in the host configuration and that it is located in the host's DOCUMENT_ROOT folder.
And a general remark: you should always prefer to place such rules in the http servers host configuration instead of using dynamic configuration files (".htaccess"). Those dynamic configuration files add complexity, are often a cause of unexpected behavior, hard to debug and they really slow down the http server. They are only provided as a last option for situations where you do not have access to the real http servers host configuration (read: really cheap service providers) or for applications insisting on writing their own rules (which is an obvious security nightmare).
URL /%variable1%/plan/%variable2%/ need redirect to /%variable1%/
I tried:
RewriteRule ^([^/]+)/?(.*) /$1/plan/$2 [L]
Returns a 500 error
Please tell me how to do it in Apache
Your question is a bit vague, but this should do what you actually ask:
RewriteEngine on
RewriteRule ^/?([^/]+)/plan/[^/]+/?$ /$1/ [R=301,END]
I am not convinced though that this is what you really want to achieve, since it is uncommon and you will actually lose the information held in what you referred to as "variable2".
It is a good idea to start out with a 302 temporary redirection and only change that to a 301 permanent redirection later, once you are certain everything is correctly set up. That prevents caching issues while trying things out...
In case you receive an internal server error (http status 500) using the rule above then chances are that you operate a very old version of the apache http server. You will see a definite hint to an unsupported [END] flag in your http servers error log file in that case. You can either try to upgrade or use the older [L] flag, it probably will work the same in this situation, though that depends a bit on your setup.
This rule will work likewise in the http servers host configuration or inside a dynamic configuration file (".htaccess" file). Obviously the rewriting module needs to be loaded inside the http server and enabled in the http host. In case you use a dynamic configuration file you need to take care that it's interpretation is enabled at all in the host configuration and that it is located in the host's DOCUMENT_ROOT folder.
And a general remark: you should always prefer to place such rules in the http servers host configuration instead of using dynamic configuration files (".htaccess"). Those dynamic configuration files add complexity, are often a cause of unexpected behavior, hard to debug and they really slow down the http server. They are only provided as a last option for situations where you do not have access to the real http servers host configuration (read: really cheap service providers) or for applications insisting on writing their own rules (which is an obvious security nightmare).