This article is part of a blog optimization process I've implemented lately and taken the loading times of my blog from 12-18 seconds to 4-7 2-3 seconds. As a bonus, these .htaccess rules improved the blog security at the same time.
Here's the thing. Many blogs have a .htaccess file that only has the rules WordPress (or any other blogging platform) install places there and possibly rules a plugin has created too. If you don't add these rules to your root .htaccess file, you're missing out easy performance improvements any blogger can have. So don't count on your hosting provider's default rules (if there even is any) and make your blog better with these simple .htaccess rules.
As a part of general optimizing a blog for both fast page loading and securing the site, the .htaccess -file at the root of your domain is an easy way to do web page optimization on a site level. Putting these rules into use won't alone cut your page loading times to half, but they do provide the foundation for further optimization and speed improvements for your blog, or any website for that matter.
You can find the most essential .htaccess blog optimization and security additions from this post. After reading this article you know how to
- protect the .htaccess file itself
- protect your core blog files, like wp-config.php on WordPress
- prevent anyone from seeing the directory indexes on your server
- protect your blog from direct comment spam
- setup file compression to speed up the blog
- (optionally) prevent people from (hot)linking to images on your blog
- configure browser cache setting for your files, so your returning visitors can enjoy super-fast loading through their browser cache
.htaccess Basics
.htaccess (HyperText ACCESS) is the default name of a directory-level configuration file that allows for decentralized management of web server configuration.
Originally the file was designed to control directory level access, e.g. password-protect a directory, but .htaccess is also a way to change how the webserver works. The .htaccess directives affect the directory the file is in and all sub-directories under it, thus the .htaccess rules at the root of your domain controls every directory and request that happens on your server.
Source: http://en.wikipedia.org/wiki/Htaccess
Before You Start Adding and Changing .htaccess Rules
Adding .htaccess rules, optimizing your blog and making it secure is easy when you know what to do, but because erroneous rules in the root .htaccess can really mess a site up, here's some words of warning (don't be too worries thou, this is quite simple)
- Always backup your existing .htaccess file!
- Keep that original in a safe place and don't overwrite it.
- .htaccess is case-sensitive and incorrectly spelled code will cause errors on your server.
- Make sure you edit YOURDOMAIN name where applicable.
- After editing and saving the new version of .htaccess, test that everything works as intended and
- if you're technologically savvy-enough, check your servers error logs to make sure everything is OK.
- If something is not working, delete the rule you added the last or revert to your backed-up .htaccess file.
Blog Optimization and Security Using .htaccess File
Apply these rules to the root .htaccess so it will affect all (sub-)directories on your server. If you have access to httpd.conf that is even better, as rules in that file are set once on the server startup and not checked per request like they are with .htaccess although httpd.conf is not suitable for all the rules here.
1. Protect .htaccess From Outside Access
This should be at the start of each and every root .htaccess file you ever create.
# Protect the .htaccess file
<Files .htaccess>
Order Allow,Deny
Deny from all
</Files>
Source: Perishable Press: Stupid htaccess Tricks
2. Protect wp-config.php From Unwanted Access
Same principle as above, apply the same principle to protect any file, but these two are the most important files to protect
# Protect wpconfig.php
<Files wp-config.php>
Order Allow,Deny
Deny from all
</Files>
Not that this rule can be in .htaccess file at the same directory as the protected file, so not necessarily the root .htaccess
Source: Perishable Press: Stupid htaccess Tricks
3. Disable Directory Browsing
This simple directive will prevent anyone from seeing the index and files in your directories. Your file permissions are important too, but this will prevent a casual visitor from seeing the index and the files in any directory on your server.
# Disable directory browsing
Options All -Indexes
Source: Perishable Press: Stupid htaccess Tricks
4. Protect From Spam Comments
Comment spammers can hit your comment script directly and this rule will prevent anyone from leaving comments without using the comment form. Spam blogging plugins catch the spammers, but as this is the most economical way to prevent direct comment spam attempts, it should be in the .htaccess-file of any blog.
# Protect from spam comments
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_METHOD} POST
RewriteCond %{REQUEST_URI} .wp-comments-post\.php*
RewriteCond %{HTTP_REFERER} !.*YOURDOMAIN.com.* [OR]
RewriteCond %{HTTP_USER_AGENT} ^$
RewriteRule (.*) ^http://%{REMOTE_ADDR}/$ [R=301,L]
</IfModule>
This code is created for WordPress blog (comments left with the wp-comments-post script. If the comment script is not referred from YOURDOMAIN (edit your domain there, without the www.) or there is not user agent, the request is redirected back to the referrer.
In very rare cases, some browser might have a blank user agent and this code might block those browsers as well.
Source: WPRecipes -- How to: Deny comment posting to no referrer requests
5. (OPTIONAL) Prevent Hotlinking
If someone is stealing your bandwidth and hotlinks to images on your server, this will help. It will redirect any outside linking to an image on your server to another image instead which you can have on another (free) domain.
Make a "please don't hotlink" image and save it on a free image hosting, like Flickr, Picasa or such and edit the URL of the image to the code (replacing http://ANOTHERDOMAIN.com/nohotlinking.jpg with the URL to the picture).
# Protect bandwidth
<IfModule mod_rewrite.c>
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http://(.+\.)?YOURDOMAIN\.com/ [NC]
RewriteRule .(jpg|jpeg|png|gif)$ http://ANOTHERDOMAIN.com/nohotlinking.jpg [NC,R,L]
</IfModule>
Do not use this code unless you know what you're doing. This will prevent using the images on your server from any other servers. Unless you do some tweaks, this will prevent showing the images in RSS readers, like Google Reader, so be aware of that.
Personally, I'm not using the hotlinking-prevention at the moment and it's not necessary unless you start to have problems with hotlinking.
Source: Girl Geekette: .htaccess – How To Stop Hotlinking
6. Compress Content
This next code utilizes Apache's mod_gzip and newer mod_deflate code to compress files on the fly. Most, if not all modern browsers can process compressed content and get it uncompressed on the fly, thus speeding up loading the site for the user, saving your bandwidth and reducing server load.
As compressed files are smaller, less data must be downloaded to your readers browser and less data travels faster. Everyone wins :)
6.1. Test What Apache mod_ Is Active On Your Server
Your server probably has mod_gzip (Apache 1.3) or mod_deflate (Apache 2.x, preferred!) active. To test which you can / should use, here's a simple test you can use. As it works for other Apache mods as well, we can test if your server has mod_headers and mod_expires active as well (for setting headers and expiration times below).
1. Create index.shtml.txt file with one line (#printenv inside a html comment):
<!--#printenv -->
2. Create .htaccess file with these lines:
SetEnv MOD_mod_deflate 0
SetEnv MOD_mod_gzip 0
SetEnv MOD_mod_headers 0
SetEnv MOD_mod_expires 0
<IfModule mod_deflate.c>
SetEnv MOD_mod_deflate 1
</IfModule>
<IfModule mod_gzip.c>
SetEnv MOD_mod_gzip 1
</IfModule>
<IfModule mod_headers.c>
SetEnv MOD_mod_headers 1
</IfModule>
<IfModule mod_expires.c>
SetEnv MOD_mod_expires 1
</IfModule>
3. Create a temporary directory to your server, e.g. http://example.com/temp/
4. Transfer the index.shtml and .htaccess you just created to the temp-directory
5. Access the index.shtml.txt, e.g. http://example.com/temp/index.shtml.txt (if you have problems opening the index.shtml.txt, rename the filed as index.shtml and access the directory, e.g. http://example.com/temp/)
6. You are looking to find either MOD_mod_deflate=1 OR MOD_mod_gzip=1 (and MOD_mod_headers=1 + MOD_mod_expires=1) on the page. 1 means the module is enabled. 0 means the module is not enabled.
7. Delete the temporary directory
After testing which mod is active, use Either mod_gzip or mod_deflate compression in the .htaccess:
Source: DreamHost Wiki: Apache HTTP Server
6.2. Using mod_gzip Compression
# BEGIN GZIP
# mod_gzip compression (legacy, Apache 1.3)
<IfModule mod_gzip.c>
mod_gzip_on Yes
mod_gzip_dechunk Yes
mod_gzip_item_include file \.(html?|xml|txt|css|js)$
mod_gzip_item_include handler ^cgi-script$
mod_gzip_item_include mime ^text/.*
mod_gzip_item_include mime ^application/x-javascript.*
mod_gzip_item_exclude mime ^image/.*
mod_gzip_item_exclude rspheader ^Content-Encoding:.*gzip.*
</IfModule>
# END GZIP
Source: SAMAXES: .htaccess - gzip and cache your site for faster loading and bandwidth saving
6.3. Using mod_deflate Compression
# BEGIN Compression (DEFLATE)
<IfModule mod_deflate.c>
# Enable compression
AddOutputFilterByType DEFLATE text/css text/javascript application/x-javascript text/html text/plain text/xml image/x-icon
<IfModule mod_setenvif.c>
BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4\.0[678] no-gzip
BrowserMatch \bMSIE !no-gzip !gzip-only-text/html
BrowserMatch \bMSI[E] !no-gzip !gzip-only-text/html
</IfModule>
<IfModule mod_headers.c>
# Make sure proxies deliver correct content
Header append Vary User-Agent env=!dont-vary
# Ensure proxies deliver compressed content correctly
Header append Vary Accept-Encoding
</IfModule>
</IfModule>
# END Compression (DEFLATE)
NOTE: All AddOutputFilterByType rule should be on one line (next line always starts with the comment # Dont' compress...) , even if it wraps above.
Source: Apache HTTP Server documentation: mod_deflate (I optimized the rules, this version of the directives is also in the post: .htaccess rules for site speed.)
6.4. Test That Compression Is Working
To test if compression is working on a specific file or URL, you can check it at:
http://www.whatsmyip.org/http_compression/
As a bonus, you also see how much data transfer compression is saving you (and your readers) on that document.
7. Set Expire Headers and Times
Static content, like images, can be cached to your visitors browser, but unless you set the expiration times, there is no way for the browser to know if the component is still valid or has it expired. Thus all files are loaded from your server, putting load on your blog and slowing the loading speed for the reader.
There are two ways to set these. By setting a expiration time per file type or setting expiration headers. The times are configured in seconds (e.g. one hour = 3600 seconds) or through natural language. When considering the expiration times, think how often the content is updating.
For example, if you upload an image, there's a change that you won't ever change or edit that image, thus images can have long expiration times (1 month or over an year). Then again, the html- and php-files on your blog are quite dynamic, so it's probably good to keep the expiration times under 2 hours (or even set the expiration times to 1 sec or completely off).
7.1. Disable ETags
It would be beneficial to use ETags as an accurate way for server and browser to communicate and see whether or not a file has been updated/expired, but because it's very likely that the ETags are not working properly, it's better to just disable them (and use "last-modified" instead):
# No ETags, No Pragma
<IfModule mod_headers.c>
Header unset Pragma
Header unset ETag
</IfModule>
FileETag none
7.2. Set Expiration Times For Caching
Choose one of the options, depending if you have mod_expires, mod_headers or both enabled. These are example cache header and expiration time configurations you might use. Feel free to tweak your own using these as a guideline.
7.2.1. mod_expires & mod_headers
Cache settings from my speed-optimized .htaccess rules:
# BEGIN CACHING
<IfModule mod_headers.c>
# Default cache time to 1 year (31536000 sec)
Header set Cache-Control "max-age=31536000, public, must-revalidate"
</IfModule>
<IfModule mod_expires.c>
# Turn on Expires
ExpiresActive On
# set default to "access plus 1 year"
ExpiresDefault A31536000
# html - "modification plus 1 hour"
ExpiresByType text/html M3600
# css and JavaScript - "modification plus 6 weeks"
ExpiresByType text/css M3628800
ExpiresByType text/javascript M3628800
ExpiresByType application/x-javascript M3628800
</IfModule>
# No cache for php-files
<FilesMatch "\.(php)$">
<IfModule mod_expires.c>
ExpiresActive Off
</IfModule>
<IfModule mod_headers.c>
Header set Cache-Control "private, no-cache, no-store, proxy-revalidate, no-transform"
</IfModule>
</FilesMatch>
# END CACHING
Source, inspiration & references:
- Perishable Press: Stupid htaccess Tricks
- AskApache: Speed up your site with Caching and cache-control
- AskApache: Speed Tips: Remove Last-Modified Header
- Google Page Speed: Optimize caching
7.2.2. What Expires or max-age time to use?
Some set HTML expiration times to 1 second, as blog's are dynamic with comments and all, and others like to use 1-2 hour cache to fasten the loading for the returning visitors. Personally, I use 1 hour (3600 seconds) at the moment. If you have a static site and the HTML pages are not changing much, set HTML caching to 1 month or even 1 year (never expires).
If you're using plugin like WP-Super Cache, the plugin sets compression and cache rules for the .html(.gz) pages it creates, so you might want to make your own rules match those (WP-Super Cache uses mod_deflate and 5 minutes / 300 seconds for the html pages).
Also, if you set long expiration times for CSS-files and you do edit them, e.g. your blog's theme, you will have to change the file name or just settle for shorter expiration times. For example, WordPress themes are using style.css by default and the name of it is not changing, but you can create non-theme related stylesheet where you import or copy the contents of the different stylesheet.
7.3. Alternate Way, Using ETags
If you use this, don't disable ETags as shown at 7.1.
FileETag MTime Size
<IfModule mod_expires.c>
<FilesMatch "\.(jpg|jpeg|gif|png|css|js)$">
ExpiresActive on
ExpiresDefault "access plus 1 year"
</FilesMatch>
</IfModule>
Source: StoreCrowd.com: The Ultimate WordPress 2.8 Optimization Guide
7.4. (Extra) Use Minimal Caching During Maintenance
Very useful when you're doing changes to your site and want to see the changes without doing a forced reload everytime.
# implement minimal caching during site development
<FilesMatch "\.(flv|gif|jpg|jpeg|png|ico|js|css|pdf|swf|html|htm|txt)$">
<IfModule mod_headers.c>
Header set Cache-Control "max-age=5"
</IfModule>
<IfModule mod_expires.c>
ExpiresActive On
ExpiresDefault A5
</IfModule>
</FilesMatch>
Inspired by: Perishable Press: Stupid htaccess Tricks
8. Additional .htaccess Tricks
These are not related to optimization or security and you shouldn't use these unless you have a reason and know what you're doing.
8.1. Your Own Shortlinks (in WordPress)
Even if you're using SEO-friendly permalink (like you should), the WordPress default url for posts and pages is still active, e.g. http://YOURDOMAIN.com/?p=123
You can use that to your advantage and use this directive to remove the need for that ?p= in the url and have your own short-URLs, like for example this post can be found as http://zemalf.com/1076
# BEGIN URL Shortening
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_URI} ^/([0-9]+)$
RewriteRule .* http://YOURDOMAIN.com/?p=%1 [R=301,L]
</IfModule>
# END URL Shortening
This is more useful if you have a short domain name, and even then a dedicated URL shortening service is better as it provides tracking and such, but it's still a cool trick that you can use to have your domain showing in Twitter.
Source: JohnChow.com: How To Create Your Own Tiny URL
8.2. Force Download (e.g. for mp3, PDFs, etc.)
If you're offering downloads from your blog, you might want to save the users for the usual "Right-click + Save As.." with this rule for the relevant files. This rule will force the files to be downloaded instead of opening them in a browser or other linked program.
<FilesMatch "\.(mov|mp3|pdf)$">
ForceType application/octet-stream
Header set Content-Disposition attachment
</FilesMatch>
Source: Ultimate htaccess Tutorial for .htaccess files
9. References And Further Reading
There's a lot you can do with .htaccess and server rules, but the ones shown on this article are the most essential and you will do fine by just using these, but in case you want to go all out with more .htaccess tricks, I recommend you check these two documents (already referenced multiple times above):
Nothing stupid on this one tbh! If you want to protect a directory with a password, do fancy redirection, block IP-addresses and bots, limit your Admin-area to only your IP and much more, it's all there!
There are many guides and tutorial that call themselves "ultimate" without being one. This one is called ultimate for a good reason.
That's It! Go Tweak Your .htaccess
Good hosting services take care of default .htaccess for you, but some hosting providers don't automatically add a .htaccess file to your server. The only thing you will see in the default .htaccess file (if there even is one) are the settings added there by the blog-installer or some plugin (like WP-Super Cache).
Now you know how to change this! With these tips you can accomplish two important things, higher security and bit of optimization.
If .htaccess file is not there, just create a htaccess.txt file (as .htaccess might be hidden in your operating systems) on your local computer, FTP it to the server root and rename it to .htaccess
There are a lot of things you can do with .htaccess, like various redirects and blogging users (spammers) based on IP-address or a spam-bot they use, but for most bloggers, the tweaks on this post will do just fine.
If you're not confortable editing the .htaccess yourself, get someone to help you (you can even ask me!). It's not hard, as long as you follow the instructions and use the code exactly as it is. And as you did backup your original .htaccess, you can always go back to that.
As said, these .htaccess rules are a part of my blog optimization process, which I have implemented to make this blog load 2-4 times faster than before (yeah, I know, it REALLY sucked before), so there's more to come -- But now if you have any suggestions, questions or feedback, leave a comment below, thanks!
3 links to this post.
27 comments.
Fantastic! This is a really helpful post for non-geeks like me, and one I’m going to keep for future reference. Thanks!
.-= Mike CJ’s last blog ..Making Money Blogging is Easy =-.
Yeah, thanks for thisVery useful for us non-tech heads. Actually I’m going to email you now and ask you a few SEO questions.
.-= Gordie Rogers’s last blog ..Productivity Tip: Don’t Do It! =-.
Holy!! I am very impressed with this article, you’ve managed to compile some of the most helpful and useful htacess tricks EVER
I imagine the amount of research you did for this was staggering, I noticed several urls that I didn’t think anyone else even knew about.
Major props to you for this great article, one of the best compilations and howto guides I’ve ever seen.
Oh wow, thanks for the compliment, I really appreciate it — especially coming from the source I spend part of the “staggering” amount of research in :)
I should be the one thanking you and the other source-sites for all the articles I went through over the last month to get my own .htaccess like I wanted it to be. After that it was just a matter of putting this post together.
This info is accurate and up-to-date, most of these topics you make seem easy and too good to be true, but most of the methods you explain are pretty cutting-edge for htaccess, like just in the past 1-5 years or so.
The short and concise explanations with code was great to read and easy to get through, something I really need to practice ;) I hope you write about something I don’t already know for your next article… What an intro to htaccess!
Subscribed!
.-= AskApache’s last blog ..Protecting Files with Advanced Mod_Rewrite Anti-Hotlinking =-.
Impressive overview. I am currently working on article to decrease page load time and wish this article was available a week ago ;).
Do you have a virtual private server? The reason for asking is that my current shared webhost and 4 others I contacted have turned off mod_gzip and mod_deflate to decrease CPU load. It is only available in dedicated servers.
Are the cache settings still useful when you use WP-Super-Cache?
Cheers
.-= Johan’s last blog ..Making sense of AdSense =-.
Hey there. Turning off mod_deflate is quite short-sighted for the webhost imho — I’d be leaving such a host in a heartbeat. Shared hosting does not have to mean “minimum functionality”, but I guess those hosting providers try to squeeze everything out of their machines instead of adding capacity.
I’m on a shared hosting on DreamHost, and the mod_deflate is in use and it’s all been good so far.
About the cache and WP-Super Cache: The browser cache settings help in a sense that returning visitor or the ones going from page to page have the images, css and such cached on their browser = goodness. On the other hand, for one-time visitor (visiting one page) browser cache doesn’t do anything.
As a side note, I think WP-Super Cache compression option uses mod_deflate, so if you don’t have that on your server, don’t try to activate compression for WP-Super Cache either.
WP-Super Cache stores the html pages in it’s cache, delivers those to the visitor and sets (browser cache) expiration times for the HTML pages to 5 minutes and it’s own cache is one hour or 3600 seconds by default.
With cached HTML from WP-Super Cache (which means no dynamic page must be generated every time), common css and images can be loaded into cache once and then loaded from cache on the following visits/pages. So yeah, cache settings are very useful, even with WP-Super Cache.
Holy moly, that’s a huge post! And very useful. I admit that most of this has been over my head for some time now, but you make it understandable. Thank you!
.-= Amy LeForge’s last blog ..My Day In Court =-.
I’m happy you found the post useful — and if I managed to make it understandable, even better! Thank you Amy
I’m not quite good at this whole .htaccess thing. Each attempt I’ve made at hacking it has left me locked out of my dashboard or even the site. So far so good I’ve only used the browser caching tricks to speed up th load time of my blogs and they work.
WP Super Cache should automatically take care of compression and stuff like that.
.-= Udegbunam Chukwudi’s last blog ..How To Get A Visa or MasterCard In Nigeria =-.
WP Super Cache actually does handle compression for the HTML is caches, but only if your host has mod_deflate active. And the compression option in the plugin’s settings should also be enabled.
There are other plugins that handles compressing the CSS, javascript, images (like SmushIt for WordPress I wrote about earlier), etc.
But setting the .htaccess rules in this post just once takes care of a lot of this as well (which you can take improve even further with other tweaks and optimizing plugins)
This is great stuff and explained so we can use it, thanks.
Can you advise regarding the order that things go into the .htaccess? I have 2 plugins that have written to it along with the code to prevent directory access and to wpconfig. I used my control panel to add a redirect, but had to move it from where the control panel put it to the front of the file before it would work. (This was a while ago)
http://httpd.apache.org/docs/1.3/howto/htaccess.html#how explains that directives are processed in the order they are found. Not understanding all of the code in the plugins’ directives, I still don’t understand why the redirect wasn’t processed when it was at the end of the file.
Just wondered if you had any advice about the order that these rules are put into the file, and relative to other directives. Thanks again!
JEDs
.-= Steve Warriner’s last blog ..FTC Guidelines – One More Day =-.
Hi Steve. What kind of redirect you’re trying to add?
Without knowing the spesifics it is possible that there is conflicting redirect or rule in there, e.g. some other redirect or such. Thus, you should find the right “spot” for the rule before/after/between the rules. Look for other rules with
RewriteCond %{HTTP_REFERER} & RewriteRule, which do the redirect.In general, everything that restricts access should be at the very top and for example the WordPress rule (added at install) should be at the very end.
Zemalf, it was a 301 redirect. And you have answered my question why it didn’t work at the end where my control panel put it, because it came after code put in by my short url plugin from synected.com, which of course has
RewriteCond %{HTTP_REFERER} & RewriteRulein the code. Makes sense now thanks.What you said about rules restricting access should be 1st, means I should move the 301 down below them, it is currently 1st.
You have a new Twitter follower and subscriber to this blog! Steve aka JEDs
It’s my general rule to have the access rules at the beginning, as if something is fordidden/restricted, placing the rules to the beginning makes sure a request is stopped if rules say so. However, the most important thing is that all rules work as intended, and it sounds your 301 found its place already :)
FANTASTIC post – great combination of explanation and useful code. I’d like to add a note and make a suggestion for a future post.
I use GoDaddy hosting and recommend them to my clients. Unfortunately, GoDaddy does not enable Mod_deflate or Mod_Gzip, so compression isn’t possible using the methods you describe.
There IS a work-around for compressing JS and CSS (requires mod rewrite and shell access). I’ve found a couple of people that do an OK job of explaining the process, but I’d like to read a post from you on the subject, i.e. Gzip compression for WP blogs on Godaddy, or something like that…just an idea.
BTW, someday I’d like to wake-up and have your depth of htaccess knowledge.
Hi there Jason, and thank you for a fantastic comment in return. I’m just putting stuff together I’ve learned from others :)
I didn’t know GoDaddy doesn’t have any compression enabled. I’m stunned actually. So thanks for the post suggestion, I will definitely take a look at that, as I’m planning on continuing this “series” about blog optimization. Web optimizing and tweaking is a passion of mine – there is no such thing as “too fast loading blog” :)
As a side note, it is possible to just compress the CSS and JS files manually. And in some cases the static files like main CSS should be compressed anyway, as it doesn’t change, why not compress it once, instead of everytime someone loads it, right? But on the fly compression is perfect for all the third party things like plugins get the benefit too.
I was stunned to learn that as well. It’s a big disappointment, actually. If I weren’t so invested in them I would consider changing, but instead I’ll just use the manual gzip option and lobby for a change.
Thanks again.
Yep. This article represents probably weeks of work and testing. I’ll be referring back to it and linking to it. It turns out I have a draft blog post in my queue on this exact topic, and I am so happy I don’t need to finish it!
.-= Dave Doolin’s last blog ..Static Versus Dynamic Websites – Operational, Informational, Interactional =-.
Thanks Dave, I’m happy to be of assistance :)
Awesome post. Thanks for helping to make my blog more secure!
You're welcome Sebastian, I'm just happy this was useful for you! Thank you for taking the time to comment and sharing the post on Twitter too :)
Hey as I don't know very much about blog commenting I had done several mistakes, but after reading you blog it will be easy to avoid them. thanks a lot for this nice and informative post. i will share this others so that they can take benefit of this wonderful post. Keep up the good work.
Your new very useful in my project work
hi
Do you know of anyway with htaccess to disable someone from using your domain to point to their own website on the same server? Ex: they use YOURDOMAIN.com to promote their PHISHING WEBSITE.COM by using this simple URL to send users : YOURDOMAIN.COM/~phishing/file.html
Any help would be greatly appreciated. Thanks
Roch, I don't understand your question – No one has access to your domain, but you. If someone can use your domain name to redirect stuff, you've been hacked.