example.com/index.php?module=website&page=somepage1
example.com/index.php?module=report&page=somepage2
example.com/index.php?module=admin&page=somepage3

Now i want to change it to seo friendly url. .

example.com/somepage1.html
example.com/report/somepage2.html
example.com/admin/somepage3.html 

All the pages may or may not be available physically.

what should be the url rewriting steps.

The response for these files appears to return the correct headers:

Last-Modified Thu, 07 Jun 2007 20:05:38 GMT
Cache-Control max-age=604800
Expires Tue, 02 Oct 2007 18:25:13 GMT

It’s still a lot fewer files than with a fresh, unprimed request (no images are re-requested), but I’m wondering if there’s a way to prevent these from being called each time as well.

AddHandler application/x-httpd-php .htm
Options +FollowSymLinks -Indexes -ExecCGI
DirectoryIndex index.htm
AddDefaultCharset ISO-8859-1
AddCharset ISO-8859-1 .css
DefaultLanguage en
ServerSignature Off 

ExpiresActive On
ExpiresByType image/gif A2592000
ExpiresByType image/png A2592000
ExpiresByType image/jpeg A2592000
ExpiresByType image/x-icon A2592000
ExpiresByType application/pdf A2592000
ExpiresByType application/x-javascript A2592000
ExpiresByType text/plain A2592000
ExpiresByType text/css A10800 

Any help would be apprieciated plus I also have access to the httpd.conf in Apache on our server..

I await your reply

# DONT CACHE
Header unset Cache-Control
Header unset Expires
Header unset Last-Modified
FileETag None
Header unset Pragma

you suggest that unsetting cache headers will stop a resource being cached. This is wrong, when there are no cache headers the client can choose whether to cache (setting a client defined heuristic) or not. You must explicitly state no-cache to ensure all clients do not cache resources.

@fostware: opening http connections costs time, and it is not always the case that opening more connections is efficient. Reducing the number of resources is much more effective than just piling up lots of open HTTP connections. Ideally, browsers would follow Opera’s lead and enable HTTP pipelining, allowing high efficiency over fewer (less costly) connections. See http://www.die.net/musings/page_load_time/

FF and IE (by default) process 4 simultaneous requests, but will process each site synchronusly. Split the requests and you make the clients browsers behave like a multithreaded downloader – overall responsiveness is better however you will have the burst requests equivalent to three clients :)

.htaccess files are very useful tools–I use them on my web sites also, but never without carefully considering the pros and cons of turning htaccess on. If you have no other reason than the speed tweaks discussed in this article (and it is a good article, despite my minor quibble with using .htaccess files), then as DrBacchus said, put the tweaks in your httpd.conf file rather than a .htaccess file. Here’s why:

Suppose your web directory looks like this: /var/www/localhost/htdocs/this/is/a/deeply/nested/path/to/somewhere

Given that your web root is /var/www/localhost, then in this case, Apache will have to look for /var/www/localhost/.htaccess, /var/www/localhost/htdocs/.htaccess, /var/www/localhost/htdocs/this/.htaccess, /var/www/localhost/htdocs/this/is/.htaccess, …, /var/www/localhost/htdocs/this/is/a/deeply/nested/path/to/somewhere/.htaccess to make sure that it correctly uses all of the applicable directives. Each of these lookups–whether an .htaccess file exists in that directory or not–incurs a performance hit. Furthermore, it does this for EACH file called by your html code. So, every image, every style sheet and every include in your code requires a lookup in each subdirectory of your web root.

So, if you are on a shared host and will be using .htaccess files anyway–go ahead and add this tweak to your .htaccess file. But, if you are on a dedicated server, and/or have no other reason to use .htaccess files, then apply the tweak to your httpd.conf file for the biggest performance gains.

Regardless if you are applying these settings in your httpd.conf or your .htaccess, the information seems correct. In the latter everything in this article is applicable.

I’m still a firm believer in having .htaccess on commonly hosted websites. The ability to allow clients to make changes on their own (and many management interfaces utilize them by default) will often keep clients happier than the ever so slight performance increase by disabling them all together.