<div id="SafeStyles1160254282">
<!-- begin sanitized html -->
<div id="message">
Here are my thoughts.<br /><br />mod_rewrite is great if you're dealing with legacy systems written in various languages.  I've often retrofitted legacy systems written in Perl,  Java,  PHP,  Cold Fusion,  and you name it with &quot;friendly&quot; URLs quite quickly (&lt;1 afternoon) with mod_rewrite.  It even works with systems that you don't have the source code for,  and that's a big win.<br /><br />mod_rewrite is also good for little jobs.  For instance,  I've got a habit of installing software packages (say a CMS) under unique URLs. Just to take an example,  my site at<br /><br />http://polyhedra.org/<br /><br />redirects to<br /><br />http://polyhedra.org/poly/<br /><br />and I do that redirect with mod_rewrite.  It's easy to do in one line.<br /><br />This is one of a number of &quot;best practices&quot; for URLs,  which I think of as unwritten web standards.  Adding the &quot;/poly/&quot; directory makes my URLs a little longer,  but it means I'll have an easy time if
  I change the CMS I use.  I can build out the new CMS at a new URL and put something under &quot;/poly/&quot; that redirects people to the right place.  I can put &quot;robots.txt&quot;,  &quot;favicon.ico&quot; and all that under the htdocs directory and know that they'll never get trashed by my CMS.  (Particularly important when you're running a commercial CMS.)<br /><br />I call short URLs with no &quot;?&quot; in them &quot;friendly&quot; URLs because they're friendly to everyone.  People look at them and have some faith that the URLs will stay stable if they bookmark them or link to them;  I've seen commercial products that generate 300 character URLs when 20 character URLs would do.  There's no excuse for that.<br /><br />Another issue is URL aliasing.  It's really good for<br /><br />1 resource &lt;=&gt; 1 URL<br /><br />Query schemes that involve GET parameters often create vast numbers of &quot;virtual&quot; pages that display the same resource.  This is harmful in 
 a number of ways.  A useful web search engine needs to remove duplicate documents;  spamming them with multiple copies of the same document is bad,  and hurts the search engine ~compatibility~ of  your site.  Social sites like &quot;del.icio.us&quot; try to keep track of how many people have linked a particular resource:  if there are 1000 URLs that show the same resource (say you use session id's in your URLs),  sites like this don't work,  and your site doesn't get the recognition it deserves.<br /><br />If there's a &quot;mod_rewrite killer&quot;,  it's that nothing like mod_rewrite is packaged with IIS.  Roughly half of the market uses Apache and half uses IIS.  Yes,  mod_rewrite clones exist for IIS,  but many people don't have a lot of control over their web server.  If you're happy being tied to Apache,  this is no problem,  but if portability matters to you,  it is.<br /><br />There's another practice I use on &quot;polyhedra.org&quot;,  which is setting<br /><br />D
 efaultType application/x-httpd-php<br /><br />The result of this is that filenames with no extension default to PHP.  You can write a script with a name like &quot;show&quot;,  so a URL like<br /><br />http://polyhedra.org/poly/show/56/triangular_dipyramid<br /><br />runs the show script,  which sees &quot;/56/triangular_dipyramid&quot; in the PATH_INFO variable,  and does the appropriate thing.  The front controller approach can take this to a higher level.<br /><br />I think web sites look more professional if you don't have &quot;.php&quot;,  &quot;.asp&quot;, &quot;/cgi-bin/&quot; or &quot;.cfm&quot; in your URL.  Some day you might change the language that you work in,  and you'd rather not have to change your URLs.  Most clients don't pay attention to these kind of quality issues,  but I've certainly worked for people who've had a violent reaction to &quot;.php&quot; URLs.  A final point is that sometimes people like to mirror web sites with tools like &quot;httrack&qu
 ot;,  and this works best if your URLs make sense in the context of a static web site.  (HTML files end in .html,  GIF files end in .gif,  etc.)<br /><br /> 

</div>
<!-- end sanitized html -->
</div>