How to use Apache .htaccess and mod_rewrite without corrupting the FrontPage Extensions

People who publish their websites with Microsoft FrontPage to an Apache server often discover that if they modify their site's .htaccess file manually or if they use certain cPanel features that modify .htaccess, it corrupts their FrontPage Extensions, makes the site display improperly, and can make it impossible to publish the site with FrontPage.

The fix is usually to uninstall, clean up, and reinstall the FrontPage Extensions, which has the undesirable side effect of emptying all the site's FrontPage-specific folders that start with an _underscore (including any _underscored folders that are inside other folders that don't start with an underscore). In a worst case, it's necessary, or at least easiest, to republish the entire site. After this has happened a couple of times, many people decide that they can't use .htaccess if they publish with FrontPage. But it is possible.

1. Minor modifications can make the FrontPage Extensions compatible with .htaccess, even with the mod_rewrite module that does rewrites and redirects.
2. It is sometimes possible to uncorrupt the FrontPage extensions without reinstalling them.

I did some experiments to answer these questions:

Is there a security feature of FrontPage Extensions that checks whether .htaccess has been edited and freezes the site if it has?

That is, do the FrontPage Extensions use any tampering detection methods on .htaccess such as checksum verification, timestamp checking, or a hidden or encrypted shadow file that must always match?

The answer to all is No.

I was able to do all of the following without corrupting the FrontPage Extensions:

1. Edited .htaccess directly from within cPanel > File Manager, inserting carriage returns and whitespace.
2. Copied all the text from .htaccess, pasted it into Notepad, changed LF line ends to CRLF, inserted blank lines, pasted the text back into .htaccess on my server, and saved it.
3. Added some code (not mod_rewrite code) at the end of .htaccess.
4. Then, after intentionally corrupting my FrontPage Extensions (by inserting mod_rewrite code), I took the text from my previously known good .htaccess file, pasted it back into .htaccess, and restored full FrontPage access to my site. That is, I was able to uncorrupt the FrontPage Extensions.

It is only the settings specified in .htaccess that corrupt the FrontPage Extensions. It is not the act of tampering with the file.

Can you modify your server's configuration so you can use the FrontPage Extensions and still have full use of .htaccess, including mod_rewrite?

Yes. Here's how:

Navigate to each of the following three files (using, for example, cPanel > File Manager) and edit each one using the Edit File command. If you decide not to save the file, just close the browser window. The file is not saved unless you click the Save button.

1. /public_html/_vti_bin/.htaccess
2. /public_html/_vti_bin/_vti_adm/.htaccess
3. /public_html/_vti_bin/_vti_aut/.htaccess

At the top of each file you will probably find the following line. If it's not there, see Note 1 at the bottom of this page:

Options None

It was put there when the FrontPage Extensions were installed. Don't delete or modify that line. It gives this folder a secure starting point by turning OFF any insecure options that might be enabled in folders above it. It is most likely this line that prevents publishing successfully with FrontPage, but removing it might weaken the folder's security. Instead, make a specific modification that has fewer side effects:

At the very bottom of each file, add the following on its own line:

Options +SymLinksIfOwnerMatch

Save the file. Do the same for each of the three files.

You do not have to make any modifications to the top-level /public_html/.htaccess file.

If you ever have to uninstall and reinstall your FrontPage Extensions, you must reapply the mods to those three files afterwards because reinstalling the FPE resets all .htaccess files in the site to the FrontPage default ones, discarding any modifications you have made. Fortunately, it does save a backup copy of each old .htaccess file, in the same folder where it was, with a name that has 10 digits appended, like this:

.htaccess.0123456789

You can use the contents of each backup file to restore the corresponding .htaccess file to what it was before you reinstalled the FPE. After doing that, the backup files with the appended digits have no function and can be deleted.

Alternate method

There is another .htaccess line that will achieve the same purpose as the one above:

Options +FollowSymLinks

When first writing this article, I thought the Apache documentation seemed to imply this was less secure. However, the newer documentation appears to imply that neither is more secure than the other, so the two methods are probably equivalent, and they both worked for me. Without fully understanding the differences between the two, what I'd suggest is that if one doesn't work, try the other.

Test results

I've tested the configuration described above with the following cPanel features, and they all work without corrupting the FrontPage Extensions. By the end of testing, they were all enabled simultaneously:

• Index Manager
• Redirects (RewriteEngine, RewriteCond, RewriteRule)
• MIME Types
• Hotlink Protection
• DenyIP
• Apache-level (rather than FrontPage subdomain level) folder password protection

But cPanel can't be fully trusted to manage .htaccess

In the course of testing, it became evident that there are some flaws in how cPanel manages the .htaccess file.

cPanel is not part of Linux or Apache. It is an independent module that provides a user friendly interface to some of Apache's features. It takes options you select and translates them to .htaccess code. But like almost any automated code generator, its features are somewhat crude and error-prone compared to what you can accomplish if you work with the underlying system directly.

In order to work properly, cPanel has to correctly interpret the existing contents of .htaccess, which it seems unable to do in some circumstances. Then, if its method of modifying .htaccess consists of inserting a block of cookie-cutter code without regard for possible conflicts, it's no wonder .htaccess can end up in disarray.

Unless you have no other choice, cPanel should not be completely trusted with management of your .htaccess files, whether you use FrontPage or not. It is much more advisable to determine the correct code to achieve a desired objective, and insert it into .htaccess manually. You can still use cPanel to generate the code, but you should look at what it did and decide whether it's correct.

A good method for making changes, if you must use cPanel, is to:

