I need to implement a rewrite rule for my users, this type:
https://domain/user.strike18
The problem is that using this regex, any url containing "dot" returns error.
For example
https://domain/register.php
https://domain/styles.css
So I added a dot inside the regex rule.
RewriteRule ^([#a-zA-Z0-9._-]+)$ user.php?p=profile&username=$1
RewriteRule ^([#a-zA-Z0-9._-]+)/$ user.php?p=profile&username=$1
Still not working, How do I make it work?
The issue you face is that it is impossible for the rewriting module to decide whether something like "abcde.fghi" is a user name or a file name with a "file name extension".
You could try to work around that issue by explaining the exceptions to the rewriting module, here by means of a condition that allows the application of the actual rule to only get applid of the requested path does not point to an existing file:
RewriteEngine on
RewriteCond {REQUEST_FILENAME} !-f
RewriteRule ^([#a-zA-Z0-9._-]+)/?$ user.php?p=profile&username=$1
That however has the annoying implication that this now won't work as expected for a user called for example "styles.css" ...
The issue is actually rooted not in your rewriting attempts but in how you try to publish those user profiles. You should use a unique prefix for that to prevent such unsolvable problems. So a URL like for example https://example.com/profile/user.strike18. That would obviously allow for a precise rewriting rule without any such naming collisions you currently face.
Related
I am sorry to ask this question, because the answer seemingly is so easy. However, after three hours of trial and error I am without a clue.
I have several pages on a website using parameters in the url. I would like to change that, to a more regular url. Example:
domain.com/pag.php?id=1-awesome-page should become domain.com/awesome-page
So far so good, but so far I have three problems.
1. The old page still is accessible, Google will index it as duplicated content. When I try to redirect it, I am getting infinite loop errors.
2. For whatever reason, sometimes SOME images (straight from the content) get stripped off on the newly named page. I tried playing with a base-url and renaming the images and urls, but nothing so far.
3. Also the redirect doesn't care if i'd enter id=1-awesome-page or id=2-worthless-page. It all redirects to the first one.
Among the things i've tried.
RewriteCond %{QUERY_STRING} id=1-awesome-page
RewriteRule ^pag\.php$ /awesome-page? [L,R=301]
RewriteRule ^awesome-page?$ pag\.php?id=1 [NC]
What you want to do cannot really be done with mod_rewrite, unless you want to make a rule for every page, which will probably slow your site down quite a lot. This is, because you can't summon the 1 in 1-awesome-page out of thin air, and your pag.php page doesn't seem to be able to load the page only based on it's seo name. If you need to use that number, you need to have that number somewhere in your url.
As for your questions:
The error you mention cannot be reproduced with the current iteration of your .htaccess. You likely had an infinite loop previously, and since you use R=301 to test, the browser will cache this redirect and only request the second resource afterwards when you request the first resource. You should test with [R,L] and only change to [R=301,L] when everything works as expected. Not doing so will cause weird behaviour, and behaviour you do not expect with your .htaccess.
When you have an url a and an url b, and want to redirect a to b, and want to internally rewrite b to a, you need to make sure that any given time not both rules can be matched. You can either use the %{THE_REQUEST} trick or use the END flag. Both are outlined in this answer.
If you have a problem with resources on a page not loading after making a fancy url, you likely used relative url's. This question outlines the possibilities on how to resolve this. You can either make the url's absolute or relative to the root of your site, or use <base href="/">.
The following would work for /pag.php?id=123-news-page and /news/123/news-page.
RewriteCond %{THE_REQUEST} pag\.php\?.*id=([^-]+)-([^&\s]+)
RewriteRule ^pag\.php$ /news/%1/%2? [L,R]
RewriteRule ^news/([^/]+)/([^/]+)/?$ pag.php?id=$1-$2 [L]
Tried looking via search but I couldn't find a match for this particular issue.
Needing to redirect /games/ps3/?page=2 to /ps3/games/2/. All of the approaches I've tried so far won't remove the query string and grab the page value to pass into my new URL.
A little bit new to these types of redirects as I don't work with them often, so I'm guessing it might be a RedirectRule-type approach but I'm not sure.
(Note that due to how the URLs work with other pages on the site I'm having to create the rule for each platform, i.e. I need have a separate rule for both ps3 and xbox-360. So the only variable here is the page number.)
I was thinking it might work something like
RewriteRule ^games/ps3/?page=(.*)$ /ps3/games/$1/? [L,R=301]
But I think the first ? is causing the rule to fail since the second part uses it. I tried looking online to see how to resolve that possible issue but I couldn't find anything.
Ended up messing around with the rules and got this to solve the issue:
RewriteCond %{QUERY_STRING} ^page=(.+)$ [NC]
RewriteRule ^games/ps3/$ /ps3/games/%1/? [L,R=301]
Earlier today, I was helping someone with an .htaccess use case, and came up with a solution that works but can't quite figure it out myself!
He wanted to be able to:
Browse to index.php?id=3&cat=5
See the location bar read index/3/5/
Have the content served from index.php?id=3&cat=5
The last two steps are fairly typical (usually from the user entering index/3/5 in the first place), but the first step was required because he still had some old-format links in his site and, for whatever reason, couldn't change them. So he needed to support both URL formats, and have the user always end up seeing the prettified one.
After much to-ing and fro-ing, we came up with the following .htaccess file:
RewriteEngine on
# Prevents browser looping, which does seem
# to occur in some specific scenarios. Can't
# explain the mechanics of this problem in
# detail, but there we go.
RewriteCond %{ENV:REDIRECT_STATUS} 200
RewriteRule .* - [L]
# Hard-rewrite ("[R]") to "friendly" URL.
# Needs RewriteCond to match original querystring.
# Uses "?" in target to remove original querystring,
# and "%n" backrefs to move its components.
# Target must be a full path as it's a hard-rewrite.
RewriteCond %{QUERY_STRING} ^id=(\d+)&cat=(\d+)$
RewriteRule ^index\.php$ http://example.com/index/%1/%2/? [L,R]
# Soft-rewrite from "friendly" URL to "real" URL.
# Transparent to browser.
RewriteRule ^index/(\d+)/(\d+)/$ /index.php?id=$1&cat=$2
Whilst it might seem to be a somewhat strange use case ("why not just use the proper links in the first place?", you might ask), just go with it. Regardless of the original requirement, this is the scenario and it's driving me mad.
Without the first rule, the client enters into a request loop, trying to GET /index/X/Y/ repeatedly and getting 302 each time. The check on REDIRECT_STATUS makes everything run smoothly. But I would have thought that after the final rule, no more rules would be served, the client wouldn't make any more requests (note, no [R]), and everything would be gravy.
So... why would this result in a request loop when I take out the first rule?
Without being able to tinker with your setup, I can't say for sure, but I believe this problem is due to the following relatively arcane feature of mod_rewrite:
When you manipulate a URL/filename in per-directory context mod_rewrite first rewrites the filename back to its corresponding URL (which is usually impossible, but see the RewriteBase directive below for the trick to achieve this) and then initiates a new internal sub-request with the new URL. This restarts processing of the API phases.
(source: mod_rewrite technical documentation, I highly recommend reading this)
In other words, when you use a RewriteRule in an .htaccess file, it's possible that the new, rewritten URL maps to an entirely different directory on the filesystem, in which case the .htaccess file in the original directory wouldn't apply anymore. So whenever a RewriteRule in an .htaccess file matches the request, Apache has to restart processing from scratch with the modified URL. This means, among other things, that every RewriteRule gets checked again.
In your case, what happens is that you access /index/X/Y/ from the browser. The last rule in your .htaccess file triggers, rewriting that to /index.php?id=X&cat=Y, so Apache has to create a new internal subrequest with the URL /index.php?id=X&cat=Y. That matches your earlier external redirect rule, so Apache sends a 302 response back to the browser to redirect it to /index/X/Y/. But remember, the browser never saw that internal subrequest; as far as it knows, it was already on /index/X/Y/. So it looks to you as though you're being redirected from /index/X/Y/ to that same URL, triggering an infinite loop.
Besides the performance hit, this is probably one of the better reasons that you should avoid putting rewrite rules in .htaccess files when possible. If you move these rules to the main server configuration, you won't have this problem because matches on the rules won't trigger internal subrequests. If you don't have access to the main server configuration files, one way you can get around it (EDIT: or so I thought, although it doesn't seem to work - see comments) is by adding the [NS] (no subrequest) flag to your external redirect rule,
RewriteRule ^index\.php$ http://example.com/index/%1/%2/? [L,R,NS]
Once you do that, you should no longer need the first rule that checks the REDIRECT_STATUS.
The solution below worked for me.
RewriteEngine on
RewriteBase /
#rule1
#Guard condition: only if the original client request was for index.php
RewriteCond %{THE_REQUEST} ^[A-Z]{3,9}\ /index\.php [NC]
RewriteCond %{QUERY_STRING} ^id=(\d+)&cat=(\d+)$ [NC]
RewriteRule . /index/%1/%2/? [L,R]
#rule 2
RewriteRule ^index/(\d+)/(\d+)/$ /index.php?id=$1&cat=$2 [L,NC]
Here is what I think is happening
From the steps you quoted above
Browse to index.php?id=3&cat=5
See the location bar read index/3/5/
Have the content served from index.php?id=3&cat=5
At Step 1, Rule 1 matches and redirects to location bar and fulfills Step 2.
At Step 3, Rule 2 now matches and rewrites to index.php.
The rules are rerun, for the reasons David stated, but since THE_REQUEST is immutable once set to the original request, it still contains /index/3/5 so Rule 1 does not match.
Rule 2 does not match either and the result of index.php is served.
Most other variables are mutable e.g. REQUEST_URI. Their modification during rule processing, and the incorrect expectation that the pattern matches are against the original request is a common reason for infinite loops.
Its feels quite esoteric sometimes, but I am sure there is a logical reason for its complexity :-)
EDIT
Surely there are two distinct requests
There are 2 client requests, the original one from Step1 and the one from the external redirect in step 2.
What I glossed over above is that when Rule 2 matches on the second request, it is rewritten to /index.php and causes an internal redirect. This forces the .htaccess file for / directory to be loaded again (it could easily have been another another directory with different .htaccess rules) and Re-run all the rules again.
So... why would this result in a request loop when I take out the first rule?
When the rules are re-run, the first rule now unexpectedly matches, as a result of Rule2's rewrite, and does a redirect, causing an infinite loop.
David's answer does contain most of this information and is what I meant "for the reasons David stated".
However, the main point here is that you do need the extra condition, either your condition, which stops further rule processing on internal redirects, or mine, which prevents rule 1 from matching, is necessary to prevent the infinite loop.
I want to create functionality similar to the site downforeveryoneorjustme.com. They use a pretty URL to take in the URL of any given site. I sure they use htaccess to do this, however the method i'm using is encountering problems.
This is my .htaccess file that I'm using to send the site URL to a file.php:
RewriteEngine on
RewriteCond %{SCRIPT_FILENAME} !-f
RewriteCond %{SCRIPT_FILENAME} !-d
RewriteRule ^(.+)?$ /file.php?var=$1
However when I type in something like
mysite.com/http://google.com the variable it sends the file is http:/google.com (missing a slash). I can't figure out why this is occurring.
Also, when I type in something like mysite.com/existingfolder, where existingfolder is a folder on my site, it always works incorrectly. The variable it passes to the file is missing.html instead of existingfolder. In this case, the file doesn't display images. The image can't be found, and i'm assuming its because it's searching for the image in an incorrect folder on the site. That it might think it's in existingfolder and not in the normal folder it should be in.
Does anyone know why I'm getting these problems? I'm knew to htaccess, and I'm assuming it has something to do with that.
Thanks for any help.
I sure they use htaccess to do this
I'm not. I'm not even sure they're using Apache.
mod_rewrite is not always the answer to all URL-processing problems. It's certainly prone to some of the quirks of path-based URL handling, including the removal of double-slashes.
I suggest reading the Apache-specific REQUEST_URI variable from your script, rather than relying on rewrites to get a parameter. This will give you the path requested by the browser without any processing.
trying to figure out how to rewrite this url clientside
blog.com/post/how-to-get-the-ladies
to point serverside to
blog.com/post.php?id=123
i know how to do this:
blog.com/post/123
RewriteRule ^([^/]+)/?$ post.php?id=$1 [NC,L]
but how do you replace the id string with the post title slug?
The webserver itself doesn't make this distinction and cannot translate from your "unique text identifier" to the database id. Therefore a .htaccess rule alone evaluated by the webserver will not help you. But how is it done on all those web-applications? Normally this translation is done by Joomla/Wordpress itself and it only works as long the "how_to_get_the_ladies" text is known and unique throughout the system/database.
you can add rule that go to index file like :
RewriteRule ^(.*)$ index.php?url=$1
and in this file according to the title you can show the post that request
I solved a similar problem recently. I would suggest looking into the RewriteMap directive and using an 'External Rewriting Program'.
There are some big limitations with RewriteRule in terms of maintainability and robustness. If you haven't gotten there yet you may eventually. Only simple rewriting rules can be written safely.
With a rewriteMap you can create a php or perl script, take advantage of your existing code base, and perform all the rewriting rules from a localized place in your code which easily sits in version control.
I believe you need access to the httpd.conf (or vhost) configuration file though, RewriteMaps (or some related directive) cannot be put in .htaccess files.