Forum Moderators: phranque
What does it mean? I never use front page so can I get rid of it and the file it links to, in which there are more htaccess files and other stuff?
# -FrontPage-
IndexIgnore .htaccess */.?* *~ *# */HEADER* */README* */_vti*<Limit GET POST>
order deny,allow
deny from all
allow from all
</Limit>
<Limit PUT DELETE>
order deny,allow
deny from all
</Limit>
AuthName www.example.com
AuthUserFile /_vti_pvt/service.pwd
AuthGroupFile /_vti_pvt/service.grp
Also how do I get rid of the need for .htm or .php?
An example of one of my re-writes:
Options +FollowSymLinks
RewriteEngine on
RewriteRule id=(.*)\.htm$ info.php?id=$1
Any help would be really appreciated!
When your mod_rewrites don't work, *how* do they not work? Do you get a server error? An error displayed in the browser? Or just a silent failure to rewrite?
If FrontPage is installed, then yes, you will need at least some of that code or an equivalent to prevent hacks, even if you don't use frontpage extensions.
We'll get to the "also" question later: These things are much simpler if taken one at a time.
Jim
Ok I thought I'd got my head round some basic htaccess after hours of playing around. I had a problem in my code, doh!
So if i insert mod re-writes underneath this front page code will my site still be secure?
And the "also" - how do I het rid of the need for .htm in this re-write for example:
Options +FollowSymLinks
RewriteEngine on
RewriteRule id=(.*)\.htm$ info.php?id=$1
Thanks again - this site is def the best and I've looked at lots!
So if i insert mod re-writes underneath this front page code will my site still be secure?
Directives in .htaccess and other config files are processed by each Apache module in turn, according to the reverse LoadModule order on Apache 1.x, and according to the order determined by an internal priority scheme in Apache 2.x. Each module processes only the directives that it recognizes, and ignores the others.
What this means is that the order of directives which are all processed by the same module is significant, but that the order of directives processed by different modules is not.
For example, if you have two directives which are both processed by mod_rewrite, then they will be processed in the order that they appear in your .htaccess code.
However, if you have a mod_rewrite directive ahead of a mod_auth directive, then they won't be executed in the order you specify, because mod_auth always runs first (on any normally-configured server).
So, it is important to realize that your directives in .htaccess, taken as a whole, cannot be viewed as a sequentially-ordered program or script.
If you group all of your directives for each module together neatly, then you can almost view your file as a collection of subroutines or functions called by the server's "incoming HTTP request processing program" which consists only of "call module #1, then call module #2, then call module #3, etc.
So, it doesn't really matter whether your mod_rewrite code goes above or below your mod_access code used to restrict frontpage extensions, because on a normally-configured server, mod_access will execute first.
---
And the "also" - how do I het rid of the need for .htm in this re-write for example:
Options +FollowSymLinks
RewriteEngine on
RewriteRule id=(.*)\.htm$ info.php?id=$1
If you remove the ".htm" from that rule, then the resulting rule will do this: When a request is received for any URL-path ending with "id=" followed by any number of any characters (including zero), then that request will be "sent" to the file info.php, with a query string of "id=" followed by the "any number of any characters" captured from the originally-requested URL.
But things are rarely that simple. For one thing, RewriteRule looks at the URL-path only. This consists of the URL with the "http://" and domain name and query strings removed. So, if the browser requests "http://example.com/silly.htm?foo=bar" then the URL path inspected by RewriteRule in .htaccess is "silly.htm" and no more. The protocol, hostname, and query string (if any) can be inspected by RewriteConds if needed, but RewriteRule cannot see them directly.
So let's back up a bit and look at what you are trying to do. Look at one of your pages involved in this project:
In accordance with our TOS and Forum Charter, please use only "example.com" as your domain name in posts here... Thanks!
Jim
Although a little over my head! Basically (sorry I'm a bit of a simpleton!) My coding is fine in terms of the security as it doesn't matter where I put teh mod re-write?
I terms of what I want to change:
www.example.com/info.php?id=66 to www.example.com/id=66 to make it simpler for users to find a specific item.
Also to change hideously long urls to cleaner more search engine and user freindly url's, eg:
http://www.example.com/search.php?c=&s=&search_country=Spain&search_state=&search_PropertyType=&MaxPrice=&MinPrice=&rooms1=&rooms2=
This url only has one search criteria in it! Spain. So will use mod re-write to clean this up to:
http://www.example.com/Spain
I haven't done so yet as don't want duplicate pages eg two urls pointing to same page. So I am assuming that I can change my php code around any mod re-writes I do to prevent duplicates - ie one static url links and php search results pointing to the same thing. So for example:
php code now:
$url = "search.php?c=$c&s=$s&search_country=$_POST[search_country]&search_state=$_POST[search_state]&search_PropertyType=$_POST[search_PropertyType]";
change to
$url = "$_POST[search_country]&$_POST[search_state]&$_POST[search_PropertyType]";
Mod_Rewrite then receives requests for the URLs and uses the rules you defined to connect the request to the old filepath on the server.
Unless you want a whole load of other issues to deal with, go with all lower-case URLs too.
*** www.example.com/info.php?id=66 to www.example.com/id=66 ***
I would omit the equals sign in the new format, and likely omit the id part too, especially if it were easy to identify the id number with a simple non-ambiguous match (such as if the id were always 5 digits, and no other 5 digit numbers appeared in any other parameters elsewhere on the site).