1

I realise that having the .htaccess file in the root of my installation is probably the way the program is designed to run, but I was having some difficulties accessing the site, and then fixed the problem by deleting the .htaccess file in the root. But then it made me wonder if this was a good idea to leave my Drupal 7 installation without a .htaccess file in the root at all.

Is there any security or operational problems if I do not have any .htaccess file in drupal root? I imagine that I would have to put it back in order to enable clean URLs.

  • What about the .htaccess file in the files directory, will you still have/use that? That one does have security implications. – greggles Aug 14 '12 at 12:34
  • I have not had any problems with the files directory. I would still have/use that one. As I posted in my comments to the posted answers, I think it is a good idea to have it in the root. – Q Beat Aug 14 '12 at 18:16
  • Will explain more. Without .htaccess file in the root, my D7 sites give server errors after updating a module. To restore access, I could delete the .hta file in the root, hence the question. By going back to the default .hta file I painstakenly added back in one item at a time. The culprit was this line: Options +SymLinksIfOwnerMatch By commenting this out and putting back in: Options +FollowSymLinks I was able to restore things. When updating modules but no .hta exists, incomplete .hta files are created in root and tempdir again breaking the site. So it's best to have them in! – Q Beat Aug 14 '12 at 19:22
5

You may have some problems, depending on how Apache is configured.

People may be able to browse directly to some hidden files. Look at lines 6 and 73 in the .htaccess to see what it restricts.

People may be able to browse directories directly. See line 10.

The site may not work right if you accidentally put a file called index.html in the root. Line 20 makes index.php the primary file.

Clean URLs won't work. I am not 100% sure if image cache will, either.

There may be some PHP security issue, but the php_flag directives have been standard settings in php.ini for a several years now.

Are you on shared hosting? If so, the problem with the .htaccess could be the Options lines. Some hosts restrict these. Everything else should be feature checked the the <IfModule> directives.

It is possible to not have a .htaccess in the DOCROOT by placing the contents into the Apache config for the site, or in an include. On high volume sites, there are some performance gains from doing this (.htaccess is read each request, where Apache config is read once when it starts).

  • Thank you very much for mentioning these reasons. I am convinced now that it would be best for me to get the default .htaccess file put back into my Drupal root and to take a good look at several of those things mentioned above. Thanks for your comments. – Q Beat Aug 8 '12 at 16:46
3

Adding to what MPD said, I think there are other two important parts in the .htacess file provided by Drupal:

  • File caching Drupal says to the browser which files must be cached and how long.

    # Requires mod_expires to be enabled.
    <IfModule mod_expires.c>
      # Enable expirations.
      ExpiresActive On
    
      # Cache all files for 2 weeks after access (A).
      ExpiresDefault A1209600
    
      <FilesMatch \.php$>
        # Do not allow PHP scripts to be cached unless they explicitly send cache
        # headers themselves. Otherwise all scripts would have to overwrite the
        # headers set by mod_expires if they want another caching behavior. This may
        # fail if an error occurs early in the bootstrap process, and it may cause
        # problems if a non-Drupal PHP file is installed in a subdirectory.
        ExpiresActive Off
      </FilesMatch>
    </IfModule>
    
  • Serving compressed JavaScript, and CSS files
    Drupal is able to return to the browser compressed files.

    # Rules to correctly serve gzip compressed CSS and JS files.
    # Requires both mod_rewrite and mod_headers to be enabled.
    <IfModule mod_headers.c>
      # Serve gzip compressed CSS files if they exist and the client accepts gzip.
      RewriteCond %{HTTP:Accept-encoding} gzip
      RewriteCond %{REQUEST_FILENAME}\.gz -s
      RewriteRule ^(.*)\.css $1\.css\.gz [QSA]
    
      # Serve gzip compressed JS files if they exist and the client accepts gzip.
      RewriteCond %{HTTP:Accept-encoding} gzip
      RewriteCond %{REQUEST_FILENAME}\.gz -s
      RewriteRule ^(.*)\.js $1\.js\.gz [QSA]
    
      # Serve correct content types, and prevent mod_deflate double gzip.
      RewriteRule \.css\.gz$ - [T=text/css,E=no-gzip:1]
      RewriteRule \.js\.gz$ - [T=text/javascript,E=no-gzip:1]
    
      <FilesMatch "(\.js\.gz|\.css\.gz)$">
        # Serve correct encoding type.
        Header set Content-Encoding gzip
        # Force proxies to cache gzipped & non-gzipped css/js files separately.
        Header append Vary Accept-Encoding
      </FilesMatch>
    </IfModule>
    

Those directives don't protect from security issues, but they increase the performance of the web site.
You can put those directives in a configuration file read from http.conf, if you have access to those files.

Generally speaking, removing the .htaccess file from the Drupal root directory is not a good idea, except when you can move those directive in another file.

  • 1
    True. I didn't mention those, mainly because there are much better methods for handling cache TTL and file compression. Typically, I will place much of the .htaccess from HTML5 Boilerplate into an Apache config include for each site. – mpdonadio Aug 8 '12 at 13:58
  • More reasons to have the .htaccess in place. Thanks for taking the time to respond. – Q Beat Aug 8 '12 at 16:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.