.htaccess URL rewrite using two parameters and one variable - .htaccess

My current project needs some cleaner urls. I got it until the ID part like http://test.com/profile/1337(additional backslash)
I want to hide the "ugly" stuff like http://test.com/profile.php?plid=1337&action=view that would appear. Users shouldn't see this.
Already tried to add some "hardcoded" params like
RewriteRule ^profile/([0-9\_]+)/history/?$ ./profile.php?plid=$1&action=history [NC,QSA]
Also tried to change [NC,QSA] to [L,QSA], [QSA,L], [NC,QSA,L] and so on.
These are my rewrite rules currently not working
RewriteRule ^profile/([0-9\_]+)/edit/?$ ./profile.php?plid=$1&action=edit [NC,QSA]
RewriteRule ^profile/([0-9\_]+)/history/?$ ./profile.php?plid=$1&action=history [NC,QSA]
And this rule is working fine
RewriteRule ^profile/([0-9\_]+)/?$ ./profile.php?plid=$1&action=view [NC,QSA]
I want to display some buttons like "history, edit" if the action is "view" (which works fine at the moment)
Expecting a working url like https://test.com/profile/1337/history
(Where $action should be 'history')
My error is currently a 404 page not found.
[Sat Sep 07 11:36:20.981057 2019] [:error] [pid 20923] [client ip:port] script '/var/www/main/hk/profile.php' not found or unable to stat

Here is a slightly modified version of your rule set. I remove the case insensivity (why should that matter?) and also the QSA flag since it is standard anyway. Using the END flag instead of L with save you a lot of hassle, if your http server supports it , more on that further down.
RewriteEngine on
RewriteRule ^/?profile/([0-9\_]+)/?$ /profile.php?plid=$1&action=view [END]
RewriteRule ^/?profile/([0-9\_]+)/view/?$ /profile.php?plid=$1&action=view [END]
RewriteRule ^/?profile/([0-9\_]+)/edit/?$ /profile.php?plid=$1&action=edit [END]
RewriteRule ^/?profile/([0-9\_]+)/history/?$ /profile.php?plid=$1&action=history [END]
Make sure you are not looking at earlier results cached on the client side. So disable your browser cache for that site or use a fresh anonymous tab for testing.
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).

Related

htaccess rewrite rule for query not working

Im having problems with the following rule
RewriteRule ^submit\?t=([^/]*)$ /index.php?escribir=$1 [L]
I want to redirect from /submit?t=word to index.php?escribir=word but its not working.
What am I doing wrong?
You cannot match a query string using a RewriteRule directive. That is documented. You need to match and capture it using a RewriteCond instead. Reason ist that the rule only matches against the path part of the URL.
RewriteEngine on
RewriteCond %{QUERY_STRING} ^t=(.*)$
RewriteRule ^/?submit/?$ /index.php?escribir=%1 [QSD,END]
The more general approach that allows for other query arguments being specified and preserves those:
RewriteEngine on
RewriteCond %{QUERY_STRING} (?:^|&)t=([^&]*)(?:&|$)
RewriteRule ^/?submit/?$ /index.php?escribir=%1 [QSA,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 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).

Apache2 force to remove .php or .html

I am searching for a few hours on how to redirect all .php files to the file without the .php.
I know there is surely a fast answer for this but I have really trouble finding it.
How can I say that if someone loads mysite.com/mysubfolder/mysecondsub/myfile.php goes to mysite.com/mysubfolder/mysecondsub/myfile?
Like a normal rewrite except the URL PHP redirects to the one without the PHP extension.
(using .htaccess if possible and mod_rewrite)
I configured Apache2.conf to allow overwrites so that I am able to use .htacess.
It works when I use something like this post htaccess remove index.php from url
But the thing is that it works if I write mysite.com/url, but if I write mysite.com/url.php it does not redirect to mysite/url (which is what I want) I tried a few solutions but still no idea.
This probably is what you are looking for:
RewriteEngine on
RewriteRule ^/?(.+)\.php$ /$1 [R=301]
RewriteCond %{REQUEST_URI} !\.php$
RewriteCond %{REQUEST_FILENAME}.php -f
RewriteRule ^/?(.+)$ /$1.php [END]
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).

