Web Development

  Homes arrow Web Development arrow Module mod rewrite Tutorial (Part 4)
 Webmaster Tools
Base64 Encoding 
Browser Settings 
CSS Coder 
CSS Navigation Menu 
Datetime Converter 
DHTML Tooltip 
Dig Utility 
DNS Utility 
Dropdown Menu 
Fetch Content 
Fetch Header 
Floating Layer 
htaccess Generator 
HTML Encoder 
HTML Entities 
IP Convert 
Meta Tags 
Password Encryption
Password Strength
Pattern Extractor 
Ping Utility 
Pop-Up Window 
Regex Extractor 
Regex Match 
Scrollbar Color 
Source Viewer 
Syntax Highlighting 
URL Encoding 
Web Safe Colors 
Forums Sitemap 
Weekly Newsletter
Developer Updates  
Free Website Content 
 RSS  Articles
 RSS  Forums
 RSS  All Feeds
Write For Us 
Contact Us 
Site Map 
Privacy Policy 
  >>> SIGN UP!  
  Lost Password? 

Module mod rewrite Tutorial (Part 4)
By: Developer Shed
  • Search For More Articles!
  • Disclaimer
  • Author Terms
  • Rating: 4 stars4 stars4 stars4 stars4 stars / 9

    Table of Contents:

    Rate this Article: Poor Best 
      Del.ici.ous Digg
      Blink Simpy
      Google Spurl
      Y! MyWeb Furl
    Email Me Similar Content When Posted
    Add Developer Shed Article Feed To Your Site
    Email Article To Friend
    Print Version Of Article
    PDF Version Of Article




    The Apache server power commander part 4
    By Dirk Brockhausen

    In this final part of our tutorial we will take a look at those special directives we haven't covered yet.

    These directives cannot be defined on directory level.

    This means that you will have to be able to edit the Apache webserver's configuration file (httpd.conf). These permissions will usually only be assigned to users "root" or "admin".

    If you wish to log all operations effected by mod_rewrite you can activate logging with the
    following entries:

    RewriteLog /usr/local/apache/logs/mod_rewrite_log
    RewriteLogLevel 1

    These entries are not written into the file ".htaccess" but in "Section 2: 'Main' server
    configuration" of file "httpd.conf".

    All mod_rewrite manipulations will be logged in this file. The log file can have any name you prefer. It can be referenced as an absolute path or relative to ServerRoot.

    If you wish to maintain separate log files for individual virtual hosts, you will have to place the pertinent entries in "Section 3: Virtual Hosts",

    ServerAdmin webmaster@yourdomain.com
    DocumentRoot /usr/www/htdocs/yourdomain
    ServerName yourdomain.com
    RewriteLog /usr/apache/logs/yourdomain_mod_rewrite_log
    RewriteLogLevel 1

    (Note: If your email reader or browser wraps these lines take care to enter them unwrapped in your file!)

    The RewriteLogLevel can be defined within a range of 1 to 8. Normally, 1 will do fine. Higher levels are only required for debugging purposes.

    Another directive which is very handy for cloaking purposes are the so-called Rewriting Maps. These are files consisting of key/value pairs, e.g. in the simple format of an ordinary text file:

    cde2c920.infoseek.com spider spider
    cde2c923.infoseek.com spider spider
    cde2c981.infoseek.com spider spider
    cde2cb23.infoseek.com spider spider

    These keys are, as you can see, hostnames or IPs. In this simplistic example the value is always the same, namely "spider".

    This directive is entered either in the server section 2 or in the virtual host section 3 in file

    RewriteMap botBase txt:/www/yourdomain/spiderspy.txt

    The Rewriting Map will then be available across your server.

    The other directives are entered in file ".htaccess":

    RewriteCond ${botBase:%{REMOTE_HOST}} =spider [OR]
    RewriteCond ${botBase:%{REMOTE_ADDR}} =spider
    RewriteRule ^(.*)\.htm$ $1.htm [L]
    RewriteRule ^.*\.htm$ index.html [L]

    The conditions will make the system check whether the required access is generated by a spider. To this effect a lookup of file "spiderspy.txt" is triggered.

    If the key is found, the value "spider" is returned and the condition is rendered as true.

    Next, the first RewriteRule will be executed. This one determines that the called for ".htm" page will be fed to the spider. The variable $1 is equal to the part in
    parentheses of "^(.*)\.htm$", i.e. the file name will remain the same.

    If the URL is called by a normal human visitor, rule 2 applies: the user will be redirected to page "index.html".

    As the ".htm" pages will only be read by spiders, they can be optimized accordingly for the search engines.

    You may also use a file in dbm format instead of an ordinary text file. The binary data base format helps accelerate the lookup which is particularly important if you are operating from very large spider lists.

    This example given above offers a simple cloaking functionality. All ordinary visitors will always be redirected to the site's "index.html" page and there is no access logging beyond the mod_rewrite logs.

    However, it does go to show how you can effectively replace several lines of Perl code with just a few lines of mod_rewrite.

    Our last example will illustrate this in some greater detail.

    The objective is to present site visitors with your
    "Picture of the Day". Visitors will click a link, e.g.:
    < http://www.yourdomain.com/pic.html >
    which will display a different picture every day.

    We will work from these server variables:


    In file ".htaccess" we will enter the following single code line:

    RewriteRule ^pic.html$ pic-%{TIME_MON}-%{TIME_DAY}.html

    (Note: If your email reader or browser wraps this line take care to enter it unwrapped in your file!)

    The URL called for will be rewritten, e.g. to:


    So all you have to do is upload the pertinent files once, after which you won't need to tend to their daily assignation anymore.

    Obviously the time variables can also be used for other periodicities.

    With this final example our mod_rewrite tutorial has come to its end.

    Of course, we have not tackled each and every directive, variable, etc. here.

    Rather, we suggest you view this tutorial as a general introduction intended to help you as a start off point towards a more in-depth study of the mod_rewrite module, enabling you to customize it according to your specific requirements.

    DISCLAIMER: The content provided in this article is not warranted or guaranteed by Developer Shed, Inc. The content provided is intended for entertainment and/or educational purposes in order to introduce to the reader key ideas, concepts, and/or product reviews. As such it is incumbent upon the reader to employ real-world tactics for security and implementation of best practices. We are not liable for any negative consequences that may result from implementing any information covered in our articles or tutorials. If this is a hardware review, it is not recommended to open and/or modify your hardware.

    More Web Development Articles
    More By Developer Shed



    - On Page SEO for New Domains
    - Improve Your Site`s Speed
    - Safari Books Online Review
    - Creating an Estore From the Ground Up
    - Most Common SEO Mistakes Developers Make
    - Making the Most of Your Titles and Meta Desc...
    - Five Ways Using Flash Can Damage Your Site
    - A Web Designer`s Guide to Colors
    - Use Webstarts to Create a Free Site
    - More Than Just Looks. How Your Web Design C...
    - How to Design Content Pages
    - Mint Review
    - Make Your WordPress Website Look Professional
    - How to Create a Mobile Web Site
    - Meta Tags: Still Useful?

    Developer Shed Affiliates


    © 2003-2018 by Developer Shed. All rights reserved. DS Cluster - Follow our Sitemap