How to use a CIDR netmask to block an IP address range using .htaccess

This article explains why you must sometimes use CIDR netmask notation to ban an IP address range using Apache .htaccess, and how to do it. It is intended to supplement the basic Apache information about mod_access in the documentation at http://httpd.apache.org/docs/1.3/mod/mod_access.html.

An IP address is a 32-bit binary number that uniquely identifies a computer on the internet

32-bit binary is hard to remember : 11000000010000000000000000000000

Decimal notation isn't much easier: 3225419776

So it is usually written like this     : 192.64.0.0

You get this "dotted-quad notation" by breaking the 32 bits into 4 groups of 8 and then converting each group to decimal:

11000000	01000000	00000000	00000000
192	64	0	0

192.64.0.0

That makes it easier to remember, but it creates problems if you try to use it for calculations.

An IP address contains two pieces of information:

1. The leftmost binary digits are the unique ID of the network (usually your Internet Service Provider, ISP) through which you are connected to the internet.


2. The remaining binary digits are your unique ID as an individual user on that network.

The number of leftmost digits used for network ID is not the same for every network. In CIDR notation, the /nn part says how many of the leftmost bits indicate the network.

If the network uses exactly the leftmost 8, 16, or 24 bits for its ID, then the dividing line between network and user falls on one of the period boundaries of the dotted-quad notation, and one of the partial IP notations will work:

.htaccess partial IP address	Equivalent CIDR
deny from 192	deny from 192.0.0.0/8
deny from 192.64	deny from 192.64.0.0/16
deny from 192.64.0	deny from 192.64.0.0/24

Each quad that you don't specify is treated as a wildcard that can take any value from 0 to 255. So the first example bans any IP address that starts with 192., followed by anything.

When to use CIDR notation

If the network doesn't use exactly 8, 16, or 24 bits for the network part of the IP address, the dividing line between network and user does not fall on a period boundary of dotted-quad notation, and you need to use a CIDR netmask.

Example CIDR/netmask:

192.64.0.0/10

This says the base address of the network is 192.64.0.0 and the first 10 bits are the network:

192 64 0 0 = 11000000 01000000 00000000 00000000

192 is the first 8 bits, but two more bits are part of the network ID, too. The 9th bit is 0 and the 10th is 1, and that is where the 64 comes from.

The full range of this network in quad notation is 192.64.0.0 - 192.127.255.255. Note that the 64 in the second position doesn't remain constant. The first 2 bits are always the same, but the righthand 6 will be different for different users.

The simple notations for an .htaccess ban won't work. Why not?

• deny from 192 would ban the range 192.0.0.0 - 192.255.255.255, which will ban some users that are not coming from this network.


• deny from 192.64 would ban the range 192.64.0.0 - 192.64.255.255, which is insufficient to ban all the users that are coming from this network.

So the answer is CIDR notation and an .htaccess line that says:

deny from 192.64.0.0/10

This says the base address is 192.64.0.0, and the first 10 bits identify the network (those are always the same for all users who are on that network).

To ban a specific IP range in htaccess

1. Figure out, from your website access logs or elsewhere, the IP addresses you want to ban. Look them up in a WhoIs database such as http://whois.domaintools.com/.
   
   


2. Determine whether you need to use a CIDR netmask. If the IP address range in the report looks like one of these, with each quad after the leading one(s) showing a rull range of 0-255, then you can use one of the simpler methods:
   
   
   
   192.0.0.0 - 192.255.255.255   -- Use deny from 192
   
   192.64.0.0 - 192.64.255.255   -- Use deny from 192.64
   
   192.64.128.0 - 192.64.128.255 -- Use deny from 192.64.128
   
   


3. For anything else, you need CIDR. At Domain Tools, the CIDR netmask is sometimes shown in the report for that IP address, several lines down in the report. If it is, that's all you need. You're ready to create the line in your .htaccess file. Go to Step 5.
   
   