URL Rewriting URL parameters

I'm trying to set a .htaccess directive to transform this :
https://www.example.com/nos-modeles?product-page=3
OR
https://www.example.com/nos-modeles?product-page=2
TO
https://www.example.com/nos-modeles/3
OR
https://www.example.com/nos-modeles/2
I've tried this, but it didn't do the job:
RewriteCond %{QUERY_STRING} ^(.*&|)product-page=\d+(?:&(.*)|)$
RewriteRule (.*) /$1 [R=302,L]
Your question is a bit unclear about what you are actually trying to do, rewriting incoming requests or redirecting existing references to "pretty URLs"...
Here is an approach that does both which actually is a typically combination:
RewriteEngine on
RewriteCond %{QUERY_STRING} (?:^|&)product-page=(\d+)(?:&|$)
RewriteRule ^/?nos-modeles/?$ /nos-modeles/%1 [R=301]
RewriteRule ^/?nos-modeles/(\d+)/?$ /nos-modeles?product-page=$1 [END]
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 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).

redirect domain to sub directory using .htaccess

My server has following directory in the web directory
/mydomain/site/
/mydomain/site/project1/
/mydomain/site/project2/
I want to point domain http://mydoman.com to site directory /mydomain/site/ and access project directories using http://mydoman.com/project1/ and http://mydoman.com/project2/
I tried following code. When I type http://mydoman.com/project1/ in the browser, it is working fine but the problem is when i type http://mydoman.com/project1 (without "/" in the end of url) the url changes to http://mydoman.com/mydomain/site/project1/
RewriteEngine On
RewriteCond %{HTTP_HOST} mydomain.com$ [NC]
RewriteCond %{REQUEST_URI} !^/mydomain/site/.*$
RewriteRule ^(.*)$ /mydomain/site/$1 [L]
what I need is when I type http://mydoman.com/project1 url should not change to http://mydoman.com/mydomain/site/project1/
also
this url should not work http://mydoman.com/mydomain/site/project1/
Not sure why you don't want to use separate host names for separate projects. That would save a lot of hassle. Like https://example.com/... and https://project1.example.com/....
But anyway, this probablyis what you are looking for:
RewriteEngine on
RewriteRule ^/?mydomain/site/(.*)$ /$1 [R=301,QSA]
RewriteRule ^/?site/(.*)$ /$1 [R=301,QSA]
RewriteRule ^/?(.*)$ /mydomain/site/$1 [END]
You also need to take care that your application logic uses clean, relatvie references and not absolute paths like /site/... or /mydomain/site/... or even full URLs like https://example.com/mydomain/site/.... But that has nothing to do with rewriting. You need to solve that directly in your application logic.
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).

Redirect URL with /?1

I have to redirect an URL with /?1 in the end, like
https://www.example.com/path/to/page/?1
to
https://www.example.com/other/path/to/page/
And I just can't find the solution. Important is to remove the ?1. I don't know why there is this ?1 in the end and what exactly it is used for but I can't change it.
Here is what I tried (and didn't work):
RewriteCond %{REQUEST_URI} path/to/page/\?1 [NC]
RewriteRule ^other/path/to/page/ [NE]
or:
RewriteRule ^/path/to/page/?$ /other/path/to/page/ [R=301,L]
THe reason why your attempt fails is that the "1" is not part of the URL, but of the query string. So this will probably work for you:
RewriteEngine on
RewriteCond %{QUERY_STRING} ^1$
RewriteRule ^/?path/to/page/?$ /path/to/page/ [END,QSD]
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).

Resources