I've looked everywhere to find the proper solution/method but I can't seem to find anything that works for me.
I even asked friends and they helped but none prevailed.
What i'm trying to do is, changing the URL displayed in the browser but only that. (No rediraction, page re-loading).
I want to do this to make my UCP just cleaner looking when going through certain pages/files.
What am I trying to achieve?
Heres an example on a profile, the URL would be:
mysite.com/ucp/profile.php?player=Heartfire
However, I want it to look like
mysite.com/ucp/profile/heartfire
Or something else! I just want to get rid of the parameters AFTER the .PHP
I've tried various examples found with google and this website but none seems to work, could somebody please guide me along the way to achieve the result.
what have I tried so far?
Here are a few examples of what I tried before:
RewriteRule ^profile/([0-9]+)/?$ /ucp/profile.php?player=$1
RewriteRule profile.php?player=$1 profile.php [NC,L]
RewriteRule ^profile$ profile.php?player=$1
So what am I doing wrong that it isn't working?
Put the following in .htaccess file inside website's root directory:
RewriteEngine On
RewriteCond %{THE_REQUEST} ^GET\ /ucp/profile\.php?([^=]+)=(\S+) [NC]
RewriteRule ^ucp/profile\.php$ /ucp/%1/%2? [R=301,L,NC]
# Now, deal with internal rewrites (which will not cause redirection):
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^ucp/([^/]+)/([^/]+)/?$ /ucp/profile.php?$1=$2 [NC,L]
You can use internal redirects what will not change your url but map your request as your wanted.
What you want is impossible because:
Htaccess and rewrite is at server side. The request arrived to the server, need to rewrite at serverside and you need to change it in the clients url bar.
To achieve this the server should send a redirect with the url what you expected. This ia why redirect is mandatory. Server can't rewrite clients urls, just can send a redirect response.
Internal redirect can simulate you something like the request was what you expected but it is transparent at for the clients.
Btw, permanent redirect is the right solution here to notify the user and give the chance to let them know the resource has been changed and update the bookmark / api / whatever.
Related
I've got a blog subdirectory on my website (foo.com/blog), and I'm following a tutorial that offers a brief explanation of vanity urls.
Basically, I'm trying to get it so that when the user navigates to 'foo.com/blog/xyz' the 'xyz' variable (username) redirects the user to:
foo.com/blog/profile.php?username=xyz
but still displays as:
foo.com/blog/xyz
The code in the tutorial doesn't work, so I've been relying on code in the youtube comments under it:
RewriteBase /
RewriteEngine on
RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule .* - [L]
RewriteRule ^(.*)$ http://www.foo.com/blog/profile.php?username=$1 [NC]
The problem is, when I try to navigate to 'foo.com/blog/xyz' it instead redirects to:
foo.com/blog/profile.php?username=blog/xyz
So obviously the username is being set to blog/xyz instead of xyz itself.
Likewise, if navigate to foo.com/xyz, it redirects to where it is supposed to go:
http://www.foo.com/blog/profile.php?username=xyz
But displays this url as it is instead of showing up as foo.com/blog/xyz (like how reddit shows up as reddit.com/u/username for users)
So it appears I have two problems:
1) I can't figure out how to make it so that it only does the rewrite when I navigate to foo.com/blog/xyz rather than foo.com/xyz (.htaccess is in public_html -- I tried moving it to public_html/blog but it didn't work)
2) I can't figure out how to get it to display as blog/xyz instead of blog/profile?php?username=xyz
I don't know much about apache, and I really just need to get this one piece of code right so I can continue bashing my head against the wall with the rest of the tutorial. Does anyone know what I'm doing wrong?
Well, you never mentioned in your rule set anything about how to treat that/bog part of the request path. Do it...
RewriteEngine on
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^/?blog/(.*)$ /blog/profile.php?username=$1 [L]
I also cleaned up a few other issues with the code you posted which would prevent it from working as you claim at all.
And a general hint: you should always prefer to place such rules inside the http servers (virtual) host configuration instead of using dynamic configuration files (.htaccess style files). Those files are notoriously error prone, hard to debug and they really slow down the server. They are only provided as a last option for situations where you do not have control over the host configuration (read: really cheap hosting service providers) or if you have an application that relies on writing its own rewrite rules (which is an obvious security nightmare).
I have an e-commerce site that resides in:
http://dev.gworks.mobi/
When a customer clicks on the signin link, the browser gets redirected to another domain, in order for authentication:
http://frock.gworks.mobi:8080/openam/XUI/#login/&goto=http%3A%2F%2Fdev.gworks.mobi%3A80%2Fcustomer%2Faccount%2Flogin%2Freferer%2FaHR0cDovL2Rldi5nd29ya3MubW9iaS8%2C%2F
I'm trying to rewrite http://dev.gworks.mobi/* to http://frock.gworks.mobi:8080/openam/*, without redirection.
I've tried this in the .htaccess of the dev.gworks.mobi site:
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{REQUEST_URI} ^/openam(.*)$ [NC]
RewriteRule ^(.*)$ http://frock.gworks.mobi:8080/$1 [P,L]
</IfModule>
But when I access http://dev.gworks.mobi/openam, it shows a 404 page not found page.
Can anyone help me to achieve my use case?
Try this:
RewriteEngine on
RewriteBase /
# Make sure it's not an actual file being accessed
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
# Match the host
RewriteCond %{HTTP_HOST} ^dev\.gworks\.mobi
# Rewrite the request if it starts with "openam"
RewriteRule ^openam(.*)$ http://frock.gworks.mobi:8080/$1 [L,QSA]
This will rewrite all the requests to dev.gworks.mobi/openam to frock.gworks.mobi:8080.
If you want to mask the URI in a way that it's not visible to the visitor that she's visiting the authentication app, you need to add a P flag. Please note that it needs Apache's mod_proxy module in place:
RewriteRule ^openam(.*)$ http://frock.gworks.mobi:8080/$1 [P,L,QSA]
Feel free to drop the L flag, if it's not the last rewrite rule. See RewriteRule Flags for more information.
The 404
If it's all in place and you're still getting a 404 error, make sure that the target URL is not throwing 404 errors in the first place.
Second, check if you're still getting the error with the correct referrer URI set. It might be designed in a way to throw a 404, if the referrer is not correctly set. If that's the case, which I suspect, you need to use the R flag and redirect instead of proxying the request.
Last thing that comes to my mind, some webapps are not built in a way to figure out the URI address. The host, as well as the port number, might be hard-coded somewhere in the config files. Make sure that the authentication app is able to be run from another URL without the need to edit the configs.
Test
You can test the rewriterule online:
I am trying to rewrite
/search?keyword=foobar
to
/search/foobar
without much success.
I currently have the following which seem to produce a 404:
RewriteCond %{QUERY_STRING} ^keyword=(.*)$ [NC]
RewriteRule .* /search/%1? [L,R=301]
Unless you have a resource at /search/foobar then of course you're going to get a 404. Two entirely different things are happening here. The server has a physical resource that gets served (or a script that runs) that apache knows about. If apache sees /search/foobar, it is going to look for a directory called "search" and either a directory or a file called "foobar". If it sees neither, it's going to return a 404. The other part of what's happening is the browser, completely separate from apache, sees a URL (e.g. /search/foobar) and does what it needs to do in order to request for the resource. It talks to the webserver and asks for /search/foobar.
When the request comes in, it's up to the URL-file processing pipeline to turn that into a file which points to where the resource is. If mod_rewrite takes the URL and rewrites it to /blah/blah/blah, there better be a directory called /blah/blah and a file in there called blah or else it's going to 404.
Your rules are saying, if an incoming request is for anything with the query string ?keyword=(something), then redirect the browser to /search/(something). The browser sees this, and does what it's supposed to do; it sends another request for /search/(something). Apache's going to see this and wonder what the request is all about, not knowing what the request is for, and return 404.
What you probably want is to first, handle the /search/(something) URI's
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^/?search/(.*)$ /search?keyword=$1 [L,QSA]
So when a request comes in as /search/foobar, the rewrite engine internally rewrites it to something apache can understand, /search?keyword=foobar. This internal rewrite happens entirely on the server, the browser is ignorant of it.
Now, when a form is submitted as a GET method, you'll end up with a ?keyword=(something) in the URL, and it looks like you're trying to get rid of that. So apache gets the query string, and there must be something to redirect the browser to the nicer looking URL, at which point the browser does its thing, submits a brand new request, which gets internally rewritten by the above rule back to what it should be.
RewriteCond %{THE_REQUEST} \?keyword=([^\ &]+)&?([^\ ]*)
RewriteRule ^ /search/%1?%2 [L,R=301]
I sorted it out with the following:
RewriteRule search/(.*)$ /search?keyword=$1 [L]
RewriteCond %{THE_REQUEST} \?keyword=([^\ &]+)&?([^\ ]*)
RewriteRule ^ /search/%1?%2 [L,R=301]
but not quite. Having issues where there are multiple querystrings or some other URLs containing search/ in the URL, eg. /search/css/foobar.css?version=152
Our new website does not work in IE6 and honestly we wont make it work as its <1% of our traffic. I want to serve up a page that lives on the webserver that will be served up when a user comes to the site in IE6. What would be the best way to achieve this? It would be great if someone can provide a code snippet also.
I was able to get the redirect working by using this:
RewriteCond %{HTTP_USER_AGENT} MSIE\ 6
RewriteRule ^(.*)$ /general/notsupported.html [L,R]
However, i wanted to also mask the url so if someone comes in on www.example.com/uri/querystring it will stay there but serve up a page saying "Sorry" ie6 is not supported.
Thanks in advance!
Something like this should do it:
RewriteEngine on
RewriteCond %{HTTP_USER_AGENT} whatever_the_ie6_user_agent_string_is
RewriteRule .* /path/to/your/static/page [R]
An external server (I'll call it "sub.origin.edu") redirects all traffic to my webpage. I want to take all traffic from this host, and redirect it to a different site (which I'll call "http://foo.target.edu/board/").
My .htaccess file is:
RewriteEngine On
RewriteCond ${HTTP_HOST} sub\.origin\.edu [NC]
RewriteRule ^(.*)$ http://foo.target.edu/board/ [R=302]
This doesn't seem to be working. I've confirmed (using PHP) that the host is indeed sub.origin.edu, and the .htaccess file is in the right directory, but this rule just doesn't come into effect. Any suggestions? Thanks.
(If I remove the RewriteCond, the redirect happens, so I can confirm that everything but the rewrite condition is working.)
Use this:
RewriteEngine On
RewriteCond %{HTTP_HOST} sub\.origin\.edu [NC]
RewriteRule ^(.*)$ http://foo.target.edu/board$1 [R=302]
You used the wrong substition character ($ instead of %)
I found this question while trying to complete a re-derict for specific hostnames.
This link was of great help to understand how RewriteCond and RewriteRule work.
http://httpd.apache.org/docs/2.4/rewrite/intro.html
If sub.origin.edu is doing a 3xx redirect, then the browser will issue a new request to your server using your.server.edu as the host name. So this rule will never match that. If this is the case, there's no easy way to tell where the request was redirected from.
If they're using a CNAME, Femi has the correct answer.