1. Copy all the text of your current .htaccess file to a safe location.
2. Make the desired changes in cPanel.
3. Test the site to see if it still works properly. If it doesn't:
4. Copy and save the new malfunctioning .htaccess to a safe location so you can review the changes that cPanel made.
5. Put your old good .htaccess file back in place.
6. Study the new malfunctioning code to determine in what way cPanel made the changes incorrectly.
7. Apply the same changes to the old .htaccess, but correct any mistakes that were made by cPanel.

Examples of how cPanel inserted code. Some had errors.

Index Manager

Turning off indexes for the public_html folder inserted this code into .htaccess:

Options All -Indexes

This is more meddlesome than is required. The "All" enables features you might not want or need. This would turn off indexing, without the side effects:

Options -Indexes

MIME Types

I set up a MIME type for Windows wma files. cPanel inserted this code. No problems:

AddType audio/x-ms-wma wma

Hotlink Protection

Enabling the default Hotlink Protection caused cPanel to insert the following code, which has a real error in it.

RewriteEngine on
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http://mydomain.com/.*$ [NC]
RewriteCond %{HTTP_REFERER} !^http://mydomain.com$ [NC]
RewriteCond %{HTTP_REFERER} !^http://www.mydomain.com/.*$ [NC]
RewriteCond %{HTTP_REFERER} !^http://www.mydomain.com$ [NC]
RewriteRule .*\.(jpg|jpeg|gif|png|bmp)$ http://mydomain.com/bandwidththief.htm [R,NC]

The last line above should have an L in it [R,NC,L].

As long as this is the only block of Rewrite code in your site (which is what cPanel expects), it won't cause problems, but if you have other Rewrite blocks, it will cause problems. This is because cPanel appears to reserve the RewriteEngine for Hotlink Protection only. Considering how often mod_rewrite is needed for other purposes, this is wasteful on the part of cPanel, and it leads to the following errors:

1. If you have any preexisting Rewrite blocks in your .htaccess for other purposes, when you go to cPanel Hotlink Protection, it shows Hotlink Protection as enabled, even though it's really not.
    
2. The entries that it shows for sites from which to allow access and for allowed and disallowed file types are taken from all the RewriteCond lines that it finds, whether or not they have anything to do with Hotlink Protection.
    
3. The values it extracts from those lines are totally wrong. They will not accomplish Hotlink Protection at all. It's just garbage.
    
4. Then, if you click Save, what it writes to .htaccess for Hotlink Protection will be completely wrong, producing an .htaccess with errors in it and probably generating "server misconfiguration" errors (response code 500).

In other words, cPanel is unable to distinguish between mod_rewrite lines that relate to Hotlink Protection and ones that are there for other purposes. This can make a mess of your .htaccess file.

Conclusion: do not use cPanel Hotlink Protection. Do it yourself manually.

Redirects

This code was inserted:

RedirectMatch temp ^/dummy2.htm$ http://mydomain.com/dummy1.htm

Note how the redirect avoids using the RewriteEngine. This is evidence that RewriteEngine is reserved for the use of Hotlink Protection only. But the redirect does work.

IP Deny

I set it to deny my own IP address. It changed this (default created by the FrontPage Extensions):

<Limit GET POST>
order deny,allow
deny from all
allow from all
</Limit>

To this:

<Limit GET POST>
#The next line modified by DenyIP
order allow,deny
#The next line modified by DenyIP
#deny from all
allow from all
</Limit>

This part allows showing the Forbidden page, even to the denied party:

<Files 403.shtml>
order allow,deny
allow from all
</Files>

This line does the denial.

deny from ###.###.193.45

Removing the IP Deny using cPanel did not restore the modified .htaccess sections to their previous default state, but it makes no difference. The default FrontPage "order deny,allow" lines allow anyone to GET or POST, and no one to PUT or DELETE. The changes that DenyIP made don't change that, but it has to change the order in which it's done so it can apply the deny line globally.

A concise reference on how to interpret the Order, Allow, and Deny directives is at http://httpd.apache.org/docs/1.3/mod/mod_access.html. If two or more rules conflict in a way that can't be resolved any other way, whichever rule Apache processes last (the one farthest down in the .htaccess file) overrides earlier conflicting ones.

[Related article: denying IP addresses in .htaccess using wildcard and CIDR notation.]

Notes:

1. If you discover that the three .htaccess files do not have the Options None statement but already have the Options +SymLinksIfOwnerMatch or Options +FollowSymLinks lines in them, you don't need to make additional modifications yourself. One person has reported to me that their webhost had already modified the .htaccess files as needed.
    
2. When you copy your server's .htaccess file lines for external use or editing, you must do it using cPanel File Manager's "Edit File" mode, not "Show File". When you use Show File, critical tags that are in the file aren't displayed, and the lines you copy, missing those tags, are worse than useless because you think you got the whole text of the file, but you didn't.
    
3. When experimenting with .htaccess, be sure to save the text from your known-good .htaccess file before you start, so you can paste it back if the experiment fails.

As an example of something you can do with manual .htaccess editing, that cPanel cannot do correctly, these two sections that both use the Rewrite Engine happily co-exist. The first block redirects www to non-www. The second prohibits hotlinking:

RewriteEngine On
RewriteBase /
RewriteCond %{HTTP_HOST} ^www\. [NC]
RewriteRule ^(.*)$ http://mydomain.com/$1 [R=301,L]

RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http://(www\.)?mydomain\.com [NC]
RewriteRule .*\.(jpg|jpeg|gif|png|bmp)$ - [NC,F,L]

Questions are welcome in the discussion forum.