4. If the CIDR wasn't given, you can calculate it yourself with a netmask calculator such as http://jodies.de/ipcalc.
   
   
   
   a) Enter the base (lowest) address. 
   
   
   
   b) You can simply determine the netmask (the /nn part) by trial and error, or you can calculate the minimum size to start with: take the rightmost nonzero quad of the base address and convert it to binary in your head or in Windows Calculator. Find the rightmost "1". The netmask will have to be sufficient to include all of the previous quads (at 8 bits each), plus all the digits in this quad up to its rightmost "1". That's the minimum. But it might include some of the trailing zeroes, too.
   
   
   
   c) Keep using trial and error for the netmask until HostMin and HostMax match the IP address range you saw in the Domain Tools report.

Note that final quads of 0 and 255 are reserved, so:



The calculated HostMin will be nnn.nnn.nnn.1,  not nnn.nnn.nnn.0

The calculated HostMax will be nnn.nnn.nnn.254 not nnn.nnn.nnn.255



The Hosts/Net line tells you how many users this network might have, which can help decide whether you really want to ban the entire range.

5. Edit your public_html/.htaccess file to add the "deny from" line:

1. Go to cPanel > File Manager.


2. Navigate to the file public_html/.htaccess.


3. Click on its file name (not the icon next to it).


4. In the upper right corner of the screen, click Edit File.


5. Make a backup copy: Copy all the text in the file, and save it into a file on your local computer so you can put it back into .htaccess if something goes wrong.


6. Backup made? Ok, now you can edit the file. On a blank line in a part of the file that is not between HTML-style tags like <tag></tag>, type the line:
   
   
   
   deny from nnn.nnn.nnn.nnn/nn
   
   
   
   Replace the nnn's with the IP/netmask you calculated for this range.
   
   
   
   Further explanation: some lines of your .htaccess file might be contained between tags that look like HTML tags where the opening tag looks like <tag> and the closing tag looks like </tag>. Insert this new line in a part of the file that is not between any of these pairs of tags.
   
   
   
   Depending on what is in your .htaccess, you might need to use your judgment whether to use the order and allow directives that are also provided by mod_access. See the link to Apache at the top of this article for more information. That is beyond the scope of this article, and it will require your judgment. I'd suggest adding only the "deny from" line at first and seeing if it works as expected. What is expected: you can access your website; most other people can, too; when the denied party tries, your logs will show a result code of 403 Forbidden.
   
   

Understanding mod_rewrite Directives Convertion

Converting mod_rewrite directives

Overview

The URL Rewriting engine in Abyss Web Server is comparable to the mod_rewrite module in Apache. Both offer similar features but they are not fully equivalent.

This article explains how to convert mod_rewrite directives to URL Rewriting parameters in Abyss Web Server. In most cases, the conversion straightforward. But in some rare cases, and for some of the most obscure features of mod_rewrite, conversion is possible provided that you change or rewrite the rules.

mod_rewrite directives syntax

mod_rewrite directives are put in .htaccess files (in subdirectories) or in the main configuration file httpd.conf.

The following directives are related to mod_rewrite and will be used for conversions:

RewriteBase

RewriteCond

RewriteRule

A typical configuration of mod_rewrite looks as follows:

# Some comments

RewriteBase PATH



RewriteCond %{VARIABLE1} CONDITION1

RewriteCond %{VARIABLE2} CONDITION2

RewriteRule REGEX REPLACEMENT [FLAGS]

RewriteBase is optional. By default, the base path is the current location of the directory where the .htaccess file is. Each time a RewriteRule is found, the base path is updated with the parameter following the directive. The base path is useful when processing RewriteRule parameters.

RewriteCond is also optional. 0 or more RewriteCond directives can precede a given RewriteRule declaration.

RewriteRule is mandatory and ends the declaration of a rule. More sequences of RewriteBase/RewriteCond/RewriteRule could follow to define other rules.

Lines which start with # are comments and should be ignored. Lines referencing other directives are also to be ignored during the conversion as they are not related to mod_rewrite.

Starting the conversion

For each RewriteRule directive, you should create a URL Rewriting rule.

• Locate the RewriteRule you'll convert.


• Locate all the RewriteCond directives that precede it directly (there are 0 or more of them).


• Locate the last RewriteBase directive preceding the RewriteRule you'll convert. You may not find a RewriteBase in some cases.


• If you've found a RewriteBase directive, the base path of the current rule will be the path that is referenced in that directive. Otherwise, the base path is the virtual path of the directory where the .htaccess file you're converting is located. For example, if there is no RewriteBase, if the .htaccess file you're converting is inside C:\sites\firstsite\forum, and if your Documents Path is C:\sites\firstsite\, then the base path is /forum.


• Now open Abyss Web Server console, press the Configure associated with the host you'll add the URL rewriting rules to, and select URL Rewriting.


• Press Add in URL Rewriting rules table to create a new rule.

Conversion of the RewriteRule directive

• The RewriteRule directive has the following syntax:
  

  RewriteRule REGEX REPLACEMENT [FLAGS]

  
  [FLAGS] is optional an may not be always present.
  
  REGEX is a regular expression. If it starts with ^ but the next character is not /, the regular expression is referencing a relative path. In such a case, you must prepend it with the base path of the rule before using it in Abyss Web Server.
  
  For example, if the base path is /forum and the RewriteRule directive is:
  

  RewriteRule ^test/(.*)$ index.php?testId=$1

  
  then the regular expression we'll use will be:
  

  ^/forum/test/(.*)$

  
  If REPLACEMENT does not start with / and is not full URL (starting with http:// or similar), the base path should be prepended too. In the above example, the REPLACEMENT that must be taken into account is:
  

  /forum/index.php?testId=$1

  
  


• In the Abyss Web Server console, enter in Virtual Path Regular Expression the regular expression used in RewriteRule (after prepending it with the base path if it starts with ^ but the next character is not /).


• Enter in Redirect to the replacement string used in RewriteRule (after prepending it with the base path if it does not start / and is not full URL).


• If the RewriteRule directive has flags, convert each one of them as explained below:
  

  
  

  chain/C (chained with next rule)

  
  

  From Apache manual: "This flag chains the current rule with the next rule (which itself can be chained with the following rule, and so on). This has the following effect: if a rule matches, then processing continues as usual - the flag has no effect. If the rule does not match, then all following chained rules are skipped." No direct conversion is possible unless you reorder your URL Rewriting rules and correctly set the Next Action in Abyss Web Server for each rule.

  
  

  cookie/CO=NAME:VAL:domain[:lifetime[:path]] (set cookie)

  
  

  No equivalent in Abyss Web Server.

  
  

  env/E=VAR:VAL (set environment variable)

  
  

  No equivalent in Abyss Web Server.

  
  

  forbidden/F (force URL to be forbidden)

  
  

  Set If this rule matches to Report an error to the client and set Status Code to 403 - Forbidden.

  
  

  gone/G (force URL to be gone)

  
  

  Set If this rule matches to Report an error to the client and set Status Code to 410 - Gone.

  
  

  last/L (last rule)

  
  

  Set Next Action to Stop matching

  
  

  next/N (next round)

  
  

  Set Next Action to Stop matching.

  
  

  nocase/NC (no case)

  
  

  Uncheck Case Sensitive

  
  

  noescape/NE (no URI escaping of output)

  
  

  Uncheck Escape Redirection Location.

  
  

  nosubreq/NS (not for internal sub-requests)

  
  

  Uncheck Apply to subrequests too.

  
  

  proxy/P (force proxy)

  
  

  No equivalent in Abyss Web Server.

  
  

  passthrough/PT (pass through to next handler)

  
  

  No equivalent in Abyss Web Server.

  
  

  qsappend/QSA (query string append)

  
  

  Check Append Query String.

  
  

  redirect/R[=code] (force redirect)

  
  

  Set If this rule matches to Perform an external redirection and set Status Code to the value of code if available or to 302.

  
  

  skip/S=num (skip next rule(s))

  
  

  From Apache manual: "This flag forces the rewriting engine to skip the next num rules in sequence, if the current rule matches." No direct conversion is possible unless you reorder your URL Rewriting rules and correctly set the Next Action in Abyss Web Server for each rule.

  
  

  type/T=MIME-type (force MIME type)

  
  

  No equivalent in Abyss Web Server.

  
  

  
  

Conversion of the RewriteCond directives

Now it's time to convert the RewriteCond directives associated with the RewriteRule we're working on. Remember that only the RewriteCond immediately preceding the RewriteRule are to be taken into account. If there are no RewriteCond directives, conversion is over.

• A RewriteCond directive has the form:
  

  RewriteCond %{VARIABLE} COND [FLAGS]

  
  If the first argument of the RewriteCond you're converting contains a string which is not conforming to the syntax %{VARIABLE}, it will be impossible to convert the mod_rewrite rule to an Abyss Web Server URL Rewriting rule.
  
  [FLAGS] are optional and may not be always present.
  
  For each RewriteCond, press Add in the Conditions table and enter the value of VARIABLE in the Variable field.


• If COND is a regular expression preceded by !, select Does not match with in Operator. If it is a regular expression not preceded by !, set Operator to Matches with. Next enter the regular expression in Regular Expression field.


• Otherwise, COND is one of the following tests:
  

  
  

  <VALUE (lexicographically precedes)

  
  

  Set Operator to < and enter VALUE in the field Value.

  
  

  !<VALUE

  
  

  Set Operator to >= and enter VALUE in the field Value.

  
  

  >VALUE (lexicographically follows)

  
  

  Set Operator to > and enter VALUE in the field Value.

  
  

  !>VALUE

  
  

  Set Operator to <= and enter VALUE in the field Value.

  
  

  =VALUE (lexicographically equal)

  
  

  Set Operator to = and enter VALUE in the field Value.

  
  

  !=VALUE

  
  

  Set Operator to Is different from and enter VALUE in the field Value.

  
  

  -d (is directory)

  
  

  Set Operator to Is a directory.

  
  

  !-d

  
  

  Set Operator to Is not a directory.

  
  

  -f (is regular file)

  
  

  Set Operator to Is a file.

  
  

  !-f

  
  

  Set Operator to Is not a file.

  
  

  -s (is regular file, with size)

  
  

  Set Operator to Exists and is not an empty file.

  
  

  !-s

  
  

  Set Operator to Does not exist and is an empty file.

  
  

  -l/!-l (is/isn't symbolic link)

  
  

  No equivalent in Abyss Web Server.

  
  

  -F/!-F (is/isn't existing file, via subrequest)

  
  

  No equivalent in Abyss Web Server.

  
  

  -U/!-U (is/isn't existing URL, via subrequest)

  
  

  No equivalent in Abyss Web Server.

  
  

  
  


• If FLAGS are present, their conversion should be done as follows:
  

  
  

  nocase/NC (no case)

  
  

  Uncheck Case Sensitive.

  
  

  ornext/OR (or next condition)

  
  

  The only case where a direct conversion is possible is when you have two or more consecutive RewriteCond operating on the same variable. In such a case, the regular expressions of each condition have to be concatenated with a | sign. For example:
  

  RewriteCond %{HTTP_USER_AGENT} Mozilla [OR]
  
  RewriteCond %{HTTP_USER_AGENT} Opera [OR]
  
  RewriteCond %{HTTP_USER_AGENT} Lynx

  
  could be combined in a single RewriteCond:
  

  RewriteCond %{HTTP_USER_AGENT} Mozilla|Opera|Lynx

  
  and thus it suffices to have a single condition on variable HTTP_USER_AGENT which checks if its value matches with Mozilla|Opera|Lynx.

  
  

  
  

27 Apache Request Methods for rewritecond in htaccess

Introduction

The Request Method, as supplied in the REQUEST_METHOD meta-variable, identifies the processing method to be applied by the script in producing a response.

The script author can choose to implement the methods most appropriate for the particular application.

If the script receives a request with a method it does not support it SHOULD reject it with an error.

List of the 27 Request Methods Recognized by Apache

1. GET


2. PUT


3. POST


4. DELETE


5. CONNECT


6. OPTIONS


7. TRACE


8. PATCH


9. PROPFIND


10. PROPPATCH


11. MKCOL


12. COPY


13. MOVE


14. LOCK


15. UNLOCK


16. VERSION_CONTROL


17. CHECKOUT


18. UNCHECKOUT


19. CHECKIN


20. UPDATE


21. LABEL


22. REPORT


23. MKWORKSPACE


24. MKACTIVITY


25. BASELINE_CONTROL


26. MERGE


27. INVALID

GET

The GET method indicates that the script should produce a document based on the meta-variable values. By convention, the GET method is ’safe’ and ‘idempotent’ and SHOULD NOT have the significance of taking an action other than producing a document.

The meaning of the GET method may be modified and refined by protocol-specific meta-variables.

POST

The POST method is used to request the script perform processing and produce a document based on the data in the request message-body, in addition to meta-variable values. A common use is form submission in HTML [18], intended to initiate processing by the script that has a permanent affect, such a change in a database.

The script MUST check the value of the CONTENT_LENGTH variable before reading the attached message-body, and SHOULD check the CONTENT_TYPE value before processing it.

HEAD

The HEAD method requests the script to do sufficient processing to return the response header fields, without providing a response message-body. The script MUST NOT provide a response message-body for a HEAD request. If it does, then the server MUST discard the message-body when reading the response from the script.

OPTIONS

The OPTIONS method represents a request for information about the communication options available on the request/response chain identified by the Request-URI. This method allows the client to determine the options and/or requirements associated with a resource, or the capabilities of a server, without implying a resource action or initiating a resource retrieval.

Responses to this method are not cacheable.

If the OPTIONS request includes an entity-body (as indicated by the presence of Content-Length or Transfer-Encoding), then the media type MUST be indicated by a Content-Type field. Although this specification does not define any use for such a body, future extensions to HTTP might use the OPTIONS body to make more detailed queries on the server. A server that does not support such an extension MAY discard the request body.

If the Request-URI is an asterisk (“*”), the OPTIONS request is intended to apply to the server in general rather than to a specific resource. Since a server’s communication options typically depend on the resource, the “*” request is only useful as a “ping” or “no-op” type of method; it does nothing beyond allowing the client to test the capabilities of the server. For example, this can be used to test a proxy for HTTP/1.1 compliance (or lack thereof). If the Request-URI is not an asterisk, the OPTIONS request applies only to the options that are available when communicating with that resource.

A 200 response SHOULD include any header fields that indicate optional features implemented by the server and applicable to that resource (e.g., Allow), possibly including extensions not defined by this specification. The response body, if any, SHOULD also include information about the communication options. The format for such a body is not defined by this specification, but might be defined by future extensions to HTTP. Content negotiation MAY be used to select the appropriate response format. If no response body is included, the response MUST include a Content-Length field with a field-value of “0″.

The Max-Forwards request-header field MAY be used to target a specific proxy in the request chain. When a proxy receives an OPTIONS request on an absoluteURI for which request forwarding is permitted, the proxy MUST check for a Max-Forwards field. If the Max-Forwards field-value is zero (“0″), the proxy MUST NOT forward the message; instead, the proxy SHOULD respond with its own communication options. If the Max-Forwards field-value is an integer greater than zero, the proxy MUST decrement the field-value when it forwards the request. If no Max-Forwards field is present in the request, then the forwarded request MUST NOT include a Max-Forwards field.

PUT

The PUT method requests that the enclosed entity be stored under the supplied Request-URI. If the Request-URI refers to an already existing resource, the enclosed entity SHOULD be considered as a modified version of the one residing on the origin server. If the Request-URI does not point to an existing resource, and that URI is capable of being defined as a new resource by the requesting user agent, the origin server can create the resource with that URI. If a new resource is created, the origin server MUST inform the user agent via the 201 (Created) response. If an existing resource is modified, either the 200 (OK) or 204 (No Content) response codes SHOULD be sent to indicate successful completion of the request. If the resource could not be created or modified with the Request-URI, an appropriate error response SHOULD be given that reflects the nature of the problem. The recipient of the entity MUST NOT ignore any Content-* (e.g. Content-Range) headers that it does not understand or implement and MUST return a 501 (Not Implemented) response in such cases.

If the request passes through a cache and the Request-URI identifies one or more currently cached entities, those entries SHOULD be treated as stale. Responses to this method are not cacheable.

The fundamental difference between the POST and PUT requests is reflected in the different meaning of the Request-URI. The URI in a POST request identifies the resource that will handle the enclosed entity. That resource might be a data-accepting process, a gateway to some other protocol, or a separate entity that accepts annotations. In contrast, the URI in a PUT request identifies the entity enclosed with the request — the user agent knows what URI is intended and the server MUST NOT attempt to apply the request to some other resource. If the server desires that the request be applied to a different URI, it MUST send a 301 (Moved Permanently) response; the user agent MAY then make its own decision regarding whether or not to redirect the request.

A single resource MAY be identified by many different URIs. For example, an article might have a URI for identifying “the current version” which is separate from the URI identifying each particular version. In this case, a PUT request on a general URI might result in several other URIs being defined by the origin server.

HTTP/1.1 does not define how a PUT method affects the state of an origin server.

PUT requests MUST obey the message transmission requirements.

Unless otherwise specified for a particular entity-header, the entity-headers in the PUT request SHOULD be applied to the resource created or modified by the PUT.

DELETE

The DELETE method requests that the origin server delete the resource identified by the Request-URI. This method MAY be overridden by human intervention (or other means) on the origin server. The client cannot be guaranteed that the operation has been carried out, even if the status code returned from the origin server indicates that the action has been completed successfully. However, the server SHOULD NOT indicate success unless, at the time the response is given, it intends to delete the resource or move it to an inaccessible location.

A successful response SHOULD be 200 (OK) if the response includes an entity describing the status, 202 (Accepted) if the action has not yet been enacted, or 204 (No Content) if the action has been enacted but the response does not include an entity.

If the request passes through a cache and the Request-URI identifies one or more currently cached entities, those entries SHOULD be treated as stale. Responses to this method are not cacheable.

TRACE

The TRACE method is used to invoke a remote, application-layer loop- back of the request message. The final recipient of the request SHOULD reflect the message received back to the client as the entity-body of a 200 (OK) response. The final recipient is either the origin server or the first proxy or gateway to receive a Max-Forwards value of zero (0) in the request (see section 14.31). A TRACE request MUST NOT include an entity.

TRACE allows the client to see what is being received at the other end of the request chain and use that data for testing or diagnostic information. The value of the Via header field (section 14.45) is of particular interest, since it acts as a trace of the request chain. Use of the Max-Forwards header field allows the client to limit the length of the request chain, which is useful for testing a chain of proxies forwarding messages in an infinite loop.

If the request is valid, the response SHOULD contain the entire request message in the entity-body, with a Content-Type of “message/http”. Responses to this method MUST NOT be cached.

CONNECT

This specification reserves the method name CONNECT for use with a proxy that can dynamically switch to being a tunnel e.g. SSL tunneling.

Mod Rewrite Tips and Examples

For example, to limit the next 5 RewriteRules to only be applied to .html and .php files, you can use the following code, which tests if the url does not end in .html or .php and if it doesn’t, it will skip the next 5 RewriteRules.



RewriteRule !\.(html|php)$ - [S=5]

RewriteRule ^.*-(vf12|vf13|vf5|vf35|vf1|vf10|vf33|vf8).+$ - [S=1]



.htaccess rewrite examples should begin with:

Options +FollowSymLinks



RewriteEngine On

RewriteBase /

Require the www

Options +FollowSymLinks

RewriteEngine On

RewriteBase /

RewriteCond %{HTTP_HOST} !^www\.askapache\.com$ [NC]

RewriteRule ^(.*)$ http://www.askapache.com/$1 [R=301,L]

Loop Stopping Code

Sometimes your rewrites cause infinite loops, stop it with one of these rewrite code snippets.

RewriteCond %{REQUEST_URI} ^/(stats/|missing\.html|failed_auth\.html|error/).* [NC]

RewriteRule .* - [L]



RewriteCond %{ENV:REDIRECT_STATUS} 200

RewriteRule .* - [L]

Cache-Friendly File Names

This is probably my favorite, and I use it on every site I work on. It allows me to update my javascript and css files in my visitors cache’s simply by naming them differently in the html, on the server they stay the same name. This rewrites all files for /zap/j/anything-anynumber.js to /zap/j/anything.js and /zap/c/anything-anynumber.css to /zap/c/anything.css

RewriteRule ^zap/(j|c)/([a-z]+)-([0-9]+)\.(js|css)$ /zap/$1/$2.$4 [L]



SEO friendly link for non-flash browsers

When you use flash on your site and you properly supply a link to download flash that shows up for non-flash aware browsers, it is nice to use a shortcut to keep your code clean and your external links to a minimum. This code allows me to link to site.com/getflash/ for non-flash aware browsers.

RewriteRule ^getflash/?$ http://www.adobe.com/shockwave/download/download.cgi?P1_Prod_Version=ShockwaveFlash [NC,L,R=307]



Removing the Query_String

On many sites, the page will be displayed for both page.html and page.html?anything=anything, which hurts your SEO with duplicate content. An easy way to fix this issue is to redirect external requests containing a query string to the same uri without the query_string.

RewriteCond %{THE_REQUEST} ^GET\ /.*\;.*\ HTTP/

RewriteCond %{QUERY_STRING} !^$

RewriteRule .* http://www.askapache.com%{REQUEST_URI}? [R=301,L]

Sending requests to a php script

This .htaccess rewrite example invisibly rewrites requests for all Adobe pdf files to be handled by /cgi-bin/pdf-script.php

RewriteRule ^(.+)\.pdf$ /cgi-bin/pdf-script.php?file=$1.pdf [L,NC,QSA]

Setting the language variable based on Client

For sites using multiviews or with multiple language capabilities, it is nice to be able to send the correct language automatically based on the clients preferred language.

RewriteCond %{HTTP:Accept-Language} ^.*(de|es|fr|it|ja|ru|en).*$ [NC]

RewriteRule ^(.*)$ - [env=prefer-language:%1]



Deny Access To Everyone Except PHP fopen

This allows access to all files by php fopen, but denies anyone else.

RewriteEngine On

RewriteBase /

RewriteCond %{THE_REQUEST} ^.+$ [NC]

RewriteRule .* - [F,L]

Deny access to anything in a subfolder except php fopen

This can be very handy if you want to serve media files or special downloads but only through a php proxy script.

RewriteEngine On

RewriteBase /

RewriteCond %{THE_REQUEST} ^[A-Z]{3,9}\ /([^/]+)/.*\ HTTP [NC]

RewriteRule .* - [F,L]

Require no www

Options +FollowSymLinks

RewriteEngine On

RewriteBase /

RewriteCond %{HTTP_HOST} !^askapache\.com$ [NC]

RewriteRule ^(.*)$ http://askapache.com/$1 [R=301,L]

Check for a key in QUERY_STRING

Uses a RewriteCond Directive to check QUERY_STRING for passkey, if it doesn’t find it it redirects all requests for anything in the /logged-in/ directory to the /login.php script.

RewriteEngine On

RewriteBase /

RewriteCond %{QUERY_STRING} !passkey

RewriteRule ^/logged-in/(.*)$ /login.php [L]

Removes the QUERY_STRING from the URL

If the QUERY_STRING has any value at all besides blank than the?at the end of /login.php? tells mod_rewrite to remove the QUERY_STRING from login.php and redirect.

RewriteEngine On

RewriteBase /

RewriteCond %{QUERY_STRING} .

RewriteRule ^login.php /login.php? [L]

Fix for infinite loops

An error message related to this isRequest exceeded the limit of 10 internal redirects due to probable configuration error. Use 'LimitInternalRecursion' to increase the limit if necessary. Use 'LogLevel debug' to get a backtrace.or you may seeRequest exceeded the limit,probable configuration error,Use 'LogLevel debug' to get a backtrace, orUse 'LimitInternalRecursion' to increase the limit if necessary

RewriteCond %{ENV:REDIRECT_STATUS} 200

RewriteRule .* - [L]

External Redirect .php files to .html files (SEO friendly)

RewriteRule ^(.*)\.php$ /$1.html [R=301,L]

Internal Redirect .php files to .html files (SEO friendly)

Redirects all files that end in .html to be served from filename.php so it looks like all your pages are .html but really they are .php

RewriteRule ^(.*)\.html$ $1.php [R=301,L]



block access to files during certain hours of the day

Options +FollowSymLinks

RewriteEngine On

RewriteBase /

# If the hour is 16 (4 PM) Then deny all access

RewriteCond %{TIME_HOUR} ^16$

RewriteRule ^.*$ - [F,L]



Rewrite underscores to hyphens for SEO URL

Converts all underscores “_” in urls to hyphens “-” for SEO benefits… See the full article for more info.

Options +FollowSymLinks

RewriteEngine On

RewriteBase /



RewriteRule !\.(html|php)$ - [S=4]

RewriteRule ^([^_]*)_([^_]*)_([^_]*)_([^_]*)_(.*)$ $1-$2-$3-$4-$5 [E=uscor:Yes]

RewriteRule ^([^_]*)_([^_]*)_([^_]*)_(.*)$ $1-$2-$3-$4 [E=uscor:Yes]

RewriteRule ^([^_]*)_([^_]*)_(.*)$ $1-$2-$3 [E=uscor:Yes]

RewriteRule ^([^_]*)_(.*)$ $1-$2 [E=uscor:Yes]



RewriteCond %{ENV:uscor} ^Yes$

RewriteRule (.*) http://d.com/$1 [R=301,L]



Require the www without hardcoding

Options +FollowSymLinks

RewriteEngine On

RewriteBase /

RewriteCond %{HTTP_HOST} !^www\.[a-z-]+\.[a-z]{2,6} [NC]

RewriteCond %{HTTP_HOST} ([a-z-]+\.[a-z]{2,6})$ [NC]

RewriteRule ^/(.*)$ http://%1/$1 [R=301,L]



Require no subdomain

RewriteEngine On

RewriteBase /

RewriteCond %{HTTP_HOST} \.([a-z-]+\.[a-z]{2,6})$ [NC]

RewriteRule ^/(.*)$ http://%1/$1 [R=301,L]

Require no subdomain

RewriteEngine On

RewriteBase /

RewriteCond %{HTTP_HOST} \.([^\.]+\.[^\.0-9]+)$

RewriteRule ^(.*)$ http://%1/$1 [R=301,L]



Redirecting Wordpress Feeds to Feedburner

Full article:Redirecting Wordpress Feeds to Feedburner

RewriteEngine On

RewriteBase /

RewriteCond %{REQUEST_URI} ^/feed\.gif$

RewriteRule .* - [L]



RewriteCond %{HTTP_USER_AGENT} !^.*(FeedBurner|FeedValidator) [NC]

RewriteRule ^feed/?.*$ http://feeds.feedburner.com/apache/htaccess [L,R=302]



RewriteCond %{REQUEST_FILENAME} !-f

RewriteCond %{REQUEST_FILENAME} !-d

RewriteRule . /index.php [L]



Only allow GET and PUT Request Methods

Article: Request Methods

RewriteEngine On

RewriteBase /

RewriteCond %{REQUEST_METHOD} !^(GET|PUT)

RewriteRule .* - [F]

Prevent Files image/file hotlinking and bandwidth stealing

RewriteEngine On

RewriteBase /

RewriteCond %{HTTP_REFERER} !^$

RewriteCond %{HTTP_REFERER} !^http://(www\.)?askapache.com/.*$ [NC]

RewriteRule \.(gif|jpg|swf|flv|png)$ /feed/ [R=302,L]

Stop browser prefetching

RewriteEngine On

SetEnvIfNoCase X-Forwarded-For .+ proxy=yes

SetEnvIfNoCase X-moz prefetch no_access=yes



# block pre-fetch requests with X-moz headers

RewriteCond %{ENV:no_access} yes

RewriteRule .* - [F,L]

Make a prefetching hint for Firefox.

Header append Link "

</index.htm>

; rel=prefetch"

This module uses a rule-based rewriting engine (based on a regular-expression parser) to rewrite requested URLs on the fly. It supports an unlimited number of rules and an unlimited number of attached rule conditions for each rule, to provide a really flexible and powerful URL manipulation mechanism. The URL manipulations can depend on various tests, of server variables, environment variables, HTTP headers, or time stamps. Even external database lookups in various formats can be used to achieve highly granular URL matching.

This module operates on the full URLs (including the path-info part) both in per-server context (httpd.conf) and per-directory context (.htaccess) and can generate query-string parts on result. The rewritten result can lead to internal sub-processing, external request redirection or even to an internal proxy throughput.

Further details, discussion, and examples, are provided in the detailed mod_rewrite documentation.